“deadlock detected”不是C++标准库报的，而是libc++（如macOS/LLVM）或ThreadSanitizer等工具在检测到递归加锁、重复unlock等异常时主动abort并打印的提示；glibc默认不输出该字符串，启用PTHREAD_MUTEX_ERRORCHECK仅返回EDEADLK错误码。
用 std::mutex 时触发 deadlock detected 是谁在报错？
这个提示不是 C++ 标准库本身输出的，而是某些 libc++（如 macOS 或部分 LLVM 工具链）或第三方 sanitizer（比如 ThreadSanitizer）在检测到递归加锁、重复 unlock、或死锁路径时主动 abort 并打印的。glibc 的 pthread_mutex_lock 默认不报这种文字，但启用 libpthread 的调试模式（PTHREAD_MUTEX_ERRORCHECK）可能抛出 EDEADLK 错误码，也不会直接打“deadlock detected”。
所以第一步要确认：你看到的这行字来自哪——是运行时报的，还是 ASan/TSan 日志？如果是后者，它通常附带线程 ID 和部分调用栈，但往往不完整。
怎么让崩溃时自动抓到完整调用栈？
核心思路：让程序在 abort 前把当前所有线程的栈都 dump 出来。Linux/macOS 下最可靠的方式是捕获 SIGABRT，并用 backtrace + backtrace_symbols 打印。
- 确保编译时带调试信息：
g++ -g -O0（-O2可能导致内联丢失帧） - 链接时保留符号：
-rdynamic（尤其对动态链接的库有用） - 安装信号处理器，在
SIGABRT中遍历线程（需用pthread_kill配合raise模拟中断，或用libbacktrace） - 更简单做法：直接用
gdb启动程序，设置catch signal SIGABRT，再thread apply all bt
常见漏掉的点：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 忘了
set follow-fork-mode child（多进程场景下子进程不会停） -
backtrace在 signal handler 里不是 async-signal-safe，安全起见应改用libbacktrace或在 handler 中只记录 tid，主循环再 dump
用 ThreadSanitizer 抓死锁比手动更准吗？
是的，但代价是性能下降 5–15 倍，且必须全量编译（不能只 sanitize 部分文件）。启用方式：
- 编译：
clang++ -fsanitize=thread -g -O2 - 运行时设置：
TSAN_OPTIONS="halt_on_error=1:second_deadlock_stack=1"
关键参数说明：
-
halt_on_error=1：遇到 data race 或 deadlock 立即终止（否则默认只 log） -
second_deadlock_stack=1：强制打印两个竞争线程的完整栈（默认可能只打一个） - 注意：TSan 不支持
std::shared_mutex和部分自定义锁，若用了这些，它会静默跳过检测
为什么 gdb 里看到的栈只有 2–3 层？
多半因为锁操作被内联进调用点，或者你正在看的是 __pthread_mutex_lock 这类系统调用入口，上层业务代码帧已被优化掉。
解决办法：
- 编译加
-fno-omit-frame-pointer（x86_64 必须，aarch64 推荐） - 避免在 release 模式下调试死锁；
-O0 -g虽慢，但帧信息最全 - 如果用的是
std::recursive_mutex却没声明为 recursive 类型，错误可能发生在构造时，栈顶显示的是std::mutex::lock，实际问题在线程初始化逻辑里
死锁现场最难复现的，往往是时间窗口极窄的三线程环形等待，或者混用了 std::mutex 和 pthread_mutex_t。这时候光看单次栈不够，得配合 perf record -e sched:sched_switch 抓上下文切换痕迹。
