多线程析构崩溃主因是资源竞争或生存期错位，应排查对象共享、生命周期控制及use-after-free；启用ASan+TSan检测，shared_ptr需安全传递，析构函数须无锁无异常。
多线程环境下析构函数崩溃，90%以上是资源竞争或生存期错位导致的，不是析构逻辑本身有问题——先停掉所有“检查析构函数里写了啥”的无效排查。
崩溃发生在析构时，但问题大概率不在析构函数里
析构函数只是“最后一个被调用的现场”，真正的问题往往出在：多个线程同时访问/销毁同一个对象，或一个线程正在析构时另一个线程还在用它。典型现象包括：
-
free(): double free detected或malloc_consolidate(): invalid chunk size—— 说明同一块内存被释放了两次 - 崩溃地址是极小值（如
0x2、0x8）—— 很可能是对象成员指针已被覆写为非法地址 - 只在特定调度顺序下复现（比如加断点就消失）—— 典型竞态条件，暂停改变了执行时序
此时不要盯着析构函数代码看，而要确认：这个对象是否被多个线程共享？它的生命周期由谁控制？有没有线程在它析构后仍持有其指针或引用？
用 AddressSanitizer 捕获 use-after-free 和 data race
ASan 在多线程场景下能直接暴露两类关键问题：堆上对象被释放后又被访问（use-after-free），以及未同步的并发读写（data race）。启用方式必须带线程检测：
立即学习“C++免费学习笔记（深入）”；
g++ -fsanitize=address,thread -fno-omit-frame-pointer -g -O1 your_code.cpp -o main
注意：-fsanitize=thread（TSan）比 ASan 更适合抓多线程数据竞争，但它会显著拖慢运行速度；若只开 -fsanitize=address，可能漏掉纯读写冲突（不涉及内存释放）。
- TSan 会报告类似
WARNING: ThreadSanitizer: data race的行，并标出两个冲突访问的栈帧 - ASan 报
heap-use-after-free时，会显示对象在哪被delete，又在哪被非法访问 - 两者都开启时，崩溃位置和调用链更完整，但务必用
-O1编译，-O2可能导致行号错乱
检查 shared_ptr 跨线程传递是否安全
std::shared_ptr 不是线程安全的“万能锁”，它的引用计数原子操作只保其自身，不保其所指对象。常见踩坑点：
- 从线程 A 构造
std::shared_ptr<t></t>后，直接把裸指针t.get()传给线程 B —— 线程 B 可能在 A 的shared_ptr析构后继续用该指针 - 多个线程同时调用同一个
shared_ptr的reset()或赋值，虽引用计数安全，但若对象本身无同步保护，仍可能引发竞态 - 使用
std::enable_shared_from_this时，在构造函数里调用shared_from_this()—— 此时shared_ptr尚未建立，会抛bad_weak_ptr
正确做法：跨线程传递对象，必须传递 shared_ptr 本身（而非裸指针），且确保该 shared_ptr 在所有线程退出前不被销毁。
析构函数里别做任何可能阻塞或抛异常的事
多线程中析构函数一旦阻塞（如等锁、发网络请求）或抛异常，极易引发级联崩溃：
- 若析构函数中调用
std::mutex::lock()，而该 mutex 已被另一线程持有时，当前线程将挂起——但此时栈正在展开，其他析构函数无法执行 - 若析构函数抛出异常，而此时已有未处理异常在传播（例如外层 try-catch 没包住），
std::terminate()会被立即调用 - 标准规定析构函数默认是
noexcept，显式声明noexcept(false)并不能解决根本问题，只是绕过编译器检查
安全做法：把清理逻辑拆成显式方法（如 close()、shutdown()），由业务代码在可控时机调用；析构函数只做轻量、无异常、无锁的收尾工作（如置空指针、清标志位）。
最易被忽略的一点：析构崩溃的根源往往不在崩溃那一行代码，而在几毫秒前另一个线程对同一对象的非法访问——所以日志和断点要覆盖整个对象生命周期，而不是只盯析构入口。
