企业官网建设流程全解析

TL;DR

压测接口时 JMeter 客户端 OOM 崩溃，根本原因是线程组配置了 1000 个并发但 Ramp-Up 为 0，导致瞬时创建过多线程对象。将 Ramp-Up 调整为 10s 并启用非聚合化报告，内存峰值从 2GB 降至 300MB。

现象

上周对某支付接口进行 1000 并发压测，JMeter 运行 3 分钟后直接崩溃，报java.lang.OutOfMemoryError: Java heap space。监控显示 JMeter 进程内存瞬间飙升至 2GB 后无响应。

定位

1. 检查 JVM 堆配置，默认 512MB，看似不足但实际未触及极限。
2. 检查测试计划，发现线程组设置为 1000 线程，Ramp-Up Period 设为 0 秒。
3. 分析发现，1000 个线程在 0 秒内瞬间启动，JMeter 内部为每个线程维护完整的请求上下文、结果监听器对象，导致内存碎片化和 GC 压力巨大。
4. 使用jmap -histo分析 dump 文件，发现org.apache.jmeter.reporters.ResultCollector实例数超过 5 万，占用内存 80%。

# 复现 OOM 的命令序列 # 1. 设置 JMeter 启动参数 java -Xms1g -Xmx2g -jar /opt/jmeter/lib/jmeter.jar # 2. 执行测试（假设 test-plan.jmx 配置了 1000 线程 0 ramp-up） java -jar /opt/jmeter/bin/jmeter -n -t test-plan.jmx -l result.jtl # 3. 监控内存变化 while true; do echo $(date) $(cat /proc/$(pgrep -f jmeter)/status | grep VmRSS); sleep 1; done

修复

修改测试计划，将 Ramp-Up Period 从 0 改为 10 秒，确保线程渐进式启动。同时，将结果监听器从『聚合报告』改为『无』，或使用『简洁查看结果树』以减轻内存开销。
修复后重新压测，内存峰值稳定在 300MB，GC 频率从每秒 50 次降至 2 次，测试完成无报错。

复盘

JMeter 的内存消耗与『并发线程数 × 每线程保留对象数』成正比。0 Ramp-Up 是最常见的坑，尤其在高并发场景下。建议在压测前先用 1/10 的并发验证内存稳定性，再逐步增加。下次压测前，务必检查线程组的 Ramp-Up 配置，避免瞬间压力冲击。