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::vectoruint8_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_distributionsize_t size_dist(size_min, size_max); static thread_local std::uniform_int_distributionint byte_dist(0, 255); size_t size size_dist(rng); std::vectorlt;uint8_tgt; data(size); for (autoamp; b : data) { b static_castlt;uint8_tgt;(byte_dist(rng)); } return data; } // 模拟 JSON 文本输入 static std::string generate_json_like(size_t fields) { std::string result {; for (size_t i 0; i lt; fields; i) { result quot;field std::to_string(i) quot;:quot;value std::to_string(i) quot;; if (i lt; 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::functionvoid(uint64_t id); // 启动测试concurrency 个线程运行 duration 秒 static void run(int concurrency, int duration_sec, TaskFunc task) { std::atomiclt;boolgt; running{true}; std::vectorlt;std::threadgt; threads; auto start std::chrono::steady_clock::now(); for (int i 0; i amp;lt; concurrency; i) { threads.emplace_back(amp;amp;running, amp;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 (autoamp;amp; t : threads) { if (t.joinable()) t.join(); } auto elapsed std::chrono::duration_castamp;lt;std::chrono::secondsamp;gt;( std::chrono::steady_clock::now() - start).count(); printf(Test finished in %lld seconds\n, (long long)elapsed); } };要点说明使用std::atomicbool作为全局停止信号避免加锁开销影响吞吐测量。每个线程持续循环执行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 lt; 23; i) { std::getline(iss, token, ); } long rss_pages 0; iss gt;gt; rss_pages; return rss_pages * 4; // 转换为 KB }将指标以 CSV 或 JSON Lines 格式写入文件方便事后用 Python/gnuplot 绘图分析。建议每 5 秒采样一次1 小时产生 720 个数据点既能看清趋势又不会产生过多 IO 干扰。6. 关键技巧在压力测试中发现真实 bug6.1 注入内存分配抖动让测试过程中频繁分配/释放不同大小的内存块可以暴露分配器内部的碎片问题。如果怀疑 jemalloc / tcmalloc 版本存在缺陷测试中应切换分配器对比运行。6.2 模拟网络异常用tctraffic 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 -fsanitizeaddress -fsanitizeleak -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::atomicuint64_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::atomicbool 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 -stdc17 -O2 -pthread main.cpp -o stress_test9. 总结「先跑满 1 小时再上线」不是一句口号而是一套有方法论支撑的工程实践。核心在于真实模拟输入模式、精确控制负载曲线、持续采集多维指标并在满足内存/CPU/延迟/错误率等稳态条件后再做上线决策。使用 C 结合 Linux 原生接口可以搭出一套轻量但有效的压力测试框架帮助团队在上线前把隐藏 bug 消灭在测试环境里。