jvm性能监测关键在分层监控、工具组合与指标关联：用jstat盯eden/老年代使用率及gc频率判断对象生命周期问题，jmap+mat定位内存泄漏，jstack结合top/perf分析线程与cpu异常，辅以gc日志基线对比实现主动预判。
JVM 性能监测不是堆参数调大就完事，关键在“看见问题”和“读懂信号”。真正有效的分析，靠的是分层监控 + 工具组合 + 指标关联——先抓现象，再挖根因，最后落地优化。
JVM 实时监控：用好 jstat 看懂内存与 GC 脉搏
jstat 是生产环境第一响应工具，轻量、无侵入、秒级反馈。重点不是看全字段，而是盯住几个核心指标的联动关系：
- Eden 区使用率（EU/EC）持续 >90%：说明对象创建快、回收不及时，大概率触发频繁 Minor GC；结合 YGC 频次（如每秒多次），可初步判断短生命周期对象暴增（比如日志拼接、JSON 解析临时对象）
- 老年代使用率（OU/OC）缓慢但持续上升，且 FGC 次数增加：典型内存泄漏特征，需立即导出堆快照；若 OU 突然飙升并伴随 Full GC，可能是大对象直接进入老年代或晋升失败
- GCT 占比超过 10%（GCT / 运行总时间）：GC 开销已严重侵蚀业务时间，不能只调堆大小，要查是否有大量长生命周期对象、缓存未清理、或引用链过深阻碍回收
内存泄漏定位：jmap + MAT 的精准配合
jmap 不是随便一跑就完，关键在“时机”和“方式”：
- 高负载生产环境慎用
jmap -dump全量导出——它会触发 STW，建议优先用jmap -dump:live,format=b,file=heap.hprof PID，只抓存活对象，体积小、分析快 - 日常可配置自动兜底：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/logs/heap.hprof，OOM 时自动保留现场，避免错过关键快照 - 拿到 .hprof 后，用 MAT 打开，重点看：Dominator Tree（谁占大头）、Leak Suspects（自动标记疑似泄漏点）、Group by Class（查异常膨胀的类，比如 HashMap$Node 实例数突增十倍，往往指向缓存未设上限或 key 未重写 hashCode）
线程与 CPU 异常：jstack 结合系统命令快速归因
响应慢 ≠ 内存问题，也可能是线程卡死或 CPU 啃满：
- 先用
top -Hp $PID找出 CPU 最高的线程 ID，转成十六进制（printf "%x" 12345），再在jstack $PID输出中搜索nid=0x3039，定位具体栈帧 - 关注线程状态：BLOCKED 多说明锁竞争（查 synchronized 或 ReentrantLock 争用点）；WAITING/TIMED_WAITING 大量堆积，可能是线程池队列满、下游接口超时未设 fallback，或 CompletableFuture 未加 join 导致任务悬空
- 如果 jstack 显示大量
java.lang.Thread.State: RUNNABLE但业务无进展，配合perf top -p $PID看热点方法，常暴露空循环、正则回溯爆炸、或 JSON 序列化深度嵌套等 CPU 密集型问题
日志与基线：让监控从“被动告警”走向“主动预判”
光靠命令行不够，得把数据沉淀下来形成判断依据：
- JVM 启动必须加基础日志参数：
-Xloggc:/logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=10M，避免日志滚丢、磁盘打满 - 用 GCViewer 或 GCEasy 解析 gc.log，重点关注：每次 Full GC 后老年代剩余空间是否下降（不降 = 泄漏）、Minor GC 后 Eden 是否清零（不清 = 对象晋升异常）、STW 时间分布（P99 > 200ms 就该介入）
- 建立调优前基线：记录稳定期的 YGC 频次、平均 GC 耗时、堆内存波动范围、TPS 与 P99 响应时间。后续每次调整都对比基线，避免“越调越慢”
