用 __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 objects\n", g_live_ptrs.size());
for (auto p : g_live_ptrs) {
fprintf(stderr, " %p\n", 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、intline - 记得在
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 频繁创建销毁时，控制块分配可能成为性能瓶颈或隐蔽泄漏源。
