核心目标是定量定位内存占用结构：通过Heap Dump结合MAT的Histogram、Dominator Tree和Path to GC Roots三大视图，精准识别高占比对象、其持有者及无法回收的强引用链，并辅以GC日志与jstat等运行时指标交叉验证泄漏模式。
Java 应用发生内存溢出（OOM）时，分析内存占用结构的核心目标是：搞清楚哪些对象占了最多空间、谁在持有着它们、为什么没被回收。这不是靠猜，而是通过堆转储（Heap Dump）+ 工具链定量定位。
堆内存结构要先看懂
JVM 堆不是一块混沌区域，它有明确分层：
- 新生代（Young Gen）：又分 Eden 区 + 两个 Survivor 区（S0/S1）。绝大多数新对象在此诞生，也在此快速消亡（Minor GC 主战场）。
- 老年代（Old Gen）：长期存活的对象（如缓存、全局配置、连接池）会晋升至此。Full GC 主要清理这里。
- 元空间（Metaspace）：取代了永久代（PermGen），存类元数据（类定义、方法、常量池等），位于本地内存，不属堆内。
OOM 报错里带关键词就是线索：
-
java.lang.OutOfMemoryError: Java heap space→ 堆满（新生代或老年代） -
java.lang.OutOfMemoryError: Metaspace→ 加载类太多（如热部署频繁、动态生成类） -
java.lang.OutOfMemoryError: GC overhead limit exceeded→ 老年代快满了，GC 频繁但收效甚微（典型内存泄漏征兆）
用 MAT 分析 Heap Dump 的关键路径
拿到 .hprof 文件后，打开 Memory Analyzer Tool（MAT），重点看三块：
立即学习“Java免费学习笔记（深入）”；
Histogram：看“谁占得多”
- 按类名统计实例数和总保留大小（Retained Heap）
- 关注排序靠前的类：比如
byte[]、String、HashMap$Node、自定义的Order或CacheEntry - 点击某行 → 右键 List objects → with incoming references，查看这些实例具体是谁创建/持有的
Dominator Tree：看“谁真正说了算”
- 这是 MAT 最有力的视图：列出能“支配”最多内存的对象（即删除它，就能释放其支配的所有对象内存）
- 顶部几个节点往往就是泄漏源头：比如某个静态 Map、未清理的 ThreadLocal、单例里的大缓存容器
- 展开节点，看其字段引用关系，快速识别持有链
Path to GC Roots：确认“为什么删不掉”
- 选中一个可疑对象 → 右键 Path to GC Roots → exclude weak/soft references
- GC Roots 是 JVM 认为“必须存活”的起点（如线程栈帧、静态变量、JNI 引用等）
- 如果路径里出现
ThreadLocalMap、static final字段、或ClassLoader，基本锁定泄漏点 - 注意排除
WeakReference和SoftReference（它们本就该被回收），聚焦强引用链
结合运行时指标交叉验证
光看 Dump 不够，要和实时指标对齐：
- 启动时加
-XX:+PrintGCDetails -Xloggc:gc.log，观察 GC 日志：-
PSYoungGen/ParOldGen使用率持续攀高 → 老年代堆积 - Full GC 频繁且每次回收很少 → 对象无法释放，大概率泄漏
-
- 用
jstat -gc <pid>查看各代使用率、GC 次数和耗时 - 用
jmap -histo <pid>快速看当前堆内类实例分布（无需 Dump，适合初步筛查）
常见结构异常模式对照
| 表现 | 可能结构问题 | 典型线索 |
|---|---|---|
byte[] 占比超高 |
大文件读取未流式处理、Base64 编码缓存、日志内容全量驻留 | Histogram 中 byte[] 排第一；Dominator Tree 里挂靠在 String 或 InputStream 上 |
大量 HashMap$Node 或 ConcurrentHashMap$Node
|
缓存未设上限、Key 未重写 hashCode()/equals() 导致哈希冲突膨胀 |
Map 实例 Retained Heap 巨大；Path to GC Roots 指向静态 Map 或 Spring Bean |
org.apache.catalina.loader.WebappClassLoader 占内存多 |
类加载器泄漏（常见于热部署、SPI 扩展、未关闭 JDBC Driver） | Metaspace OOM；Dominator Tree 里出现重复类加载器实例 |
java.lang.ThreadLocal$ThreadLocalMap 持有大量对象 |
ThreadLocal 使用后未 remove()，尤其在线程池场景下 |
Path to GC Roots 显示 ThreadLocalMap → Thread → ThreadPoolExecutor.Worker
|
不复杂但容易忽略
