死锁无法自动重启，需靠外部监控主动终止进程；ThreadSanitizer可运行时检测锁序反转并预警，须编译时启用-fsanitize=thread；预防应优先于检测，推荐用std::unique_lock配超时机制，将不确定等待转为确定性分支。
死锁本身无法“自动重启”——它不是崩溃，而是线程卡在等待状态，进程仍在运行、不产生信号、不抛异常，std::terminate不会触发，操作系统也不会杀掉它。所谓“自动重启”，实际是靠外部监控机制发现死锁迹象后，主动终止进程并拉起新实例。真正的检测环节必须前置且可靠，否则重启只是掩盖问题。
用 ThreadSanitizer 在编译期捕获死锁风险
ThreadSanitizer（TSan）是 GCC/Clang 提供的动态竞态检测工具，它能在运行时识别出可能导致死锁的锁获取顺序冲突，甚至直接报告 lock-order-inversion 或 potential deadlock。这不是事后诊断，而是提前预警。
- 编译时必须加：
-fsanitize=thread -fno-omit-frame-pointer -g，否则 TSan 无法注入锁序跟踪逻辑 - 它会拦截所有
std::mutex::lock()、try_lock()调用，记录每个线程的加锁栈和锁依赖图 - 一旦发现两个线程以相反顺序请求同一对互斥量（如线程 A：mtx1→mtx2，线程 B：mtx2→mtx1），TSan 会在控制台输出带堆栈的警告，例如：
WARNING: ThreadSanitizer: lock-order-inversion - 注意：TSan 会显著拖慢运行速度（5–10 倍），且增加内存开销，**仅用于测试环境**，不可上线
用 std::unique_lock + 超时机制避免无限阻塞
检测不如预防。与其等死锁发生再处理，不如让锁获取本身具备“失败退出”能力——这为上层实现可观察性与恢复逻辑打下基础。
- 永远不要用
std::lock_guard获取多个锁；改用std::unique_lock配合try_lock_for - 示例：
std::unique_lock<:mutex> lk(mtx, std::chrono::milliseconds(200)); if (!lk.owns_lock()) { /* 记录超时、触发告警、跳过临界区或执行降级逻辑 */ }</:mutex> - 超时值不能拍脑袋定：需略大于正常临界区耗时的 P99，否则误报高；但也不能设成秒级，否则失去“及时响应”意义
- 关键点：超时不是兜底，而是把“不确定等待”转为“确定性分支”，让程序保有控制权
基于锁持有状态做运行时健康检查
没有工具链支持时，可自行构建轻量级死锁探测点：定期扫描各线程是否长时间（如 >5s）停留在某个锁的 lock() 调用上，结合线程栈判断是否卡住。
立即学习“C++免费学习笔记（深入）”；
- Linux 下可用
pthread_getname_np和/proc/[pid]/stack抓取线程当前调用栈，grep 是否含pthread_mutex_lock或__lll_lock_wait - 更稳定的做法是在每次加锁前打日志：
LOG(INFO) ，再用外部脚本比对“进入”但无“退出”日志的线程 - 注意：日志本身要无锁（如用 ring buffer + signal-safe write），否则引入新死锁
- 这种检查只能提示“疑似死锁”，不能 100% 确认，但它能作为触发
kill -SIGUSR2或优雅退出的依据
别指望进程内“自愈”，用守护进程做真正重启
C++ 进程一旦陷入死锁，内部代码完全停摆，不可能自己调用 execv 或 fork 新进程。“自动重启”必须由外部进程完成。
- 推荐方案：用 systemd 管理服务，配置
Restart=on-failure+RestartSec=3，再配合上面的健康检查主动exit(1)（而非卡死） - 若必须自研守护：主进程启动后写一个心跳文件（含 PID 和时间戳），守护进程每 2 秒读一次；若文件 10 秒未更新，且目标 PID 仍存在但
kill -0 [pid]成功（说明没崩）、read /proc/[pid]/stat显示state == 'R'（运行中）但实际无进展，则kill -9后fork+exec拉起新实例 - 最易被忽略的一点：重启前必须清理共享资源（如命名信号量、共享内存段、临时文件），否则新进程可能因残留状态再次卡死
死锁检测真正的难点不在技术实现，而在于“确认卡住”和“区分长耗时与真死锁”的边界。超时值、采样频率、栈分析精度，每一处都需结合业务 RT 和锁粒度反复校准。没有银弹，只有分层设防。
