C++ memory monitor 是什么?如何观察 C++ 程序的内存使用变化

C++ memory monitor 指在程序运行时跟踪内存分配、释放与访问行为的工具或机制，核心目标是回答三个问题：内存从哪里来（堆、栈、全局区）、什么时候被释放、有没有被非法访问。它适合排查内存泄漏、越界读写、重复释放，也适合理解指针和动态数据结构的行为。如果你的程序崩溃在 free() 或 delete 附近，或者内存占用随运行时间持续上涨，就属于它的典型使用场景。

C++ 内存监控在监控什么

C++ 没有自动垃圾回收，内存生命周期由代码自己管理，所以监控对象主要是几类区域：

监控手段可以分成两类：一类是运行时插桩，比如重载 operator new / operator delete，在每次分配释放时记录大小和调用栈；另一类是外部工具，比如 Valgrind、AddressSanitizer（ASan），它们通过替换分配器或编译期插桩来检测非法访问。

常见观察手段与适用条件

重载 new / delete 记录分配

在全局作用域重载 operator new 和 operator delete，每次调用时打印地址、大小，并可用 backtrace() 拿到调用栈。优点是零依赖、可嵌入任何项目；缺点是只能看到堆分配，看不到越界访问，且需要自己维护分配表来配对释放。

#include <cstdio>
#include <cstdlib>
#include <new>

void* operator new(std::size_t size) {
    void* p = std::malloc(size);
    std::printf("alloc %zu bytes at %p\n", size, p);
    return p;
}

void operator delete(void* p) noexcept {
    std::printf("free at %p\n", p);
    std::free(p);
}

预期结果是每次堆分配和释放都会输出一行日志。卡点在于：如果程序里混用了 malloc / free，重载不会覆盖它们；另外 C++14 之后还有 sized delete，需要一并重载才能完整配对。

Valgrind 与 AddressSanitizer

Valgrind 的 Memcheck 在运行时模拟 CPU 执行，能检测未初始化读取、越界、泄漏，不需要重新编译，但程序会明显变慢，适合在测试环境跑小规模用例。AddressSanitizer 需要编译时加 -fsanitize=address -g，运行速度快很多，报错时会直接给出出错的文件、行号和调用栈，更适合日常开发。

选择条件可以这样看：需要在不改编译选项的前提下检查已有二进制，用 Valgrind；需要在开发循环里快速定位越界或 use-after-free，用 ASan。

典型问题的表现与排查思路

• 内存泄漏：进程 RSS 持续上涨，Valgrind 报告 “definitely lost”。排查时先看泄漏块的分配调用栈，定位到具体 new 的位置，再检查对应的 delete 是否在所有分支上都执行。
• 越界访问：ASan 报 “heap-buffer-overflow”，给出读写地址和对象边界。重点看数组下标计算和 std::vector 的 operator[]（它不做边界检查）。
• 重复释放：报 “double-free” 或 “attempting free on address which was not malloc-ed”。通常是同一指针被两个所有者各释放一次，或者释放后没有置空又被复用。

排查顺序建议从最小可复现示例入手：先让问题在几十行代码里稳定复现，再逐步加回真实逻辑，这样异常分配点更容易被隔离出来。

用代码可视化平台逐步观察变量与指针

staying Code Visualization Platform 支持输入 C/C++ 代码，逐步执行并查看当前行、变量值和数据结构的变化（来源：staying 平台页面 “See every step in your code”，支持 JavaScript、Python、C/C++）。它适合观察指针指向、引用关系和递归调用栈这类“静态看代码看不出来”的行为。

例如需要理解一段链表反转或递归函数的内存行为时，可以：

1. 在平台输入最小示例代码；
2. 逐步执行，观察每一步的变量值和指针指向；
3. 对照调用栈看递归的进入与返回。

它的定位是理解执行过程，而不是替代 Valgrind / ASan 做泄漏检测——平台资料没有说明它具备堆分配追踪或越界检测能力，所以内存错误的定量排查仍应交给专门工具。

实践建议

• 先用 ASan 编译跑一遍测试用例，拿到第一手的错误位置和调用栈；
• 对怀疑泄漏的路径，用重载 new / delete 或 Valgrind 确认分配与释放是否配对；
• 对指针、引用、递归等逻辑问题，用可视化平台逐步执行，把“内存变化”对应到具体的代码行；
• 始终从最小可复现示例开始，先定位异常分配点，再顺着调用栈向上分析。