jvm内存监控需分阶段、看指标、用对工具：线上应急用jstat/jmap/jstack快速锁定异常，日常运维靠gc日志与可视化趋势预警，深度排查依托mat分析堆快照定位泄漏根因，调优优先级为业务代码＞jvm参数＞容器配置。
JVM内存监控不是配几个参数就完事，而是要分阶段、看指标、用对工具，把内存使用从“看不见”变成“可追踪、可解释、可干预”。关键不在工具多，而在每一步都踩准节奏：线上出问题先保现场，日常运维重趋势，深度排查靠快照。
线上应急：5分钟内锁定内存异常源头
服务告警、OOM频发、响应变慢时，首要目标是快速获取现场证据，避免重启丢失线索。
-
jstat 实时看GC脉搏：执行
jstat -gc <pid> 1000</pid>每秒刷新一次，重点关注FGC（Full GC次数）是否持续上涨、GCT（总GC耗时）是否超过业务容忍阈值（如单次超200ms或每分钟GC耗时占比超10%）；若YGC频繁但EU（伊甸区使用率）不降，说明对象没被回收，可能 Survivor 区太小或存在短命大对象。 -
jmap 快速抓堆快照：在低峰期执行
jmap -dump:live,format=b,file=heap.hprof <pid></pid>，生成带存活对象的堆转储；若已OOM，确认启动时配置了-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/，直接取日志目录下的最新 .hprof 文件。 -
jstack 定位线程级内存压力：运行
jstack -l <pid></pid>查看线程栈和锁信息，特别关注WAITING或BLOCKED状态线程是否集中在连接池获取、缓存加载等内存敏感操作上。
日常监控：建立可预警的内存健康视图
不能等崩了才查，要让内存行为“说话”——通过持续采集+关键指标组合，提前发现苗头。
-
必埋日志参数：上线前统一加这些JVM参数：
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/logs/gc-%p.log-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/logs/heap-
配合 logrotate 按天切割、限制单文件大小，防止磁盘写满。 -
核心监控指标：不只是看“用了多少”，更要盯住变化逻辑：
• 新生代使用率长期 >80% → 对象创建过快或 Survivor 区偏小
• 老年代使用率缓慢但持续上升 → 可能存在内存泄漏（尤其注意缓存、监听器、静态集合）
• 元空间（Metaspace）使用率逼近上限 → 动态类加载过多（如热部署、Groovy脚本、大量反射） -
可视化辅助：用
jconsole或VisualVM连接应用，开启Visual GC插件，直观观察 Eden/Survivor/Old 的水位波动与GC触发关系；对 dynamic-datasource 等多数据源场景，额外监控HikariDataSource或DruidDataSource实例数及连接池 active count。
深度分析：从堆快照定位泄漏根因
拿到 .hprof 文件后，重点不是找“最大的对象”，而是找“不该活却一直活”的引用链。
-
MAT 工具三步法：
• 打开堆转储 → 点击 “Leak Suspects Report” 自动识别可疑泄漏点
• 查看 “Dominator Tree”，按 retained heap 排序，找非基础类中占用最大的实例（如自定义缓存Map、未关闭的流、静态上下文）
• 右键选中对象 → “Path to GC Roots”（with all references），确认哪些强引用阻止了回收，常见路径包括：static字段、ThreadLocal变量、未注销的监听器。 -
针对性过滤命令：若怀疑特定组件（如 dynamic-datasource），用
jmap -histo <pid></pid>后管道过滤：jmap -histo <pid> | grep -E "(DynamicRoutingDataSource|Hikari|Druid|ConnectionPool)"</pid>
观察相关类实例数是否异常增长（比如连接池对象翻倍但活跃连接未增）。 -
堆外内存别漏掉：如果堆内存正常但进程RSS持续上涨，启用 Native Memory Tracking：
启动加-XX:NativeMemoryTracking=detail，运行时执行：jcmd <pid> VM.native_memory summary.diff</pid>
重点关注Direct ByteBuffer和MappedByteBuffer分配量，排查 NIO 使用是否未释放。
调优落地：优先级比参数更重要
调优不是调完就结束，而是闭环验证。顺序错了，效果可能适得其反。
-
优化优先级明确：
业务代码层（如缓存过期策略、流式处理代替全量加载） > JVM参数层（如调整新生代比例、启用ZGC） > 容器资源配置（如限制内存配额） > 硬件升级。 -
参数调整有依据：
• 发现频繁 YGC → 增大 Eden 区（-XX:NewRatio或-Xmn），而非盲目扩堆
• Full GC 多且老年代碎片化 → 换 G1 或 ZGC，配合-XX:MaxGCPauseMillis控制停顿
• 元空间溢出 → 先查类加载器泄漏，再考虑-XX:MaxMetaspaceSize - 压测验证不可少：任何调优后，必须用真实流量或模拟压测验证效果，对比 GC 频率、STW 时间、接口 RT 三个维度是否同步改善，避免“参数好看，效果为零”。
