内存泄漏主因是对象分配与释放失配，关键在thread_local未配对delete、shared_ptr循环引用/悬垂访问、检测工具因线程未结束而漏报；须用RAII、weak_ptr、join等待及完整Valgrind参数定位。
多线程本身不直接“控制”内存占用，真正决定内存增长的是你在线程里怎么分配、持有、释放对象——尤其是那些跨线程共享、生命周期模糊、或被意外延长的对象。盲目限制线程数或堆大小，往往治标不治本；关键得卡住三类高危内存源头。
thread_local 变量里的 new 没配对 delete
这是最隐蔽也最常被忽略的泄漏点：thread_local 变量的析构函数在 C++ 标准中**不保证在线程退出时自动调用**（尤其当线程由 std::thread 启动且未显式 join 时）。如果你在里面用了 new 分配资源，又没手动 delete，那这块内存就永远留在该线程的私有堆上了。
- 检查所有
thread_local变量定义，确认是否含裸指针或需手动释放的资源 - 改用 RAII 封装：比如
thread_local std::unique_ptr<T> ptr = std::make_unique<T>()，确保析构安全 - 若必须用
new，在线程函数末尾加显式delete，或注册pthread_key_create的 destructor 回调来兜底
shared_ptr 循环引用或提前释放强引用
多个线程共用一个 std::shared_ptr 管理对象时，一旦某个线程把它的最后一个强引用销毁了，对象立即析构——但若其他线程仍在通过弱引用或原始指针访问，就会变成 use-after-free；Valgrind 可能报 Invalid read，而现象看起来像“内存没回收”，实则是悬垂访问掩盖了真实问题。
- 避免跨线程传递裸指针或
this指针给异步回调；优先传std::shared_ptr<this_type> - 用
std::weak_ptr替代部分shared_ptr持有，尤其在观察者、回调、缓存等场景 - 检查构造函数中是否隐式捕获
this到 lambda 并绑定到shared_ptr，这是循环引用高发区
ASan/Valgrind 检测时子线程未完成就被主线程 exit
工具不是万能的。如果主线程执行完就直接退出，而子线程还在跑（比如后台日志线程、心跳线程），Valgrind 会把子线程中所有未释放的堆内存标记为 possibly lost，甚至直接跳过检测；AddressSanitizer 在这种情况下也可能漏掉泄漏路径，因为进程生命周期已终结。
立即学习“C++免费学习笔记（深入）”；
- 强制主线程等待：在
main()结尾加for (auto& t : threads) t.join(); - 编译时禁用优化：
g++ -g -O0，否则内联会让 ASan/Valgrind 的调用栈断裂，定位不到new行 - Valgrind 必须加
--tool=memcheck --track-origins=yes --read-var-info=yes，否则只告诉你“地址泄漏”，找不到源文件和行号
真正难的从来不是发现哪块内存没释放，而是判断它“该不该释放”——比如一个全局缓存池中的对象，是该随线程退出清理，还是留到进程结束？这类决策没有通用答案，必须结合业务语义和对象所有权模型来定。工具只能告诉你“谁分配了”，而你得回答“谁负责释放”。
