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></pid>（注意：线上慎用，避免STW；可配合-F强制但风险更高） - 查对象TOP20：
jmap -histo <pid> | head -20</pid>，重点关注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
