应封装“分配→使用→释放”为可重用单元，用多线程+计数器驱动；各线程独立管理内存块列表；需限制虚拟内存、结构化输出指标；关键在于模拟随机访问、跨线程干扰与释放后立即复用。
怎么让程序自己反复申请/释放内存，而不是手动写循环
核心是把「分配→使用→释放」封装成可重复调用的单元，并用多线程+计数器驱动它跑满时间或次数。不能只靠 new 和 delete 写个 for 循环就完事——那样测不出并发竞争、内存碎片或系统调度压力。
- 每个线程应独立管理自己的内存块列表（比如用
std::vector<:unique_ptr></:unique_ptr>），避免共享容器引入额外锁开销 - 分配大小要随机化：固定分配 1KB 会命中内存池热点，改用
rand() % (MAX_ALLOC_SIZE - MIN_ALLOC_SIZE + 1) + MIN_ALLOC_SIZE模拟真实负载 - 必须写入数据：只
new不写，操作系统可能延迟实际物理页分配（尤其是 Linux 的 overcommit），用memset(ptr, 0xFF, size)强制触达物理内存 - 释放不能全堆栈式顺序释放：随机选 30%~50% 的已分配块释放，再补新块，才能暴露碎片问题
为什么直接用 malloc/new 做压力测试结果不准
因为标准分配器（glibc 的 ptmalloc 或 libc++ 的 malloc）自带缓存和合并逻辑，单线程连续 malloc/free 很快进入“热路径”，测出来的是缓存性能，不是内存子系统真实承压能力。
- 开启
COMPARE_WITH_MALLOC对比时，要确保每次测试前调用malloc_trim(0)（Linux）或_heapmin()（Windows）清空分配器内部空闲链表 - 若测试目标是内存池（如 tcmalloc 或自研池），需绕过
malloc直接调用池的alloc()/dealloc()接口，否则测的是“池上套 malloc”的叠加效果 - 注意地址空间布局：64 位下多次大块分配可能触发 mmap 分配，和 brk 行为不同，需在测试中显式区分并记录分配方式
如何判断压力测试真的打满了内存，而不是被系统优化掉
任务管理器或 top 显示的“内存占用”常含 cache/buffer，不可信。得看 RSS（Resident Set Size）或 Windows 的 Commit Size。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- Linux 下用
/proc/[pid]/statm读取第 2 列（RSS 页数），乘以getpagesize()得真实物理内存占用 - Windows 下调用
GetProcessMemoryInfo获取WorkingSetSize，不是PagefileUsage - 关键验证动作：在测试中途用
mlock()（Linux）或VirtualLock()（Windows）锁定一块内存，再观察 RSS 是否稳定上涨；若仍被回收，说明写入不够或未禁用 swap（sudo swapoff -a） - 警惕 C++ 智能指针自动释放：如果用
std::shared_ptr管理大块内存，循环中没及时.reset()，引用计数延迟释放会导致 RSS 曲线毛刺，应改用std::unique_ptr或裸指针+显式delete
CI/CD 流水线里跑内存压力测试要注意什么
不是把本地能跑的二进制丢进 Docker 就算集成成功。资源隔离不彻底，结果就毫无意义。
立即学习“C++免费学习笔记（深入）”；
- 容器必须限制 memory limit（Docker 的
--memory），否则测试进程可能吃光宿主机内存，导致 CI 节点假死 - 禁用透明大页（
echo never > /sys/kernel/mm/transparent_hugepage/enabled），否则stressapptest类工具会误判 TLB 压力 - POCO 的
ci/runtests.sh里有现成的检测逻辑：先运行ulimit -v $((RAM_MB * 1024))限制虚拟内存，再启动测试，避免 OOM killer 杀进程 - 输出必须结构化：不要只 print “test passed”，要记录每秒分配次数、平均延迟、峰值 RSS、失败重试次数，方便 Grafana 聚合分析
真正难的不是让内存涨上去，而是让内存涨得“脏”——带随机访问模式、跨线程干扰、释放后立即复用。这些细节漏掉，压力测试就只是个计数器游戏。
