C++ 模拟最大输入量的压力测试：跑满 1 小时再上线
1. 为什么要在上线前做长时间压力测试
很多 C++ 后端服务在功能测试和短时间压测下表现正常，一上线就出现内存泄漏、CPU 尖刺、连接池耗尽、缓冲区溢出等问题。根本原因在于：短时间压测只能发现功能缺陷，无法暴露资源累积性问题和长时间运行下的性能退化。
模拟最大输入量连续跑 1 小时以上，本质是在生产环境之前构造一个「加速老化」场景，让潜在问题提前暴露。具体来说，1 小时以上的持续高压可以验证：
- 内存稳定性：是否存在渐进式内存泄漏，堆碎片是否导致分配失败。
- CPU 稳态：长时间满载后是否存在温控降频、缓存命中率下降等问题。
- 连接与资源管理：连接池是否会在 30 分钟后逐渐耗尽，文件描述符是否泄漏。
- 数据正确性：在高吞吐下是否存在竞态条件、丢包、乱序等并发 bug。
- GC/析构路径完整性：自定义对象池、智能指针循环引用是否在长时间运行后才暴露。
2. 模拟最大输入量的核心思路
模拟最大输入量不是简单地起 1000 个线程反复发请求，而是要对系统入口施加可控、可观测、接近真实业务模式的负载。核心原则有三条：
- 输入模拟要真实：输入数据的分布、大小、频率要贴近线上实际流量特征，不能全是固定长度的 A 字符。
- 负载要可量化：能精确控制并发数、发包速率、数据大小，以便找到系统真正的拐点。
- 运行时指标要持续采集：至少采集 CPU、内存、句柄数、延迟分位数（P50/P99/P999），并以时间序列形式存储，方便事后复盘。
下面给出一个在 Linux 环境下用 C++ 搭建的压力测试框架，包含输入生成、负载调度和指标采集三个部分。
3. 输入生成：模拟真实业务流量
输入生成器需要模拟可变大小的二进制/文本数据，并加入一定随机性以避免命中固定的缓存路径。以下是一个简单的消息生成类：
#include <random> #include <vector> #include <string> class MessageGenerator { public: // 生成 size_min 到 size_max 之间的随机长度消息 static std::vector<uint8_t> generate(size_t size_min, size_t size_max) { static thread_local std::mt19937 rng(std::random_device{}()); static thread_local std::uniform_int_distribution<size_t> size_dist(size_min, size_max); static thread_local std::uniform_int_distribution<int> byte_dist(0, 255); size_t size = size_dist(rng); std::vector<uint8_t> data(size); for (auto& b : data) { b = static_cast<uint8_t>(byte_dist(rng)); } return data; } // 模拟 JSON 文本输入 static std::string generate_json_like(size_t fields) { std::string result = "{"; for (size_t i = 0; i < fields; ++i) { result += ""field" + std::to_string(i) + "":"value" + std::to_string(i) + """; if (i < fields - 1) result += ","; } result += "}"; return result; } };建议在压力测试中混合使用二进制数据和文本数据，以覆盖不同序列化/反序列化路径。
4. 负载调度器：精确控制并发与速率
压力测试的核心是一个定时调度器，它控制并发连接数、每秒请求数（RPS）和测试总时长。以下是基于std::thread和std::atomic的轻量实现：
#include <atomic> #include <chrono> #include <thread> #include <vector> #include <functional> class LoadRunner { public: using TaskFunc = std::function<void(uint64_t id)>; // 启动测试：concurrency 个线程，运行 duration 秒 static void run(int concurrency, int duration_sec, TaskFunc task) { std::atomic<bool> running{true}; std::vector<std::thread> threads; auto start = std::chrono::steady_clock::now(); for (int i = 0; i &lt; concurrency; ++i) { threads.emplace_back(&amp;running, &amp;task, i { uint64_t idx = 0; while (running.load(std::memory_order_relaxed)) { task(idx++); } }); } // 主线程等待指定时长后停掉所有工作线程 std::this_thread::sleep_for(std::chrono::seconds(duration_sec)); running.store(false, std::memory_order_relaxed); for (auto&amp; t : threads) { if (t.joinable()) t.join(); } auto elapsed = std::chrono::duration_cast&lt;std::chrono::seconds&gt;( std::chrono::steady_clock::now() - start).count(); printf("Test finished in %lld seconds\n", (long long)elapsed); } };要点说明：
- 使用
std::atomic<bool>作为全局停止信号，避免加锁开销影响吞吐测量。 - 每个线程持续循环执行
task，直到超时——这是最直接的全速压测方式。 - 如需精确控制 RPS，可以引入速率限制器（token bucket），在每次
task调用前获取令牌。
5. 指标采集：把性能数据写成时间序列
跑 1 小时以上，必须持续记录关键指标，而不是只取最后 10 秒的平均值。建议最少采集以下数据：
- 系统级指标：CPU 使用率、内存 RSS / VM、文件描述符数量、网络收发包数量。
- 进程级指标：通过
/proc/self/stat读取本进程的 CPU ticks、RSS、线程数。 - 业务级指标：成功/失败请求数、请求延迟分位数（P50/P99/P999）。
以下是利用proc/self/stat采集 RSS 的轻量函数（不依赖第三方库）：
#include <fstream> #include <string> #include <sstream> // 读取当前进程 RSS（单位 KB） static long get_rss_kb() { std::ifstream stat_file("/proc/self/stat"); if (!stat_file.is_open()) return -1; std::string line; std::getline(stat_file, line); stat_file.close(); // /proc/self/stat 的第 24 个字段是 RSS（页计数，通常 4KB 一页） std::istringstream iss(line); std::string token; for (int i = 1; i <= 23; ++i) { std::getline(iss, token, ' '); } long rss_pages = 0; iss >> rss_pages; return rss_pages * 4; // 转换为 KB }将指标以 CSV 或 JSON Lines 格式写入文件，方便事后用 Python/gnuplot 绘图分析。建议每 5 秒采样一次，1 小时产生 720 个数据点，既能看清趋势又不会产生过多 IO 干扰。
6. 关键技巧：在压力测试中发现真实 bug
6.1 注入内存分配抖动
让测试过程中频繁分配/释放不同大小的内存块，可以暴露分配器内部的碎片问题。如果怀疑 jemalloc / tcmalloc 版本存在缺陷，测试中应切换分配器对比运行。
6.2 模拟网络异常
用tc（traffic control）命令人为引入延迟和丢包：
# 对本机 8080 端口引入 50ms 延迟和 1% 丢包 sudo tc qdisc add dev lo root netem delay 50ms loss 1% # 测试结束后恢复 sudo tc qdisc del dev lo root6.3 开启 Sanitizer 跑全量测试
如果测试环境允许，建议用 AddressSanitizer + LeakSanitizer 重新编译被测服务和压测工具，在检测到内存越界或泄漏时立刻 abort，而不是等到上线后出现偶发崩溃：
g++ -fsanitize=address -fsanitize=leak -g -O1 your_service.cpp -o your_service注意：Sanitizer 会显著增加内存和 CPU 开销，测试负载应适当降低，主要验证正确性而非极限吞吐。
6.4 日志级别与采样
最大负载下不建议每笔请求都打 DEBUG 日志。应默认开启 WARNING 级别，并采用随机采样（如每 1000 笔记录 1 笔）的方式保留部分 trace 日志用于重现问题。
7. 上线的判断标准
跑满 1 小时后，需要满足以下条件才具备上线资格：
- 内存 RSS 趋于平稳：前 10 分钟允许一定增长（预热、缓存建立），但之后 RSS 应在窄幅波动或缓慢下降，无持续上涨趋势。
- CPU 使用率稳定：满载状态下 CPU 使用率波动不超过 5%，无周期性尖刺或持续衰减。
- 零 crash / abort：测试期间没有任何 SIGSEGV、SIGABRT、std::terminate 事件。
- 错误率 < 0.01%：正常业务错误码可以有一定比例，但连接拒绝、超时、OOM 等系统级错误必须接近零。
- 延迟分位数可控：P999 延迟不超过 P50 延迟的 10 倍，且无恶化趋势。
- 句柄数与线程数稳定：文件描述符和线程数在启动后 5 分钟内达到稳态，不再增长。
如果以上所有指标均满足，系统才具备承受最大输入量连续运行的能力，可以放心上线。
8. 完整测试脚本示例
将前面的代码整合，写一个完整的main.cpp入口，启动 8 线程压测 3600 秒（1 小时），同时每秒打印 RSS 和任务计数：
#include <iostream> #include <atomic> #include <chrono> #include <thread> static std::atomic<uint64_t> g_total_tasks{0}; void work(uint64_t id) { // 模拟业务处理：生成随机消息并做简单处理 auto msg = MessageGenerator::generate(256, 4096); volatile size_t sum = 0; for (auto b : msg) sum += b; g_total_tasks.fetch_add(1, std::memory_order_relaxed); } int main() { std::atomic<bool> running{true}; std::thread monitor(&running { while (running.load(std::memory_order_relaxed)) { std::this_thread::sleep_for(std::chrono::seconds(5)); long rss = get_rss_kb(); uint64_t tasks = g_total_tasks.load(std::memory_order_relaxed); printf("[MONITOR] RSS=%ld KB tasks=%llu\n", rss, (unsigned long long)tasks); } }); LoadRunner::run(8, 3600, work); running.store(false, std::memory_order_relaxed); monitor.join(); printf("Final RSS=%ld KB total_tasks=%llu\n", get_rss_kb(), (unsigned long long)g_total_tasks.load()); return 0; }编译命令（以 g++ 为例）：
g++ -std=c++17 -O2 -pthread main.cpp -o stress_test9. 总结
「先跑满 1 小时再上线」不是一句口号，而是一套有方法论支撑的工程实践。核心在于：真实模拟输入模式、精确控制负载曲线、持续采集多维指标，并在满足内存/CPU/延迟/错误率等稳态条件后再做上线决策。使用 C++ 结合 Linux 原生接口可以搭出一套轻量但有效的压力测试框架，帮助团队在上线前把隐藏 bug 消灭在测试环境里。