AddressSanitizer可稳定捕获双重释放，通过“first freed here”和“second free here”定位两次释放点；需用-g编译、禁用-O2以上优化；重点检查shared_ptr跨线程浅拷贝、move后非法访问及STL线程安全配置。
用 AddressSanitizer 快速定位双重释放的内存操作链
双重释放（double free）在多线程下极难复现，但 AddressSanitizer（ASan）能稳定捕获——它不依赖竞态窗口，而是直接监控每次 free 或 delete 是否作用于已释放/非法地址。启用方式很简单：
g++ -fsanitize=address -g -pthread your_code.cpp。注意必须加
-g（否则堆栈无符号），且不能和 -O2 以上优化共用（会干扰 ASan 插桩）。运行时报错时，输出里会明确标出「first freed here」和「second free here」两处调用栈，这是最直接的线索。
检查 shared_ptr 和 unique_ptr 的跨线程传递是否隐含浅拷贝
多线程中最常见的浅拷贝陷阱是误传 std::shared_ptr 的裸指针或引用：比如把 shared_ptr<t>&</t> 传给新线程，线程内又用 new T(*ptr.get()) 构造新对象，却忘了原始 shared_ptr 仍管理原内存；或者在线程函数里对 shared_ptr 调用 .release() 后再手动 delete。正确做法只有两种：
- 用
std::shared_ptr值传递（触发引用计数+1） - 用
std::weak_ptr配合lock()安全访问
std::vector 或 std::string 成员被 move 后又被其他线程访问
类中含 std::vector、std::string 等成员时，若该对象被 std::move 到另一线程（如 push 到 std::queue 后由工作线程 pop），原对象的成员可能已进入「有效但未指定状态」（C++ 标准规定），此时若主线程仍试图访问（比如打印日志），就可能触发对已转移内存的非法读写，后续析构时引发双重释放。关键检查点：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- move 后的对象是否还被任何线程持有引用或指针
- 类的移动构造函数是否显式置空了内部裸指针（如有）
- 避免在 move 后调用非
noexcept且依赖成员数据的函数
调试时禁用编译器优化并启用线程安全的 STL 实现
Release 模式下 -O2 可能内联移动操作、消除临时对象，掩盖浅拷贝路径；而默认 libstdc++/libc++ 的 debug mode 不校验多线程容器访问。建议：
- 调试阶段强制用
-O0编译 - libstdc++ 下加
-D_GLIBCXX_DEBUG（但注意它不支持多线程容器 debug） - 更可靠的是用
clang++ -stdlib=libc++ -D_LIBCPP_DEBUG=1，其 debug 模式对std::queue等有基础线程访问检查
立即学习“C++免费学习笔记（深入）”；
真正棘手的不是发现双重释放，而是确认哪次「释放」本不该发生——往往要顺着 ASan 给出的两个释放点，反查对象的整个生命周期：谁 new 的、谁 shared_ptr 接管的、谁 move 走的、谁又在不知情下 delete 的。浅拷贝本身不报错，错在后续的资源管理权归属混乱。
