线程池卡死八成是内部锁逻辑出问题，需用gdb查阻塞线程的锁等待链、统一多锁获取顺序、确保condition_variable谓词完备及notify配对，并借助tsan提前发现竞争隐患。
线程池卡死、不再接受新任务，八成是内部锁逻辑出问题了——不是任务队列被独占没释放，就是工作线程在等某个永远拿不到的锁，或者主线程和工作线程互相卡住。直接上排查路径。
看线程状态：用 gdb 连上去查谁在等什么
先确认是不是真死锁，而不是单纯忙不过来。在 Linux 下：
- 用
ps -ef | grep your_app找到进程 PID - 运行
gdb -p <pid></pid>，进 gdb 后执行info threads - 重点看哪些线程停在
__lll_lock_wait、pthread_mutex_lock或std::mutex::lock附近 - 对每个疑似阻塞线程执行
thread <id></id>+bt，看调用栈里锁变量名（比如task_queue_mutex_、shutdown_flag_mutex_）
如果发现两个线程一个持着 queue_mutex_ 等 worker_state_mutex_，另一个反过来持着 worker_state_mutex_ 等 queue_mutex_，循环等待链就坐实了。
检查线程池 shutdown 和任务提交的锁顺序
很多自实现线程池死在这里：shutdown 流程和 submit 任务共用多个锁，但加锁顺序不一致。典型错误模式：
- submit() 先 lock
queue_mutex_，再 lockstate_mutex_（比如检查是否 running） - shutdown() 却先 lock
state_mutex_，再 lockqueue_mutex_（比如清空队列） - 一旦 submit 在持 queue_mutex_ 时被调度打断，shutdown 抢入并拿到 state_mutex_，双方就僵住
解决办法只有一个：所有涉及多把锁的路径，必须严格按同一全局顺序获取。比如约定：永远先 state_mutex_，再 queue_mutex_，再 workers_mutex_。别靠注释提醒，写死在函数签名或 RAII 封装里。
警惕条件变量虚假唤醒与未配对 notify
线程池常用 std::condition_variable 唤醒空闲 worker。但若 notify 被漏掉、或 wait 前没检查谓词，就会让 worker 永远沉睡，表现就是“不处理新任务”——看起来像死锁，其实是逻辑卡死。
- 确保每次
cv_.wait(lock, [&]{ return !tasks_.empty() || shutdown_; });的谓词覆盖所有唤醒条件 - 每次往
tasks_push 后，必须调用cv_.notify_one()或notify_all()；shutdown 时也得 notify - 特别注意：如果用了
notify_one()但所有 worker 都在处理长任务，新任务来了却没人醒，也会“假死”——这不是死锁，但现象一样
加日志：在 wait 前打 “enter wait”，notify 前打 “notify fired”，能快速区分是锁卡死还是唤醒失效。
用 -fsanitize=thread 编译，提前暴露竞争点
TSan 不会直接报“死锁”，但它能抓到锁的嵌套冲突、unlock 未 lock 的 mutex、以及跨线程的未同步访问——这些往往是死锁的前兆。
- 编译时加
-fsanitize=thread -g，运行时报错会精确到行号和线程 ID - 常见 TSan 报告如：
Thread T1 (locks mutex A) and then locks mutex B. Thread T2 (locks mutex B) and then locks mutex A.——这基本就是死锁倒计时 - 注意：TSan 会显著拖慢运行速度，只在调试阶段开，别上生产
真正难缠的从来不是单个锁没释放，而是锁粒度、持有范围、唤醒时机这三者叠在一起——比如你在锁内调了用户回调，而那个回调又去 submit 新任务，瞬间就绕开你所有的锁序设计。这种地方，光看代码看不出，必须靠 gdb bt 和日志交叉验证。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
