真实压测必须满足构建一致性、负载可控性、指标可归因、结果可回归四条件；需用Google Benchmark隔离编写微基准，锁定编译器版本、优化选项、CPU频率、ASLR及线程绑定，并控制容器负载因子与哈希分布，CI中须基于main分支tag建立baseline并自动告警。
大型 C++ 项目做性能压测，不能靠单个函数计时或手写循环跑几遍就下结论。真实压测必须覆盖构建一致性、负载可控性、指标可归因、结果可回归这四个刚性条件——否则测出来的数据既不能定位瓶颈，也无法用于 CI 中的性能门禁。
用 Google Benchmark 写微基准，但别直接塞进 src/
微基准测试（micro-benchmark）是压测起点，但必须和业务代码物理隔离。把 BM_* 函数混进生产模块会导致：链接时符号污染、O3 优化干扰测量、测试逻辑被误删。正确做法是新建 bench/ 目录，单独编译成可执行文件：
- 每个
BM_*函数只测一个明确路径，比如BM_HashMapFindWithLoadFactor05，名称里带关键参数 - 用
state.range(0)控制输入规模，避免硬编码导致后续无法横向对比 - 必须调用
benchmark::DoNotOptimize()和benchmark::ClobberMemory()，尤其当计算结果未被使用时 - 禁用 LTO（
-fno-lto）和 PGO（-fno-profile-arcs -fno-test-coverage），防止跨单元优化扭曲耗时
压测前先冻结构建环境与运行时变量
同一份代码在不同构建配置下，性能差异可达 3x 以上。不锁死这些项，压测就是无效劳动：
- 编译器版本必须固定（例如 GCC 13.3.0），
CXX和CXXFLAGS在 CI 脚本中硬编码，不依赖系统默认 - 强制统一优化等级：
-O2 -march=x86-64-v3（避免-O3引入不可控向量化） - CPU 频率锁定：
echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor - 关闭 ASLR：
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space，否则每次malloc地址偏移影响缓存局部性 - 线程绑定：
taskset -c 0-3 ./bench_binary，排除调度抖动
对 std::unordered_map 这类容器，必须控制负载因子和哈希分布
容器性能对负载因子（max_load_factor）极度敏感，但默认行为会随插入顺序动态 rehash，导致压测不可复现。要得到可信对比数据：
立即学习“C++免费学习笔记（深入）”；
- 构造后立即调用
rehash(0)，再设max_load_factor(0.5)，最后验证size() / bucket_count()确实等于目标值 - 键类型用
uint64_t，哈希器用原生std::hash<uint64_t></uint64_t>，禁用自定义哈希带来的随机扰动 - 查找测试必须用预生成的 key 数组，且按相同顺序重复执行（避免 cache warmup 偏差）
- 用
bucket_size(i)遍历所有桶，导出链长直方图——这才是命中率退化的直接证据，不是光看平均耗时
CI 中跑压测，得有 baseline 对比和自动告警
在 GitHub Actions 或 GitLab CI 里跑 ./bench_binary --benchmark_out=report.json 只是第一步。没 baseline 就等于没压测：
- 每次 PR 提交时，从 main 分支 checkout 上一个 tag 的 benchmark 结果作为 baseline（不是上一次 CI）
- 用
benchmark::Initialize()+ 自定义 reporter 解析 JSON，提取关键 metric 如real_time和cpu_time，做相对变化判断 - 设置阈值：任意
BM_*耗时增长 >5% 且 p-value - 失败时自动上传两份报告 diff 到 artifact，并高亮变动最大的 3 个测试项
最常被忽略的一点：压测不是测“最快能跑多快”，而是测“在稳定吞吐下延迟是否可控”。所以 state.iterations() 要设足够大，让 OS 调度、TLB miss、cache warming 全部收敛；而 state.range() 必须覆盖真实业务数据量级——比如你的服务实际处理 10K~100K 条消息，那压测就不能只跑 100 元素。
