java内存泄漏典型场景是长生命周期对象（如静态集合、单例、线程池）意外持有短生命周期对象引用，导致后者无法gc；排查需抓取堆快照，用mat分析支配树和gc roots路径，重点检查threadlocal、静态map、内部类隐式引用及监听器未反注册等问题，并结合gc日志与运行时监控定位。
Java 中内存泄漏的典型场景之一，就是长生命周期对象（如静态集合、单例、线程池、缓存）意外持有了短生命周期对象（如 ServletRequest、Activity、Fragment、局部业务对象）的引用，导致后者无法被 GC 回收。排查核心在于：定位“谁长期持有谁”，并确认该持有关系是否合理、是否可释放。
一、用 JVM 工具抓取堆快照，聚焦可疑长生命周期容器
先让应用运行一段时间（尤其复现内存增长后），触发一次 Full GC，再导出堆快照（heap dump）：
-
jmap -dump:format=b,file=heap.hprof
（生产环境慎用，建议加 -XX:+HeapDumpBeforeFullGC 或用 JMX 触发） - 或用 jcmd
VM.native_memory summary 辅助判断是否 native 内存异常（排除混淆） - 用 VisualVM / Eclipse MAT / IntelliJ Profiler 打开 heap.hprof，按“Group by Class”查看实例数和 retained heap 排名靠前的类
重点关注：static 字段持有的集合（HashMap、ArrayList）、单例内部 Map、ThreadLocal 变量、未清理的监听器/回调、线程池中未完成的 Runnable 引用的对象。
二、在 MAT 中分析“支配树（Dominator Tree）”和“路径到 GC Roots”
选中疑似泄漏的短生命周期对象（例如某个已应结束但实例数持续增长的 RequestWrapper、ViewHolder、Listener 实例），右键 → “Paths to GC Roots” → 勾选 “exclude weak/soft/phantom references”：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 若路径终点是 java.lang.Thread（尤其自定义线程或线程池线程）→ ThreadLocalMap → value，说明 ThreadLocal 泄漏（常见于 Tomcat 线程复用 + 未 remove）
- 若路径终点是 static field（如 CacheUtil.cache、Spring Context、LoggerFactory）→ HashMap → value，检查 key 是否为短生命周期对象（如把 request 当 key 放进 static map）
- 若路径经过 Anonymous Inner Class / Lambda（尤其非静态内部类）→ outer this，注意它隐式持有了外部 Activity/Service 的引用
三、代码层面重点审查几类高危模式
不依赖工具也能提前规避，以下写法极易造成泄漏：
-
静态集合直接存局部对象：
private static List<object> cache = new ArrayList(); cache.add(request);</object>—— request 永远不会被回收 -
ThreadLocal 使用后未 remove()：
threadLocal.set(obj); // 忘了 threadLocal.remove();—— 线程池复用时，obj 随线程存活 - 注册监听器未反注册：Android 中 Activity 注册广播/BroadcastReceiver、RxJava 订阅、LiveData observeForever() 后没 removeObserver
- Handler 持有 Activity 引用且消息队列有延迟消息：非静态内部 Handler + postDelayed，Activity finish 后消息仍存在，强引用阻止回收
四、结合日志与监控缩小范围
单纯看 dump 容易迷失，配合运行时线索更高效：
- 开启 GC 日志：
-Xlog:gc*:file=gc.log:time,uptime,level,tags，观察 old gen 是否持续增长且 Full GC 后无明显下降 - 用 jstat -gc
5s 持续观察 Eden/Survivor/Old 区变化趋势 - 在关键对象构造/销毁处加日志（如 RequestWrapper 构造时打 traceId，destroy 时 log "released"），对比日志中“创建多但销毁少”的 ID
- 使用 Arthas watch/trace 命令 动态观测特定方法调用链，比如 watch com.example.Cache.put '{params,returnObj}' -n 5
不复杂但容易忽略。关键是把“谁不该持有谁”的逻辑想清楚，再用工具验证路径，最后落地到代码修复——删掉冗余引用、加 remove、用 WeakReference 包装、或改用作用域明确的局部变量。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
