Java应用内存不足的关键在于识别本该死亡却因引用链未断而存活的对象，需聚焦老年代增长趋势、引用链归属及持有方生命周期合理性。
Java 应用内存不足时，关键不是“有多少对象”，而是“哪些本该死的对象还活着”。核心在于识别那些业务上已废弃、却因引用链未断而持续占据堆内存的实例。分析要聚焦在老年代增长趋势、引用链归属和持有方生命周期是否合理这三点上。
看老年代是否“只进不出”
内存不足常表现为频繁 Full GC 但老年代使用率（O列）不降反升。用 jstat -gcutil <pid> 1000 10 持续观察：
- O值在5分钟内从40%缓慢涨到65%，且每次FGC后仅回落1~2%，说明大量对象跨代晋升后无法被回收
- Minor GC 正常清空 Eden ≠ 没问题；真正危险信号是老年代“只进不出”
- 若FGC后老年代几乎无变化，基本可判定存在存活对象误持
抓取干净的堆快照
快照质量决定分析效率。务必在一次 Full GC 刚结束时执行：
- 命令用 jmap -dump:live,format=b,file=leak.hprof <pid>，确保 dump 中只有真实存活对象，排除待回收垃圾干扰
- 避免不加 live 参数的 dump，否则文件体积大、MAT 分析卡顿、结果噪声高
- 文件大小约等于当前老年代已用内存，提前检查磁盘空间（几百MB到几GB常见）
用 MAT 定位“挡路者”
打开 hprof 后，不用猜，靠三个视图联动定位：
立即学习“Java免费学习笔记（深入）”；
- Histogram：按类排序，重点关注实例数异常多、Retained Heap 特别高的业务类（如 UserSession、OrderCache）
- Dominator Tree：直接看到谁占内存多、又拦住下游一堆对象不被回收——这类对象就是典型“挡路者”
- Path to GC Roots（排除弱/软引用）：右键可疑对象 → “Exclude weak/soft references”，看剩下哪条强引用链连回 GC Roots。高频罪魁包括：static final Map、ThreadLocal 变量、未注销的监听器、静态内部类隐式持有的外部类实例
回溯代码验证引用合理性
找到引用链后，只问两个实际问题：
- 这条引用是业务必需的吗？比如缓存中的订单对象，是否设置了过期时间或 LRU 容量上限？
- 持有方的生命周期是否远长于被持有方？例如 Servlet 实例（常驻）持有了一次性 Request 对象，属于典型生命周期错配
- 资源类（如 FileInputStream、Connection）是否漏关？它们本身内存小，但底层句柄可能拖住大片堆内存
