内存泄漏排查关键是定位被强引用持有、本该回收却长期驻留堆中的对象；通过jmap -histo:live筛选异常类，再用jmap -dump:live导出快照，最后用MAT的支配树和GC Roots路径分析引用链并结合代码验证合理性。
内存泄漏排查的关键，是确认本该被回收的对象却一直被强引用持有，导致长期驻留堆中。jmap 生成的堆转储文件（.hprof）正是定位这类“长寿命但已无业务用途”变量的核心依据。
先用 jmap 快速筛出可疑类和对象数量
不急着导出大文件，先执行：
jmap -histo:live | head -n 30
重点关注三列：实例数（#instances）、总字节数（#bytes）、类名（class name）。若发现某类实例数异常高（如数十万）、且
保留堆大小（Retained Heap）远超单个实例预期
，就值得深挖。例如：
或
占比突增，常指向缓存未清理、日志堆积或序列化残留。
导出精准的存活对象快照
避免包含已标记待回收但尚未清除的对象，务必加
live
参数：
jmap -dump:live,format=b,file=leak_check.hprof
—— 推荐首选，体积小、分析准
若进程响应慢或怀疑 GC 不及时，可省略 live，但后续需在 MAT 中手动过滤“unreachable”对象
文件路径建议用绝对路径，避免权限或挂载问题（尤其在容器中）
用 MAT 聚焦“长寿命但无业务价值”的变量
在 Eclipse MAT 中打开 .hprof 后，重点看两个视图：
支配树（Dominator Tree）
：按 Retained Heap 降序排列。找到排在前列、但业务逻辑中本不该长期持有的对象（如某个 Service 实例持有一个静态 Map，Map 里存了成千上万个 DTO）
GC Roots 路径（Path to GC Roots → with all references）
：右键可疑对象 → “Merge Shortest Paths to GC Roots”。观察谁在强引用它——常见元凶包括：静态集合、ThreadLocal 变量、未注销的监听器、缓存未设置过期策略
特别注意那些生命周期本应很短（如一次 HTTP 请求内创建），却出现在老年代且被 GC Roots 直接/间接持有的对象。
结合代码验证引用链合理性
MAT 中双击某个对象，查看其字段值和引用关系。例如：
看到一个
实例 Retained Heap 很大，点开它的
字段，再点某个
，查看 key/value 的实际内容和类型
若 value 是某个业务实体，而 key 是时间戳或 UUID，再回溯到持有该 Map 的类——检查该类是否声明为 static，或是否被 ServletContext / Spring ApplicationContext 长期持有
确认该引用是否存在业务必要性。比如“用户会话缓存”合理，“全量数据库记录缓存且永不淘汰”就不合理
不复杂但容易忽略
java.lang.Stringbyte[]HashMaptableNode