new和delete不匹配会导致泄漏，因编译器无法静态追踪指针生命周期，且链接时不检查配对；必须重载全局new/delete，用unordered_map记录分配信息，并在程序退出前遍历未释放块。
为什么 new 和 delete 不匹配会导致泄漏，而编译器不报错
因为 C++ 的内存分配是运行时行为，new 返回的指针可能被任意变量、结构体或容器持有，编译器无法静态追踪生命周期。链接时也不检查配对——operator new 和 operator delete 是独立函数调用，没语法强制绑定。
实操上，真正能捕获泄漏的时机只有程序退出前：遍历所有未归还的堆块地址，看是否还有活跃指针指向它们。但标准 C++ 不提供“枚举当前所有 malloc/new 分配”的接口，所以必须自己接管分配入口。
- 重载全局
operator new和operator delete，记录每次分配的__FILE__、__LINE__、大小和返回地址 - 用
std::unordered_map<void allocationinfo></void>存活块（键为指针，值含位置信息） - 在
operator delete中从 map 删除对应项 - 程序结束前（如 atexit 回调）遍历 map，打印剩余项
如何安全重载 operator new 而不引发递归或线程冲突
重载时若内部再调用 new（比如往 map 插入），就会无限递归。必须用底层无锁方式分配元数据——推荐 malloc，它绕过 operator new；或者用预分配固定大小缓冲区 + 自管理 freelist。
多线程下，map 插入/删除需同步。但加锁本身可能触发 new（如 std::mutex 构造），形成死锁风险。更稳妥的做法是：用 std::atomic_flag 实现自旋锁，或直接禁用检测器的多线程支持（开发期单线程够用）。
立即学习“C++免费学习笔记（深入）”；
- 在
operator new开头用static std::atomic_flag lock = ATOMIC_FLAG_INIT尝试获取锁 - 失败则 fallback 到原始
::operator new（不记录），避免卡死 - 记录结构体
AllocationInfo里只存size_t size、const char* file、int line，避免 string 构造 - 不要在重载函数里抛异常——异常栈展开可能再次触发 new
atexit 注册的泄漏报告函数为何有时不执行
当程序调用 exit(0) 或 main 正常返回时，atexit 函数会执行；但如果发生 abort()、std::terminate()、信号终止（如 SIGSEGV）、或直接调用 _Exit()，则不会触发。
这意味着：崩溃导致的泄漏不会被报告，且部分 IDE 运行环境（如 VS 的“启动而不调试”）可能静默 kill 进程，跳过清理。
- 在 main 开头尽早调用
atexit(dump_leaks)，别依赖构造函数静态初始化顺序 - 补充一个 RAII 类（如
LeakDetectorGuard），在栈上定义，析构时也调用dump_leaks() - Linux 下可结合
mallinfo()或malloc_stats()输出粗略总分配量，作为泄漏存在的旁证 - 注意：Windows 的
_CrtDumpMemoryLeaks()是 MSVC 特有，仅对_malloc_dbg有效，与重载 operator new 无关
实际使用中哪些分配会被漏检
这个工具只覆盖显式调用 new/delete 的路径。以下情况完全不捕获：
-
malloc/free、calloc、realloc—— 需额外重载这些 C 函数 -
std::vector内部扩容、std::string缓冲区增长 —— 它们可能用allocator_traits::allocate，未必走全局 new - 第三方库（如 Boost、Qt）自定义分配器，或使用 mmap/mprotect 直接申请页
- 通过 placement new 构造的对象，若没手动调用析构+释放原始内存，也会漏报
真实项目建议把它当作辅助手段：开启后跑单元测试，关注新增泄漏点；别指望它替代 Valgrind 或 ASan。
