线程池退出时任务丢失需采用三态控制：运行中→停止接收新任务→等待所有任务完成；通过原子变量标记停止请求与活跃任务数，工作线程循环检查停止标志与队列状态，析构前先通知再join，避免死锁。
线程池退出时任务丢失怎么办
线程池调用 stop() 后仍有新任务被丢弃，或正在执行的任务被强行中断——这通常是因为没有区分「拒绝新任务」和「等待已有任务完成」两个阶段。标准做法是引入三态控制：运行中 → 停止接受新任务（drain）→ 所有任务完成并退出线程。
- 用
std::atomic<bool> m_stop_requested</bool>标记是否已请求停止（只设不改） - 用
std::atomic<int> m_active_tasks</int>计数当前正在执行的任务数，stop()最后需等待其归零 - 每个工作线程在取任务前检查
m_stop_requested，若为 true 且任务队列为空，则退出循环 - 提交任务时先检查
m_stop_requested，若已请求停止则直接返回 false 或抛异常，避免写入队列
为什么 std::condition_variable::wait_until 不可靠
用 wait_until 配合超时判断队列是否为空，容易因虚假唤醒或系统时钟跳变导致提前退出或卡死。更稳妥的做法是用带谓词的 wait + 原子状态配合。
- 把任务队列的 pop 操作封装成带超时的阻塞等待，但谓词必须同时检查
!m_queue.empty()和!m_stop_requested - 不要依赖超时来“驱动”退出逻辑，超时只用于防止无限等待；真正退出信号来自
m_stop_requested - 示例片段：
while (!m_stop_requested.load() && m_queue.empty()) { m_cv.wait(lock, [this]{ return !m_queue.empty() || m_stop_requested.load(); }); }
析构时阻塞等待所有线程结束的安全写法
直接在析构函数里调用 join() 可能死锁：如果某个工作线程正持有锁又试图 push 新任务，而主线程已持锁等待 join，就会循环等待。
-
stop()必须是可重入、幂等的，且不能在加锁状态下调用join() - 推荐模式：先原子置位
m_stop_requested→ 通知所有线程退出 →notify_all()→ 解锁 → 对每个std::thread调用join() - 切忌在持有互斥锁期间调用
join()；更不能在工作线程中调用join()自身 - 若使用
std::jthread（C++20），可省略手动join()，但依然要确保stop_token正确传递并响应
std::queue + mutex 在高并发下性能差怎么缓解
单个 std::queue 加全局 mutex 是最简实现，但在大量线程争抢时会成为瓶颈，尤其退出阶段多个线程频繁检查空队列+等待。
立即学习“C++免费学习笔记（深入）”；
- 改用无锁队列（如
moodycamel::ConcurrentQueue）可消除锁竞争，但需注意其try_dequeue()返回 false 时无法区分「空」还是「忙」，仍需配合m_stop_requested判断 - 若坚持用标准库，可考虑每个线程维护本地任务缓存（work-stealing 风格），减少对共享队列的访问频次
- 退出阶段，优先让线程消费完本地任务，再统一转向共享队列；避免所有线程在同一时刻争抢同一个空队列
m_active_tasks 就永远不归零。 
