java内存泄漏的本质是对象业务上已无用，却因被gc roots可达而无法回收；关键在于追踪从gc roots（如静态变量、栈帧局部变量、活跃线程等）出发的引用链是否合理，常用mat分析“path to gc roots”定位static字段、未注销监听器等异常持有者，并结合引用类型（强/弱/软/虚）与创建位置判断生命周期是否错位。
Java内存泄漏的本质，是对象在业务逻辑中已无用，却因仍被GC Roots可达而无法回收。梳理对象生命周期，不是看它“活了多久”，而是看它“为什么还活着”——关键在于追踪从GC Roots出发的引用链是否合理、是否必要。
从GC Roots出发，画出真实引用路径
对象能否被回收，只取决于它是否能从GC Roots被访问到。常见的GC Roots包括：栈帧中的局部变量、静态变量、JNI引用、活跃线程对象等。梳理生命周期第一步，就是用工具还原这条路径。
- 用MAT打开堆转储（.hprof），选中可疑对象 → 右键“Path to GC Roots” → 选择“with all references”
- 重点观察路径中是否出现static字段、长期存活的单例、线程局部变量（ThreadLocal）、未注销的监听器等“不该持有它”的节点
- 若路径终点是某个static List或Spring Bean的成员变量，基本可判定该对象被意外长期持有了
区分四类引用，判断回收时机是否合理
不同引用类型决定了对象在GC时的“生存权”。强引用最顽固，虚引用最松散。梳理时要结合代码中实际使用的引用类型来评估：
-
强引用：如List
cache = new ArrayList() —— 只要cache不为空且自身可达，里面所有User就永不回收 -
弱引用：如WeakReference
ref = new WeakReference(user) —— 下次GC就会被清空，适合缓存场景 - 软引用：在内存不足时才回收，适合图片/数据缓存，但不解决泄漏，只延缓OOM
- 虚引用：仅用于跟踪对象被回收的时机，不影响生命周期
按对象创建位置，反推其预期存活范围
对象在哪创建，往往暗示它该活多久。把创建点和持有者对照着看，容易发现逻辑错位：
- 在方法内new的对象 → 应随方法结束、栈帧弹出而不可达（除非被逃逸出去）
- 在Servlet或Controller里new的对象 → 生命周期应与一次HTTP请求一致，若被塞进static Map或ThreadLocal，就超期服役了
- 在static块或静态字段中初始化的对象 → 天然与类加载器同寿，必须确保它持有的其他对象可安全释放
- 在线程池任务中创建的对象 → 若任务Runnable是非静态内部类，会隐式持有外部类实例，可能让整个Service对象卡在内存里
结合GC日志，验证生命周期是否失控
生命周期梳理不能只靠静态分析，还要看运行时表现。GC日志是对象“实际存活状态”的客观证据：
- 用jstat -gcutil
1000 持续观察：若老年代使用率（OU）单向爬升、Full GC后下降极少，说明大量对象跨代晋升后“赖着不走” - 对比两次Minor GC之间Eden区增长量：若每次增长都接近Eden上限，说明新对象创建快；但若Survivor区对象数也稳定上升，说明有对象在年轻代“反复躲过回收”
- 配合-XX:+PrintGCDetails启动JVM，关注“promotion failed”或“concurrent mode failure”，这些往往是老年代被泄漏对象撑满的前兆
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
