瞬时并发溢出与内存泄漏需通过GC弹性、时间同步性、对象生命周期和可控脉冲测试综合区分：前者GC后内存明显回落、与流量峰严格同步、短生命周期对象锐减、脉冲后可恢复；后者GC后老年代持续攀升、内存缓慢增长、对象不释放、重复脉冲恶化。

不能直接看内存曲线就下结论——瞬时并发溢出和持续内存泄漏的表现相似，但成因、节奏和可逆性完全不同。关键在区分“峰值扛不住”和“底子兜不住”。

看GC行为是否具备恢复弹性

瞬时并发溢出通常伴随一次或几次剧烈的Full GC，之后堆内存能明显回落至压测前水平；而内存泄漏下，每次GC后老年代占用不降反升，或仅微降又快速反弹。

• 查GC日志：搜索"Full GC" + "After GC" + 老年代使用量，连续对比3–5次。若“After GC”老年代占比从70%→65%→68%→72%，趋势上扬即存疑；若70%→45%→50%→48%，说明GC仍有效，更倾向瞬时压力。
• 配合监控图：在Grafana中叠加“Full GC触发时间点”与“堆内存回落幅度”，观察回落是否稳定、是否随并发下降同步发生。

比对业务流量与内存增长的时间粒度

内存泄漏是缓慢累积过程，一般以小时甚至天为单位显现；瞬时并发溢出则与压测波峰严格同步，误差通常在秒级。

• 把压测工具（如JMeter）的RPS曲线、TPS曲线，和JVM堆内存曲线放在同一时间轴比对。若内存飙升起始点、峰值点、回落起点均与请求洪峰完全重合，基本可排除泄漏。
• 特别注意“压测停止后”的1–2分钟：若内存迅速下降30%以上，且线程数、连接数同步归零，大概率是对象短期堆积未及时回收，而非泄漏。

验证对象生命周期是否真正失控

泄漏的本质是“该死的对象没死”。可通过轻量级快照交叉验证。

• 在压测峰值刚过、内存高位时，执行：jmap -histo <pid> | head -20</pid>，记录TOP10类实例数；5分钟后再次执行，对比数量变化。若byte[]、String、HashMap$Node等临时对象数量锐减，说明只是短生命周期对象积压。
• 用jstat -gc <pid> 1000 5</pid>观察5秒内Eden区使用率波动：若Eden频繁打满又清空（如95%→5%→92%→6%），说明新生代回收正常，压力可消化。

做一次“可控释放”测试

主动制造一个与压测强度相当、但持续时间极短（如10秒）的流量脉冲，观察系统反应。

• 若该脉冲引发同样OOM或GC overhead异常，但随后内存平稳回落、服务响应恢复正常，说明是瞬时容量瓶颈，不是泄漏。
• 若相同脉冲在第2–3次重复时，OOM提前发生或恢复变慢，则开始转向泄漏排查——因为“残留状态”正在积累。