伪内存泄漏是工具误判线程未结束时的正常堆分配：valgrind因主线程提前退出而将子线程活跃内存标为possibly lost，asan则因临时对象或thread_local析构不确定性产生假阳性；需用join()、raii、显式清理及正确选项（如--show-leak-kinds=all、lsan_options=detect_leaks=2）区分并消除。
“伪内存泄漏”不是真泄漏，但 Valgrind 或 ASan 会报它——本质是工具误判线程未结束时的正常堆分配。
为什么多线程下 Valgrind 报 possibly lost 却找不到 leak 点
Valgrind 默认在主线程调用 exit() 时立即终止检测，此时子线程可能还在运行、堆上仍有活跃分配。这些内存并非泄漏，只是 Valgrind 没等到它们被释放就收工了。
- 必须显式让主线程等待所有子线程结束：
for (auto& t : threads) t.join();，否则所有子线程的堆分配都会被标为possibly lost - 即使加了
join()，若线程函数里用了thread_local变量且内部new了内存，C++ 标准不保证其析构函数自动执行——这属于真泄漏，但 Valgrind 很难关联到thread_local上下文 -
--leak-check=full不够，得加--show-leak-kinds=all才能看到possibly lost分类；而--track-origins=yes才能定位到哪一行new出的问题
AddressSanitizer 为什么也报假阳性（尤其对临时对象）
ASan 默认启用 LeakSanitizer（LSan），但它对线程生命周期和临时对象的处理比 Valgrind 更敏感——某些场景下根本没泄漏，却打出 Direct leak。
- 典型假阳性：
std::thread(func, std::string("hello"))中传入的临时std::string，其内部堆内存可能被 LSan 误判为未释放 - 解决方法：加编译/运行时选项
-fsanitize=address -fno-omit-frame-pointer，并设置环境变量LSAN_OPTIONS=detect_odr_violation=0抑制该类误报 - 注意：LSan 默认只检测
direct leak，要查间接泄漏（如 shared_ptr 管理的对象未析构），需设LSAN_OPTIONS=detect_leaks=2
怎么区分伪泄漏和真泄漏：看线程退出前有没有清理动作
伪泄漏的核心特征是——内存分配发生在某个线程内，且该线程退出时本应释放却没做；真泄漏则是无论线程是否退出，指针都永久丢失。
- 检查所有
thread_local变量：若其中含裸指针或new出来的资源，必须在线程退出前手动delete（不能依赖静态析构） - 检查线程函数异常路径：
std::thread启动的裸函数若抛异常，catch外的delete就会被跳过；建议改用 RAII（如std::unique_ptr）或在函数末尾加try/catch保底清理 - 检查
shared_ptr使用方式：若多个线程共用一个shared_ptr，但某线程提前销毁了全部强引用，其余线程继续访问 → 这是use-after-free，Valgrind 报Invalid read，不是泄漏，但现象像内存持续增长
真正难缠的从来不是工具报什么，而是线程退出那一刻，你有没有主动交出手里每一块 new 来的内存——thread_local 不帮你做，异常不替你兜底，shared_ptr 也不会猜你想怎么同步。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
