防溢出压测核心是定位JVM失稳边界而非单纯承压能力，聚焦老年代溢出、Metaspace耗尽、Direct Memory溢出三类场景，通过阶梯压测+主动扰动识别拐点指标，并将实测临界值转化为-Xmx、-XX:MaxMetaspaceSize、-XX:MaxDirectMemorySize等硬性配置。
大促前对 JVM 做“防溢出压测”，核心不是测它能不能扛住，而是测它在什么流量下开始失稳——特别是内存溢出（OOM）、频繁 Full GC、元空间耗尽、线程数爆炸等边界点。关键在于用真实链路+量化指标+渐进推导，而不是拍脑袋设堆大小。
一、先锁定最危险的三类溢出场景
千万级秒杀中，JVM 最容易在以下三个位置“无声崩塌”：
- 老年代溢出：订单对象堆积、未及时消费的 MQ 消息体、缓存未释放的大 Map，导致老年代持续增长，触发频繁 Mixed GC 或 Full GC
- 元空间（Metaspace）耗尽：动态代理类（如 Spring AOP、MyBatis Mapper）、大量 Lua 脚本加载（Redis 预扣库存）、热更新类（如 Sentinel 规则动态生效），引发 Metaspace 不断扩容直至 OOM
- 直接内存（Direct Memory）溢出：Netty 的 PooledByteBufAllocator、RocketMQ 的堆外消息缓冲、NIO 文件读写未显式释放，尤其在高吞吐异步链路中极易被忽略
二、构建“溢出导向”的压测模型
普通压测看 TPS 和响应时间，防溢出压测必须盯死三组指标的拐点：
- 内存曲线拐点：监控 CMS Old Gen / G1 Old Gen 使用率上升斜率；当连续 3 分钟每分钟增长 >8%，且 Young GC 后老年代回收率
- GC 行为突变点：关注 Mixed GC 频次是否从每 5 秒 1 次骤增至每 2 秒 1 次；Full GC 是否从“压测全程 0 次”变成“第 18 分钟首次出现”——这个时间点就是老年代安全边界
-
类加载与线程增长速率：用
jstat -class每 10 秒采样一次，若 LoadedClassCount 在 5 分钟内增长超 1200 个，或线程数（jstat -thread）每分钟新增 >80，需立即检查动态类生成逻辑
三、用“阶梯注入 + 主动扰动”逼近真实溢出边界
不靠暴力打满，而是分四步精准试探：
- 第一阶段（基线）：以日常峰值 1.2 倍流量压测 15 分钟，记录各代内存 baseline 和 GC 稳态值
- 第二阶段（探针）：在基线上叠加 3 类扰动——① 模拟 Redis 连接池耗尽（强制创建 5000+ Jedis 实例）、② 注入 1000 个动态代理类（反射生成 Spring Proxy）、③ 手动分配 2GB DirectByteBuffer 并不释放，观察哪类扰动最先触发 STW 延长或 OOM
- 第三阶段（临界）：按 10% 步长递增并发用户数，每次只跑 3 分钟，重点捕获“第一次发生 Metaspace OOM”或“第一次出现 200ms+ STW”的并发阈值
- 第四阶段（回滚验证）：在临界点向下回退 15%，连续压测 30 分钟，确认无内存持续爬升、无 GC 频次跳变、无线程泄漏——该值即为可上线的安全容量上限
四、边界推导后必须落地的三项配置
压测得出的数字不写进 JVM 参数等于白干：
-
老年代安全水位 = 实测临界点 × 0.75：比如实测 12 万 QPS 下老年代 8 分钟涨到 92%，则生产堆应设
-Xms4g -Xmx4g -XX:MaxGCPauseMillis=200，并用-XX:G1HeapRegionSize=2M避免大对象直接进老年代 -
Metaspace 必须硬限 + 预热：根据压测中最大 LoadedClassCount 推算，设
-XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=768m，并在应用启动后主动触发一次全量 Sentinel 规则加载和 Lua 脚本预编译 -
Direct Memory 必须显式管控：加
-XX:MaxDirectMemorySize=1g，并在 Netty 初始化时设置PooledByteBufAllocator.DEFAULT的最大缓存块数，RocketMQ 消费端开启pullBatchSize=32控制单次拉取消息体大小
