LeakCanary是一款用于检测Android和Java应用中内存泄漏的开源库，由Square公司开发。其核心原理基于Java的弱引用（WeakReference）和引用队列（ReferenceQueue）机制，结合GC Roots追踪技术，能够自动发现内存中无法被垃圾回收的对象。

一、内存泄漏的本质

在Java/Android中，当一个对象不再被使用，但由于某些强引用链仍然存在，导致GC无法回收该对象，就会造成内存泄漏。例如：

• 静态变量持有Activity引用（如单例模式误用）。
• 非静态内部类持有外部类引用（如AsyncTask、Handler）。
• 资源未正确释放（如Cursor、文件流、SurfaceTexture）。

二、LeakCanary的检测原理

LeakCanary的核心工作流程分为三个阶段：监控对象生命周期 → 触发GC并验证存活 → 分析引用链。

1. 监控对象生命周期

LeakCanary通过**弱引用（WeakReference）和引用队列（ReferenceQueue）**监控对象的生命周期：

• 当一个Activity/Fragment被销毁时（如onDestroy()回调），LeakCanary会创建一个弱引用指向该对象，并将其注册到引用队列中。
• 正常情况下，对象被销毁后，其弱引用会在下次GC时进入引用队列。

2. 触发GC并验证存活

• 在对象销毁后的一段时间（默认5秒），LeakCanary会主动触发GC。
• 检查引用队列：如果对象的弱引用仍未进入队列，说明该对象仍然存活，可能存在内存泄漏。

3. 分析引用链（Heap Dump与MAT分析）

• 如果对象存活，LeakCanary会生成堆转储文件（Heap Dump），这是一个包含当前内存中所有对象的快照文件。
• 使用Shark库（LeakCanary的内存分析引擎）分析堆转储文件，找出阻止对象被回收的GC Roots引用链。
• 将分析结果以可视化报告形式展示，指出泄漏对象的类型、引用路径和可能的原因。

三、关键技术点详解

1. 弱引用与引用队列

• 弱引用（WeakReference）：当一个对象仅被弱引用持有时，GC会直接回收该对象，并将其弱引用放入引用队列。
• 引用队列（ReferenceQueue）：用于接收GC回收的弱引用对象。

示例代码（简化版原理）：

Object monitoredObject = new Object();
ReferenceQueue<Object> referenceQueue = new ReferenceQueue<>();
WeakReference<Object> weakReference = new WeakReference<>(monitoredObject, referenceQueue);

// 模拟对象不再被使用
monitoredObject = null;

// 触发GC
System.gc();

// 检查引用队列
Reference<? extends Object> polled = referenceQueue.poll();
if (polled == null) {
    // 弱引用未进入队列，对象可能泄漏
} else {
    // 对象已被GC回收
}

2. GC Roots追踪

• GC Roots：内存中一组特殊的对象，包括静态变量、栈变量、JNI引用等。GC从这些根对象开始遍历，标记所有可达对象。
• LeakCanary通过分析堆转储文件，找出从GC Roots到泄漏对象的完整引用链，例如：

  GC Root (静态变量) → ActivityManager → LeakedActivity
  

3. 自动触发GC的时机

• LeakCanary在检测到Activity/Fragment销毁后，会等待一段时间（默认5秒）再触发GC，确保对象有足够时间被回收。
• 如果等待后对象仍存活，会再次触发GC并等待（默认再等5秒），以避免误判。

四、LeakCanary的工作流程

1. 初始化：在Application中安装LeakCanary。
2. 注册监听：通过ActivityLifecycleCallbacks监听Activity的生命周期。
3. 对象销毁：当Activity的onDestroy()被调用时，创建弱引用并注册到引用队列。
4. 定时检查：延迟5秒后，检查引用队列是否包含该弱引用。
5. 触发GC：若未包含，触发GC并再次检查。
6. 生成Heap Dump：若仍未包含，生成堆转储文件。
7. 分析引用链：使用Shark库分析堆转储，找出泄漏路径。
8. 通知开发者：通过Notification或Log展示泄漏报告。

五、常见内存泄漏场景及LeakCanary报告

场景1：静态变量持有Activity引用

public class MySingleton {
    private static MySingleton instance;
    private Context context;

    private MySingleton(Context context) {
        this.context = context; // 持有Activity引用
    }

    public static MySingleton getInstance(Context context) {
        if (instance == null) {
            instance = new MySingleton(context); // 传入Activity
        }
        return instance;
    }
}

LeakCanary报告：

* GC ROOT static MySingleton.instance
* references MySingleton.context
* leaks MainActivity instance

场景2：非静态内部类持有外部类引用

public class MainActivity extends Activity {
    private void startAsyncTask() {
        new AsyncTask<Void, Void, Void>() { // 非静态内部类
            @Override
            protected Void doInBackground(Void... params) {
                // 长时间运行的操作
                return null;
            }
        }.execute();
    }
}

LeakCanary报告：

* GC ROOT thread java.lang.Thread.<Java Local>
* references MainActivity$1.this$0
* leaks MainActivity instance

六、LeakCanary的优缺点

优点

• 自动化检测：无需手动编写大量测试代码，自动监控常见泄漏点。
• 精准定位：提供完整的引用链，快速定位泄漏源头。
• 可视化报告：以直观的方式展示泄漏路径和可能原因。
• 可扩展性：支持自定义检测规则（如检测自定义View的泄漏）。

缺点

• 性能开销：生成Heap Dump和分析过程可能影响应用性能。
• 误报风险：在某些情况下（如对象被系统缓存）可能误判为泄漏。
• 无法检测所有泄漏：例如资源未关闭（如文件流）、Binder泄漏等。

七、LeakCanary的使用建议

1. 仅在Debug版本启用：通过BuildConfig.DEBUG控制LeakCanary的初始化，避免影响Release版本性能。
2. 结合其他工具：如Profiler、Lint等，全面检测内存问题。
3. 处理已知泄漏：对于一些无法避免的“伪泄漏”（如系统组件缓存），可通过ExcludedRefs配置排除。
4. 定期分析报告：养成查看LeakCanary报告的习惯，及时修复新发现的泄漏。

总结

LeakCanary通过弱引用、引用队列和堆转储分析，能够自动检测Android应用中的内存泄漏。其核心原理是监控对象生命周期，验证对象是否应该被回收但未被回收，并通过分析GC Roots引用链找出泄漏原因。合理使用LeakCanary可以显著提升应用的内存管理质量，减少OOM崩溃的风险。