jvm内存使用率本身不是问题，但特定区域持续高占用或异常波动是性能瓶颈信号；需关注eden、old、metaspace、survivor各区含义及jstat/jstack/jmap等工具诊断。
JVM 内存使用率本身不是问题，但特定区域的持续高占用或异常波动，往往是性能瓶颈的明确信号。关键不在于“用了多少”，而在于“怎么用”和“谁在用”。
看懂各内存区的真实含义
不同区域的高使用率代表不同风险：
- Eden 区 >90%：说明对象创建快、回收也快，属正常；但如果伴随 YGC 频繁（如每秒超 5 次），说明 Young 区太小或对象生命周期偏长，需调大 -Xmn 或检查短生命周期对象是否可复用。
- Old 区 >70%：必须警惕。G1 默认在 45% 触发 Mixed GC，CMS 在 92% 左右触发 Full GC。若 Old 区缓慢爬升且 FGCT 持续增长，大概率存在内存泄漏或对象过早晋升（如大对象直接进老年代、Survivor 区太小）。
- Metaspace >85%：常见于大量动态类加载场景（Spring AOP、MyBatis Mapper、字节码增强框架）。不及时干预可能触发 Metaspace OOM，建议显式设置 -XX:MaxMetaspaceSize 并观察 -XX:MetaspaceSize 初始值是否合理。
- Survivor 区长期接近 0% 或 100%：前者说明对象“秒杀即走”，后者说明 Survivor 空间不足，对象被迫提前进入老年代——这是典型的晋升压力信号。
用 jstat 快速抓取关键证据
生产环境首选轻量命令，无需重启、无侵入：
- 执行
jstat -gcutil <pid> 1000 5</pid>，连续采样 5 次，重点关注 S0/S1/E/O/M/YGC/FGC 字段变化趋势。 - 若发现 FGC 从 0 变为 ≥1，立刻停掉非必要业务，准备做堆转储；不要等第二次 Full GC。
- 若 YGCT 单次超过 100ms，说明年轻代 GC 压力大，可能因 Eden 过小、对象分配速率突增，或 GC 算法不匹配（如 CMS 不适合高吞吐场景）。
- 对比多轮输出中 O（Old）列，若数值单向上升且增速加快，比绝对值更危险——这是泄漏的典型节奏。
结合线程与堆转储交叉验证
内存问题常与线程行为交织：
- 用
jstack <pid></pid>查看是否有大量WAITING或BLOCKED线程，尤其关注持有锁却长时间不释放的线程，可能造成对象无法被回收。 - 用
jmap -dump:live,format=b,file=heap.hprof <pid></pid>生成堆快照，用 MAT 或 VisualVM 的 Heap Walker 分析 “Dominator Tree”，定位占用 Top 3 的对象及其引用链。 - 重点排查：静态集合类（HashMap、ArrayList）未清理、缓存未设淘汰策略、监听器/回调未反注册、ThreadLocal 变量未 remove()。
避免误判：内存够用 ≠ 没瓶颈
物理内存充足、JVM 堆设置合理，不代表没有问题：
- 堆内碎片多（尤其 CMS）、GC 吞吐低，即使总使用率仅 60%，也可能频繁触发 STW（Stop-The-World）。
- 对象分配速率过高，导致 GC 频繁，CPU us 值被动拉高，此时 CPU 瓶颈实为内存管理引发的连锁反应。
- 元空间或直接内存（-XX:MaxDirectMemorySize）耗尽，不会体现为堆内存告警，但会导致 OOM: Metaspace 或 OOM: Direct buffer memory。
