稳定性取决于线程异常、超时、退出时能否干净收尾，且共享状态访问路径唯一可控；std::thread析构前必须join()或detach()，否则调用std::terminate()终止进程。
高负载下 C++ 多线程系统崩溃、卡死、内存缓慢增长——这些问题通常不是因为“线程太多”，而是同步机制、资源生命周期和任务调度三者没对齐。直接上结论：稳定性不取决于线程数，而取决于你能否让每个线程在异常、超时、退出时都干净收尾，且共享状态的访问路径唯一可控。
std::thread 析构前必须 join() 或 detach()，否则 terminate()
这是最常被忽略的硬性约束。C++ 标准规定：std::thread 对象析构时若仍处于可加入（joinable）状态，会直接调用 std::terminate()，进程立即终止，无堆栈、无日志、无法捕获。
- 常见错误：局部
std::thread对象未显式join()，函数返回即析构 - 更隐蔽的坑：在线程池中 worker 线程因任务抛异常退出，但主线程未等待其结束就销毁线程池对象
- 正确做法：用 RAII 封装，例如
std::jthread（C++20），它在析构时自动join()；或手动确保所有线程在对象销毁前完成生命周期管理
任务执行必须包裹 try/catch，且不能让异常穿透 worker 循环
线程内未捕获的异常会导致该线程静默终止，资源（如堆内存、文件描述符、锁持有状态）可能未释放，而线程池仍认为该 worker “活着”，后续任务继续派发，最终形成“假活跃”线程泄漏。
- worker 函数中所有
task()调用必须包在try { task(); } catch (...) { /* 记录、清理、继续循环 */ }中 - 不要把异常向上抛给
std::thread构造函数捕获——它不处理，只触发terminate() - 若任务需传播错误，应通过线程安全队列将
std::exception_ptr回传给调度器，而非中断 worker
共享队列销毁时必须清空剩余任务，否则资源泄漏
线程池析构时若仅设置 stop = true 并 notify_all()，但不主动消费完 tasks 队列里的待执行任务，这些 std::function<void></void> 对象（尤其捕获了 shared_ptr、unique_ptr 或闭包中的大对象）将随队列一起销毁——但它们持有的资源可能已无法正确释放。
- 在
~ThreadPool()中，先置stop = true，再cv.notify_all()，然后循环pop()直到队列为空，并显式调用每个任务（或至少std::move后弃置） - 若任务支持取消语义，应在 pop 前检查是否已被标记为 cancel，避免执行已过期任务
- 使用
std::queue时注意：它不提供线程安全的size()，判断空应依赖empty()+ 锁保护
避免 std::mutex 在异常路径中泄露锁
裸调 mtx.lock()/mtx.unlock() 是高危操作。一旦临界区内抛异常，unlock() 不会被执行，导致死锁或后续所有线程阻塞在 lock() 上。
- 永远优先用 RAII：
std::lock_guard（作用域自动释放）或std::unique_lock（支持延迟锁定与手动释放） - 不要在持有锁期间做任何可能抛异常的操作（如
new、std::string::append、IO），如必须，先在锁外准备数据，再进锁内原子更新 - 多个锁嵌套时，严格按固定顺序获取（如地址大小序），否则易引发死锁；更推荐用
std::scoped_lock（C++17）一次性锁定多个互斥量
真正难的不是写一个能跑的线程池，而是让它的每个退出路径——正常停止、异常中断、信号终止、OOM 前夕——都等价于一次干净的资源归还。很多“稳定性问题”其实发生在 shutdown 阶段，而非运行中。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
