jvm内存监测重在用对工具、盯准指标、快速定位：jstat看实时gc与内存使用，jmap查对象分布与堆快照，jconsole/visualvm做可视化趋势分析，gc日志辅助深度归因。
JVM内存监测不是为了凑参数，而是看清程序“吃多少、消化快不快、有没有积食”。重点在于用对工具、盯准指标、快速定位，而不是堆砌命令。
用jstat看实时内存和GC行为
这是最轻量也最常用的手段，适合日常巡检和问题初筛。执行 jstat -gc <pid> 1000 10</pid>（每秒刷新一次，共10次），重点关注：
- EU/EC 和 OU/OC：Eden区和老年代的使用率。如果 OU 持续超过 85%，说明对象晋升过快或老年代空间不足，容易触发 Full GC；
- YGC/YGCT 和 FGC/FGCT：Minor GC 次数和耗时总和。若 YGCT 占应用总运行时间比例 >20%，说明年轻代太小或对象生命周期过长；
- S0U/S1U 长期接近容量：Survivor 区反复打满，可能意味着对象没被及时回收，或 SurvivorRatio 设置不合理，导致对象提前进入老年代。
用jmap查对象分布和内存快照
当发现内存持续上涨、GC 后无法回落，大概率存在泄漏，这时要用 jmap 定位具体是谁在“占着茅坑”：
-
jmap -histo:live <pid></pid>：列出当前存活对象的类名、实例数和占用字节，一眼看出是否某类对象异常膨胀（比如byte[]、String、自定义缓存类）； -
jmap -dump:live,format=b,file=heap.hprof <pid></pid>：导出精简版堆快照（只含存活对象），体积小、分析快，适合生产环境使用； -
jmap -heap <pid></pid>：查看堆配置详情——初始大小、最大大小、各代实际分配值、使用的 GC 算法，判断-Xms/-Xmx是否匹配实际负载。
用jconsole或VisualVM做可视化趋势观察
命令行适合“点状诊断”，而图形化工具适合“面状监控”：
- 实时查看堆内存曲线（上升斜率、GC 后回落幅度）、线程数变化、类加载数量增长；
- 发现“内存缓慢爬升+偶发 Full GC”这类渐进式问题，比单次命令更易捕捉；
- VisualVM 还可直接打开
.hprof文件，用支配树（Dominator Tree）定位大对象引用链，快速找到泄漏源头。
结合GC日志做深度归因
开启 -XX:+PrintGCDetails -Xloggc:gc.log 后，日志里藏着关键线索：
- 每次 Minor GC 后 Eden 是否清空？没清空说明有大对象或 Survivor 区太小；
- Full GC 前是否有 “promotion failed” 或 “concurrent mode failure”？前者指向晋升失败，后者常见于 CMS/G1 并发阶段失败；
- GC 后老年代占用是否不降反升？说明有强引用阻止回收，大概率是静态集合、缓存未清理、监听器未注销。
不复杂但容易忽略。
