C++如何实现自定义的智能指针检测内存泄漏？（开发工具辅助）

用 __attribute__((destructor)) 可在程序退出前自动触发泄漏检测，需配合全局 unordered_set 记录裸指针地址、重载 operator new/delete 保存调用栈，并辅以 addresssanitizer 验证真实性，避免误报漏报。

用 __attribute__((destructor)) 捕获程序退出时的未释放对象

自定义智能指针本身不自带泄漏检测能力，得靠外部机制在进程结束前扫描全局存活对象。GCC/Clang 支持 __attribute__((destructor))，它会在 main() 返回后、库卸载前自动调用标记函数——这是最轻量、无侵入的钩子点。

常见错误是把清理逻辑写在普通全局对象的析构函数里，但静态对象析构顺序不确定，可能在你的检测器之前就被销毁了，导致漏报。

• 必须用 C 风格函数 + __attribute__((destructor))，不能是类静态成员或 Lambda
• 检测器要早于所有智能指针实例初始化（比如放在单独的 .cpp 文件，避免被链接器优化掉）
• 记录对象地址时用 std::unordered_set<void></void>，别存 shared_ptr 本身——那会延长生命周期，掩盖泄漏

static std::unordered_set<void*> g_live_ptrs; void track_ptr(void* p) { g_live_ptrs.insert(p); } void untrack_ptr(void* p) { g_live_ptrs.erase(p); } <p><strong>attribute</strong>((destructor)) static void report_leaks() { if (!g_live_ptrs.empty()) { fprintf(stderr, "Memory leaks detected: %zu objectsn", g_live_ptrs.size()); for (auto p : g_live_ptrs) { fprintf(stderr, "  %pn", p); } } }

重载 operator new 和 operator delete 记录分配源头

只靠析构钩子只能知道“还有谁活着”，但不知道“从哪来的”。要定位泄漏点，得拦截每次堆分配，把调用栈、文件名、行号一起记下来。c++ 允许全局重载这两个操作符，但要注意：它们不处理 malloc、new[] 或 STL 容器内部分配（除非你一并重载 operator new[]）。

容易踩的坑是没处理对齐要求（C++17 起 operator new 必须支持 align_val_t），导致 std::vector 等容器崩溃。

立即学习“C++免费学习笔记（深入）”；

• 用 backtrace() + backtrace_symbols() 获取栈帧，但注意符号未 strip 时才有效
• 分配记录结构体里至少存 void* 地址、size_t 大小、const char* file、int line
• 记得在 operator delete 里从记录表中删除对应项，否则误报
• 多线程下必须加锁（std::mutex 或原子操作），否则记录表会损坏

配合 AddressSanitizer（ASan）验证泄漏是否真实

自己写的检测器可能漏掉某些路径（比如异常中途跳出、信号中断），也可能把正常缓存当成泄漏。AddressSanitizer 的 -fsanitize=leak 是更可靠的基线工具——它在运行时跟踪所有 malloc/free，并在退出时报告未配对的分配。

关键差异在于：ASan 检测的是“堆块未释放”，而你的自定义指针检测的是“智能指针对象未析构”。两者不等价：前者可能因裸指针接管内存而漏报；后者可能因循环引用导致 shared_ptr 永不析构而误报。

• 编译时加 -fsanitize=leak -fno-omit-frame-pointer，否则 ASan 无法还原栈
• ASan 不兼容自定义 operator new（会冲突），调试时二者选其一
• 用 LSAN_OPTIONS=suppressions=lsan.supp 屏蔽已知的第三方库假阳性
• 检查输出里的 indirect leak：说明有对象通过其他路径持有该内存，不是你的智能指针问题

为什么不用 std::weak_ptr 自动发现循环引用？

weak_ptr 本身不解决泄漏，只是提供一种打破循环的手段。它无法主动上报“这里有个循环引用正在发生”，只能靠人工在设计时插入 weak_ptr 断开强引用链。

真正复杂的地方在于：泄漏未必来自循环引用。比如一个全局 shared_ptr 持有对象，但业务逻辑忘记清空它；或者对象被注册到某个事件总线后长期无人反注册。这类问题没法靠 weak_ptr 探测，只能靠上面说的运行时分配跟踪 + 退出扫描。

最容易被忽略的是：智能指针的控制块（control block）本身也占内存，且独立于托管对象。如果你只扫描对象地址，会漏掉控制块泄漏——尤其当大量短生命周期 shared_ptr 频繁创建销毁时，控制块分配可能成为性能瓶颈或隐蔽泄漏源。