JVM内存监控需日常盯住Eden区使用率、老年代占比、GC次数和耗时等关键指标；通过jstat -gcutil关注E/O/M/YGC/YGCT/FGC/FGCT五字段，结合jmap定位大对象与泄漏源，并识别内存抖动、老年代缓慢爬升、Metaspace持续上涨三类问题信号，容器环境下须启用UseContainerSupport并用MaxRAMPercentage替代固定-Xmx。

JVM内存监控不是等出问题再看，而是日常要盯住几个关键数字——Eden区使用率、老年代占比、GC次数和耗时。一旦这些指标异常，往往意味着内存泄漏、堆配置不合理或对象生命周期失控。

盯住jstat -gcutil的5个核心字段

这是生产环境最轻量、最常用的实时监控命令：

• E（Eden区使用率）：持续高于90%，说明年轻代太小或对象存活时间变长，触发Young GC频率升高；可结合YGC次数判断（每秒>5次需调大-Xmn或优化对象创建）
• O（老年代使用率）：超过70%就要预警，G1默认在堆占用45%时启动并发标记；若O持续上升且FGC开始出现，大概率是内存泄漏或大对象直接进入老年代
• M（Metaspace使用率）：>85%且Loaded类数持续增长、Unloaded为0，常见于热部署未清理类加载器（如Tomcat反复reload）、动态代理生成过多类
• YGC/YGCT：单次YGCT > 100ms，说明Eden区过大或 Survivor 区过小导致对象频繁晋升；总YGCT占应用总运行时间>10%，GC已成瓶颈
• FGC/FGCT：只要FGC > 0，就必须立刻排查；Full GC后Old区没明显下降，基本可断定存在强引用泄漏

用jmap快速定位大对象和泄漏源头

jstat只能看“用量”，jmap才能看“谁占的”：

• 先抓快照：jmap -dump:format=b,file=heap.hprof <pid>（注意：线上慎用，避免STW；可配合-F强制但风险更高）
• 查对象TOP20：jmap -histo <pid> | head -20，重点关注byte[]、String、HashMap$Node、业务实体类实例数是否异常偏高
• 对比两次快照：用MAT或HeapHero打开两个不同时段的dump，做Dominator Tree + Leak Suspects分析，能直接标出疑似泄漏链（比如某个静态Map不断put却没remove）
• 小技巧：加参数-XX:+PrintClassHistogramBeforeFullGC，让每次Full GC前自动打印类统计，无需手动触发

识别三类典型内存问题信号

不用等OOM，这些组合现象就是明确告警：

• 内存抖动（Memory Thrashing）：堆使用曲线呈高频锯齿状（Eden涨→GC→回落→再涨），YGC极频繁但O几乎不变，通常是短生命周期对象暴增（如循环内new StringBuilder、JSON反序列化未复用Parser）
• 老年代缓慢爬升：O从20%逐步升到60%以上，期间FGC极少或没有，但响应延迟缓慢增加，多因缓存未设上限（如Guava Cache未配置maximumSize）、监听器注册后未注销
• Metaspace持续上涨：M%线性增长，Loaded类数不停加，Unloaded始终为0，典型场景是CGLIB动态代理无节制生成、JSON库（如Jackson）开启DEFAULT_TYPING但类型泛滥

容器环境下的特殊注意事项

在Docker/K8s里，传统-Xmx容易失效：

• 必须启用-XX:+UseContainerSupport（JDK8u191+默认开启），否则JVM仍按宿主机内存计算堆大小
• 推荐用-XX:MaxRAMPercentage=75.0替代固定-Xmx，让JVM按容器cgroup限制自动分配（如容器limit=4g，则堆≈3g）
• 避免同时设-Xms和-Xmx不同值：容器内存受限时，JVM扩堆失败会导致频繁GC甚至OOM，统一设为相同值更稳
• 检查cgroup v1/v2兼容性：K8s 1.22+默认v2，部分老JDK对memory.low/memory.min支持不全，建议JDK17+并配-XX:+UseCGroupMemoryLimitForHeap