定位对象泄露需检查gc root到对象的强引用链；gc root包括栈帧变量、静态字段、常量池、jni引用及运行线程；通过jmap获取堆快照，用mat分析leak suspects与dominator tree，反向追踪path to gc roots，过滤弱引用，聚焦静态变量、线程、监听器及handler等典型泄漏路径。
要定位生产环境中的对象变量泄露，核心是判断哪些本该被回收的对象仍被 GC Root 持有——即存在一条从 GC Root 出发、可到达该对象的强引用链。这不是看“有没有引用”，而是看“能不能从根追溯到它”。
明确哪些对象能作为 GC Root
GC Root 是垃圾回收器的起点，以下几类对象天然被视为“存活”，它们直接或间接引用的对象都不会被回收：
- Java 栈帧中正在使用的局部变量（包括方法参数、临时变量）
- 方法区中静态字段（static 变量）引用的对象
- 方法区中常量池引用的对象（如字符串常量、class 对象）
- 本地方法栈（Native）中 JNI 引用的对象
- 正在运行的 Java 线程本身（Thread 对象及其栈帧）
实战抓取与分析堆快照（Heap Dump）
在生产环境触发内存异常（如频繁 Full GC、OOM 前）时，需第一时间获取堆快照：
- 使用 jmap -dump:format=b,file=heap.hprof
生成 dump 文件（JDK8+ 推荐加 -XX:+HeapDumpBeforeFullGC自动捕获） - 用 JVisualVM、Eclipse MAT 或 IntelliJ IDEA 的 Memory View 打开 .hprof 文件
- 在 MAT 中执行 Leak Suspects Report，它会自动识别持有大量对象且疑似泄漏的 GC Root 路径
- 重点查看 dominator tree：排在顶部、自身占用大且支配（dominate）大量子对象的实例，往往是泄漏源头
追踪可疑引用链的关键技巧
发现一个疑似泄漏对象（如某个 Activity、Bitmap 或 Handler 实例）后，不要只看它“被谁引用”，而要反向回溯到 GC Root：
- 右键 → Path to GC Roots → with all references（显示完整强引用链）
- 优先过滤掉 WeakReference / SoftReference / PhantomReference，它们不阻止回收
- 重点关注静态变量（
java.lang.Class → static field）、线程（java.lang.Thread → local variable）、未注销的监听器（android.view.View$ListenerInfo → mOnClickListener） - 若路径中出现
ThreadLocal、Handler、AsyncTask或匿名内部类，极可能因隐式持有外部类（如 Activity）导致泄漏
典型泄漏模式与对应 Root 路径特征
不同泄漏场景在 GC Root 路径中呈现明显指纹：
-
静态集合缓存：路径终点为
java.lang.Class → static field → java.util.HashMap/ArrayList，且 key/value 持有 Activity/Context -
非静态内部类 Handler：路径含
android.os.Handler → this$0（指向外部 Activity）→ ... → Thread，且该 Thread 是主线程或后台长生命周期线程 -
未注销广播/事件总线：路径终点为
android.app.LoadedApk$ReceiverDispatcher → ... → your.Activity或org.greenrobot.eventbus.EventBus → subscriptionsByEventType → your.Activity -
资源未关闭（如 Cursor、FileInputStream）：路径经由
java.io.FileInputStream → fd → java.io.FileDescriptor，最终关联到 native 层，Root 类型可能是JNI global reference
