堆快照分析需避开四大认知偏差：一忌只盯Retained Heap最大对象而忽略增长趋势；二忌盲信Leak Suspects报告；三忌导出未过滤的非存活对象快照；四忌脱离GC日志孤立分析。
堆快照分析不是“打开MAT点几下就能找到泄漏”，很多开发者卡在第一步就误判了问题性质。真正有效的分析，关键在于避开几个高频认知偏差——它们不体现在工具操作上，而藏在分析逻辑和判断依据里。
误区一：只看“Retained Heap”最大对象，忽略增长趋势
很多人一打开MAT就直奔Dominator Tree，盯着那个占几百MB的HashMap猛看，立刻认定是它导致OOM。但实际可能是这个Map本身合理，只是里面缓存的数据量随业务增长自然上升。真正的问题，往往藏在“相同类实例数持续翻倍”或“某类对象的Retained Heap每周涨30%”这类动态变化中。
建议：
• 对比多个时间点的快照（比如每天凌晨导出一份），用Histogram按类名分组，排序“Objects”列，观察哪些类的实例数异常攀升
• 关注“Shallow Heap”与“Retained Heap”差值大的类——差值大说明它持有了大量子对象，是重点追踪对象，不是直接背锅对象
误区二：依赖Leak Suspects报告“一键定案”
Leak Suspects确实能标出可疑GC Roots，但它基于启发式规则，容易把正常强引用（比如Spring容器管理的单例Bean）误判为泄漏源。更常见的是，它没报出问题，但内存仍在缓慢上涨。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
建议：
• 把Leak Suspects当线索，不是结论。对它标出的每个可疑路径，右键选“Path to GC Roots → with all references”，逐层展开看引用链是否合理
• 重点关注非业务代码持有的引用：ThreadLocal、静态集合、未注销的监听器、数据库连接池中的闲置连接
误区三：导出快照时没过滤“存活对象”，白费力气分析已死对象
用jmap -dump:format=b,file=heap.hprof
建议：
• 生产环境导出务必加live参数：jmap -dump:live,format=b,file=heap-live.hprof
• 如果已经导出全量快照，在MAT中可手动触发“Merge Shortest Paths to GC Roots”，系统会自动排除不可达对象
误区四：不结合GC日志交叉验证，孤立看快照
一个快照只反映某个瞬间的状态。如果此时恰好刚做完一次Full GC，老年代几乎空了，你却在找“老年代堆积”，结果必然落空。同样，如果快照里年轻代对象极少，但GC日志显示YGC每秒十几次，说明对象生命周期极短，问题可能出在频繁创建而非泄漏。
建议：
• 分析快照前，先查对应时间点前后5分钟的GC日志（用jstat或开启-XX:+PrintGCDetails）
• 关键对照项：快照中老年代占用率 vs 日志中FGC触发前的老年代使用率；快照中Eden区对象大小分布 vs YGC后Eden区清空比例
