jvm内存诊断需分区域定位堆、元空间、栈问题，结合jstat/jstack/jmap/arthas等工具联动分析，按gc异常→线程状态→对象分布→堆快照顺序分阶段验证。
Java 虚拟机内存诊断不是靠“看”一张图就解决的，而是要结合运行时状态、堆/栈行为、GC日志和工具链联动分析。核心在于分区域定位 + 分阶段验证 + 工具协同。
先明确重点排查区域
JVM 内存问题主要集中在三块：
- 堆（Heap）：对象分配与回收主战场，OOM 和 Full GC 频发地
- 元空间（Metaspace，JDK 8+）：类定义、常量池、反射数据，容易因动态类加载泄漏
- 虚拟机栈（Stack）：线程数暴增、深度递归、-Xss 设置过小都会触发 StackOverflowError 或线程创建失败
常用诊断工具怎么用才有效
不同工具解决不同层次的问题，不能只依赖一个：
-
jstat：轻量实时观测，适合快速判断 GC 频率、各代使用率、元空间增长趋势
jstat -gc -h10 <pid> 2s # 每2秒打印一次GC统计，每10行空一行 jstat -gccause <pid> 1s # 查看最近一次GC原因（如Allocation Failure、Metadata GC Threshold）</pid></pid>
-
jmap：生成堆快照（heap dump），用于离线分析对象分布和大对象来源
jmap -dump:format=b,file=heap.hprof <pid> # 触发全堆 dump（慎用于生产） jmap -histo <pid> # 打印存活对象类统计（不暂停应用）</pid></pid>
-
jstack：抓取线程快照，查死锁、线程阻塞、无限递归或线程堆积
jstack -l <pid> > thread.log # -l 显示锁信息，可识别 synchronized 或 java.util.concurrent 锁争用</pid>
-
Arthas：生产环境首选，无需重启、支持在线诊断
dashboard # 实时概览（内存、线程、GC、运行时） vmtool --action getstatic -c java.lang.System -f out # 查静态字段 heapdump /tmp/heap.hprof # 安全导出堆（比 jmap 更可控） trace ClassName method # 追踪方法调用耗时与异常分支
关键信号要会识别
- 堆内存持续上涨 → 检查是否有缓存未清理、监听器未注销、流未关闭、ThreadLocal 泄漏
- 元空间持续增长且不回收 → 大量动态代理（Spring AOP）、Groovy 脚本、OSGi 类加载器未释放
- GC 后老年代占用不降反升 → 可能存在强引用链阻止回收（如静态集合误存对象）
- 线程数接近系统上限（ulimit -u）→ 检查线程池配置、异步任务未设界、连接池泄漏
建议诊断流程
- 第一步：用
jstat看 GC 是否异常（如 Young GC 频繁但老年代不涨 → 可能是短生命周期对象过多；Full GC 后老年代仍 >90% → 很可能内存泄漏） - 第二步：用
jstack看线程是否卡在 I/O、锁、或等待状态（WAITING/TIMED_WAITING 占比过高需深挖） - 第三步：用
jmap -histo快速扫一遍对象数量TOP20，确认是否存在明显异常类型（如 HashMap$Node、byte[]、String 占比畸高） - 第四步：必要时用 Arthas 或
jmap -dump获取堆快照，用 VisualVM、Eclipse MAT 分析支配树（Dominator Tree）和垃圾回收根路径（Path to GC Roots）
不复杂但容易忽略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
