用全局 operator new/delete 拦截堆分配需在 .cpp 中定义非 inline 的 extern "C" 版本，配合原子计数统计峰值，注意异常、静态对象、多线程及 mmap 等绕过路径。
怎么用全局 operator new / delete 拦截所有堆分配
核心是替换全局的 operator new 和 operator delete，让每次堆内存申请/释放都经过你的统计逻辑。不是重载类内版本，而是提供链接期可见的全局符号——必须在 .cpp 文件里定义，不能只在头文件声明。
常见错误现象：undefined reference to 'operator new(unsigned long)' —— 说明只声明没定义，或定义被 inline 了；或者多个翻译单元重复定义引发 ODR 违规。
- 必须用
extern "C"链接约定包装 malloc/free 调用，避免 name mangling 干扰底层分配器 - 不要在钩子里再调用
new（比如记录日志用std::string），否则会递归触发自己，栈溢出或死锁 - 考虑线程安全：简单方案加
std::atomic计数器 +std::atomic_fetch_add，别用std::mutex——锁里再分配内存就崩了
如何准确统计峰值而不漏掉临时对象
峰值不是“当前占用”，而是“历史最大瞬时占用”。关键在于：分配时累加、释放时减去，同时用原子操作更新峰值变量。漏统计往往发生在异常路径或静态对象析构阶段。
使用场景：程序启动后长期运行的服务、命令行工具跑完即退出、带 atexit 清理逻辑的程序——这三类行为对峰值捕获时机影响很大。
立即学习“C++免费学习笔记（深入）”；
- 静态对象的构造函数可能在
main()前触发new，析构在main()后，必须确保钩子从程序起始就生效（避免放在某个类的 static 成员初始化里） - 异常抛出时若栈展开过程触发
delete（如智能指针释放），钩子必须能处理，否则峰值虚高 - 建议在
main()开头打一个基准快照，在atexit回调里输出最终峰值，而不是依赖 RAII 对象析构——后者可能晚于内存映射释放
为什么 malloc_hook 在现代 glibc 上基本失效
__malloc_hook 等系列接口在 glibc 2.34+ 已被标记为 deprecated，且默认编译时禁用；即使强制启用，也会因多线程下性能开销大而被绕过（glibc 内部改用 per-thread cache 后，很多分配根本不走 hook 路径）。
参数差异：__malloc_hook 只能拿到 size，拿不到调用栈或对齐要求；而自定义 operator new 可以接收 std::align_val_t、nothrow_t 等额外参数，更贴近真实 C++ 分配语义。
- Clang/GCC 编译时若加了
-fsanitize=address，会直接接管new，你的钩子会被跳过——调试时得关 ASan - Windows 下对应的是
_malloc_dbg，但仅限 Debug CRT；Release 版本需用SetHeapInformation或 ETW，和 Linux 方案不兼容
峰值监控要小心哪些隐蔽的内存来源
你拦住了 new，但程序仍可能通过其他路径悄悄吃内存：mmap/mprotect 分配的匿名页、thread_local 变量、std::string 的 small string optimization 以外的堆分配、甚至 std::vector 的 capacity 扩容策略。
性能影响：每次 new 多一次原子加法，实测在高频分配场景（如每秒百万次）下，开销约 5–10%，比 malloc_hook 稳定但不可忽略。
-
std::string、std::vector等标准容器内部调用的是operator new，会被捕获；但std::string_view或栈上std::array不算 - 第三方库（如 Boost、protobuf）若显式调用
malloc而非new，就不会进你的钩子——得看它源码是否封装了分配器 - 动态链接库（.so/.dll）里的
new是否走你的钩子，取决于链接方式：static lib 没问题，shared lib 默认不共享全局 new 符号，除非用-fvisibility=default显式导出
最麻烦的其实是 mmap：有些 STL 实现（如 libstdc++ 的 __gnu_cxx::__pool_alloc）会在大块分配时切到 mmap，这部分完全绕过 operator new。真要全覆盖，得配合 /proc/self/maps 解析或 eBPF 抓系统调用——那就不是“简易”方案了。
