秒杀系统内存边界压测核心是验证堆与非堆内存协同承压能力及临界点，需通过四阶阶梯压力（50%→80%→95%→110%预估峰值QPS）、泄漏探针注入、堆外内存专项监控及业务指标联动分析，精准识别对象堆积、Metaspace膨胀、Direct Buffer逃逸等隐性问题。

大促前对秒杀系统做内存边界压测，核心不是“堆够不够大”，而是看系统在真实流量冲击下，堆与非堆内存如何协同承压、何时触达临界点、是否出现隐性泄漏或逃逸。关键在于用可复现的阶梯压力，精准暴露内存行为拐点。

构建分层压力斜率模型

避免一次性拉满并发。采用四阶递增：50% → 80% → 95% → 110% 预估峰值QPS，每阶持续5分钟并强制触发一次Full GC。重点观察：

• 堆内Old Gen使用量在95%压力段是否出现非线性陡升（提示对象堆积未释放）
• Metaspace使用率是否随类加载持续增长（尤其Spring AOP代理类、动态生成的Redis序列化器）
• Direct Buffer占用是否同步飙升（Netty堆外内存、JDBC PreparedStatement缓存）

注入可控泄漏诱捕内存异常模式

在压测脚本中嵌入轻量级泄漏探针，不破坏业务逻辑但能放大问题：

• 预热期：用Guava Cache预填充10万商品ID，但不设expireAfterWrite → 触发元空间+堆联合膨胀
• 压力维持期：在下单链路中模拟未关闭的ZipInputStream或MappedByteBuffer → 直接观测Direct Memory泄漏速率
• 释放期：压力撤除后执行System.gc() + 等待30秒，检测Old Gen回落延迟＞5秒 → 暗示Finalizer队列阻塞或弱引用未及时清理

隔离监控堆外内存逃逸路径

非堆内存问题常被忽略，但秒杀场景下极易成为瓶颈：

• 用jcmd <pid> VM.native_memory summary scale=MB每30秒采集一次，比对Committed与Reserved差值突增
• 检查Netty的PooledByteBufAllocator是否开启池化（默认开启），禁用后重压对比Direct内存分配速率
• 容器环境运行kubectl top pod --containers，确认OOMKilled前1分钟内容器RSS是否远超JVM -Xmx设置（典型堆外逃逸信号）

绑定业务指标反推内存健康阈值

不只看内存绝对值，而要看它和业务水位的关系：

• 当P99响应时间突破400ms时，记录对应堆使用率——此即“业务可接受上限”
• 当库存扣减失败率首次＞0.5%，立即dump堆并检查Redis连接池对象（如JedisPool中的idleObjects）是否占堆TOP3
• 建立内存健康度公式：MemoryScore = (1 − OldGenUsedRatio) × (1 − DirectMemGrowthRate) × TPS，分数连续3分钟＜0.65即预警