JVM 内存分代与垃圾回收 (GC) 机制详解

引言：理解基石，方能构建高楼

Java 和 Android 开发的便利性很大程度上得益于 JVM (Java Virtual Machine) 提供的自动内存管理和垃圾回收 (GC) 机制。然而，理解这些底层机制并非可选，而是编写健壮、高性能应用的基础。不恰当的对象引用可能导致内存泄漏，进而引发应用卡顿甚至崩溃 (OOM)。

本文将首先坚实地讲解 JVM 的内存分代模型与核心的垃圾回收原理，然后基于此背景，引出 Android 开发中常见的内存泄漏问题，最后深入剖析业界流行的内存泄漏检测框架 LeakCanary 的工作原理，并介绍其基本使用方法。

第一部分：JVM 内存区域与分代模型

JVM 在运行时会将其管理的内存划分为不同的区域，其中与对象实例存储最相关的是堆 (Heap)。为了优化垃圾回收效率，HotSpot JVM（Android ART 虚拟机也借鉴了类似思想）通常会对堆内存进行分代管理。

堆内存主要分为以下两代：

1. 新生代 (Young Generation / New Generation)

• 用途: 绝大多数新创建的对象首先在这里分配。
• 特点: 对象生命周期短，GC 发生频繁但速度快（称为 Minor GC 或 Young GC）。
• 内部结构:
  • 伊甸园区 (Eden Space): 新对象的出生地。
  • 幸存者区 (Survivor Space): 分为两个等大的区域，From Survivor (S0) 和 To Survivor (S1)。
• GC 流程 (基于复制算法):
  1. Eden 区满，触发 Minor GC。
  2. 将 Eden 区和 From Survivor 区中的存活对象复制到 To Survivor 区。
  3. 清空 Eden 和 From Survivor 区。
  4. 交换 From 和 To Survivor 的角色。
  5. 对象每在 Survivor 区躲过一次 Minor GC，年龄加 1。达到晋升阈值 (Tenuring Threshold) 时，会被移动到老年代。
  6. 若 To Survivor 区不足以容纳所有存活对象，部分对象会直接晋升老年代。

2. 老年代 (Old Generation / Tenured Generation)

• 用途: 存放生命周期较长的对象（从新生代晋升而来）或一些无法在新生代分配的大对象。
• 特点: 对象生命周期长，GC 频率低，但单次耗时长（称为 Major GC 或 Full GC）。Full GC 通常会清理整个堆（包括新生代）甚至元空间，暂停时间（STW）较长。
• GC 算法: 通常采用标记-清除 (Mark-Sweep) 或 标记-整理 (Mark-Compact) 算法及其变种。

3. (非堆区) 元空间 (Metaspace) / 永久代 (PermGen)

• 用途: 存储类的元信息、常量池、静态变量等（JDK 版本不同，存储内容有差异）。
• 演进: JDK 8+ 使用元空间 (Metaspace)，位于本地内存 (Native Memory)，取代了之前的永久代 (PermGen)（位于 JVM 内存）。这解决了 PermGen 大小固定易 OOM 的问题。
• GC: 元空间本身也有 GC，其空间不足可能触发 Full GC。

第二部分：JVM 垃圾回收 (GC) 核心机制

GC 的目标是自动找出并回收不再使用的内存。

1. 如何判断对象已死？ - 可达性分析

现代 JVM 主流采用可达性分析 (Reachability Analysis) 算法。

• 思路: 从一系列称为 “GC Roots” 的根对象集合出发，沿着引用链进行搜索。如果一个对象到任何 GC Root 之间没有可达路径，则判定该对象为不可达 (Unreachable)，即为垃圾。
• GC Roots 示例:
  • 虚拟机栈中引用的对象 (方法局部变量)。
  • 类静态属性引用的对象。
  • 常量引用的对象。
  • 本地方法栈 JNI 引用的对象。
  • 活跃线程。
  • 被 synchronized 持有的锁对象。

2. 如何回收垃圾？ - 常见 GC 算法

确定垃圾后，需要算法来回收空间：

• 标记-清除 (Mark-Sweep):
  • 标记存活对象，然后清除未标记的垃圾对象。
  • 优点: 简单。
  • 缺点: 产生内存碎片，效率不高。
• 复制 (Copying):
  • 将内存分两半，只用一半。GC 时将存活对象复制到另一半，清空当前半。
  • 优点: 高效，无碎片。
  • 缺点: 空间利用率低 (一半浪费)。适用于新生代 (对象存活率低)。
• 标记-整理 (Mark-Compact):
  • 标记存活对象，然后将所有存活对象移动到一端，清理掉边界外的内存。
  • 优点: 无碎片。
  • 缺点: 移动对象成本高 (需更新引用)，需要 STW (Stop-The-World)。适用于老年代。

第三部分：Android 中的内存泄漏问题

有了 JVM/ART 的自动 GC，为什么还会发生内存泄漏？

Android (Java) 内存泄漏：指逻辑上不再需要使用的对象，由于仍然被至少一个有效的强引用链连接到 GC Roots，导致垃圾回收器无法将其回收，从而持续占用内存。

换句话说，泄漏的对象对于 GC 来说是可达的 (Reachable)，GC 不认为它是垃圾。问题出在程序的逻辑错误，保留了不该保留的引用。

常见 Android 泄漏场景与原因

• 静态 Context 引用: 静态变量生命周期与应用进程相同。若持有 Activity 或 Service 的 Context，在其销毁后无法被回收。
  // Bad: Static variable holding Activity context
  private static Context sContext;
  void setStaticContext(Context context) { sContext = context; } // If context is an Activity, it leaks!

• 非静态内部类/匿名类持有外部类引用:
  • Handler、Thread、AsyncTask 等实例默认持有其外部类 (如 Activity) 的引用。如果它们执行耗时操作，且生命周期长于外部类，会导致外部类无法回收。
  // Bad: Non-static Handler in Activity
  private Handler mHandler = new Handler() {
      @Override public void handleMessage(Message msg) { /* ... */ }
  };
  // If mHandler posts a delayed message and Activity finishes before message is processed, Activity leaks.

• 资源未释放/注销:
  • BroadcastReceiver 未 unregisterReceiver()。
  • Cursor 未 close()。
  • 文件/网络流未 close()。
  • 监听器 (Listener) 未在合适时机移除。
• 集合类持有废弃对象: 向 List, Map 等添加对象后，忘记在对象不再需要时 remove()。

内存泄漏的危害

• 可用内存减少: 逐步蚕食可用堆内存。
• 频繁 GC: 内存紧张导致更频繁的 GC，尤其是耗时的 Full GC。
• 应用卡顿: Full GC 导致的 STW 时间变长，用户界面无响应。
• OOM (OutOfMemoryError): 最终耗尽堆内存，导致应用崩溃。

第四部分：LeakCanary - 内存泄漏检测利器

LeakCanary 是 Square 开源的一个强大的 Android 内存泄漏自动检测库。它能在开发阶段（Debug 构建）帮助我们发现并定位内存泄漏问题。

LeakCanary 工作原理

其核心原理可以总结为：利用 WeakReference 和 ReferenceQueue 监控对象回收状态，在对象预期被回收但未被回收时，触发 Heap Dump 并分析泄漏路径。

1. 对象监视 (Watch):

   • LeakCanary 通过 Application.ActivityLifecycleCallbacks 自动监视 Activity 的 onDestroy() 回调，以及类似机制监视 Fragment 的销毁。
   • 当这些组件即将销毁（逻辑生命周期结束）时，调用 ObjectWatcher.watch() 将该对象实例加入监视列表。

2. 弱引用与引用队列:

   • 对每个被监视的对象 obj，创建一个指向它的 WeakReference<Object> weakRef = new WeakReference<>(obj, referenceQueue)。
   • 这里的 referenceQueue 是一个全局的 ReferenceQueue。
   • 关键: WeakReference 不阻止 obj 被 GC 回收。如果 GC 决定回收 obj，在回收动作发生前，JVM 会将 weakRef 这个弱引用对象本身放入 referenceQueue。

3. 延迟检查与 GC 触发:

   • watch() 后，LeakCanary 并不会立即判定泄漏。它会记录下这个 weakRef 和一个唯一 key。
   • 启动一个后台延迟任务（默认 5 秒后执行检查）。
   • 在这期间，LeakCanary 会尝试触发一次 GC (Runtime.getRuntime().gc())，增加对象被回收的机会（注意：这只是建议 GC，不保证执行）。
   • 然后，检查 referenceQueue 中是否出现了与被监视对象关联的 weakRef。

4. 判断泄漏与 Heap Dump:

   • 情况 A (正常): 如果在延迟结束前，从 referenceQueue 中取到了 weakRef，说明 obj 已被 GC 回收。任务结束。
   • 情况 B (疑似泄漏): 如果延迟时间到，referenceQueue 中仍未出现 weakRef，则强烈怀疑 obj 发生了内存泄漏（它本该被回收，但似乎没有）。
   • 此时，LeakCanary 会执行 Heap Dump 操作，将当前时刻 JVM 堆内存的快照保存到一个 .hprof 文件中。这是一个重量级操作，会冻结应用。

5. 堆分析 (Heap Analysis):

   • LeakCanary 会在单独的进程中启动分析器（如 Shark）来处理 .hprof 文件，避免影响应用主进程。
   • 分析器在 Heap Dump 中：
     • 找到那个被怀疑泄漏的对象实例。
     • 从该实例出发，反向查找到达 GC Roots 的最短强引用路径 (Shortest Strong Reference Path)。

6. 结果报告:

   • 如果找到了这样一条强引用路径，就确认了内存泄漏。
   • LeakCanary 会将这条路径（称为 Leak Trace）格式化，并通过系统通知展示出来。
   • Leak Trace 清晰地显示了从 GC Root 到泄漏对象的完整引用链，开发者可以据此精准定位问题代码。

LeakCanary 原理流程图

第五部分：LeakCanary 使用入门

在 Android 项目中集成和使用 LeakCanary 非常简单：

1. 添加依赖: 在你的 app/build.gradle 文件中添加 LeakCanary 的依赖（请使用最新版本）：

   // Groovy DSL (build.gradle)
   dependencies {
     // debugImplementation because LeakCanary should only run in debug builds.
     debugImplementation 'com.squareup.leakcanary:leakcanary-android:{{2.12}}' // 请替换为最新版本号, e.g., 2.12
   }

   // Kotlin DSL (build.gradle.kts)
   dependencies {
     // debugImplementation because LeakCanary should only run in debug builds.
     debugImplementation("com.squareup.leakcanary:leakcanary-android:{{2.12}}") // 请替换为最新版本号, e.g., 2.12
   }

2. 自动初始化: 从 LeakCanary 2 开始，无需在 Application 类中进行任何手动初始化。它通过 ContentProvider 自动完成初始化工作。

3. 运行应用 (Debug模式): 以 Debug 模式构建并运行你的应用。正常使用应用，触发你怀疑可能泄漏的场景（比如反复进入退出某个 Activity）。

4. 观察通知: 如果 LeakCanary 检测到内存泄漏，它会在设备状态栏显示一个通知。点击通知可以查看详细的 Leak Trace。

5. 解读 Leak Trace: Leak Trace 是定位问题的关键。它会显示从 GC Root 到泄漏对象的引用链，每一级引用关系都会标明：

   • 持有引用的类 (e.g., MainActivity)
   • 引用的字段名 (e.g., mLeakyHandler)
   • 被引用的对象类型 (e.g., LeakyHandler) 通过分析这个链条，找到那个不该存在的引用，并修复它（例如，将内部类改为静态内部类并使用 WeakReference 持有外部类，或在 onDestroy 中清除引用/注销监听）。

总结

理解 JVM 的内存分代管理和垃圾回收机制是诊断内存问题的基础。Android 中的内存泄漏本质是逻辑错误导致对象生命周期异常延长，使得 GC 无法回收。LeakCanary 通过巧妙运用 WeakReference、ReferenceQueue 和自动化的 Heap Dump 分析，提供了一个强大的武器来发现这些隐藏的泄漏。掌握 LeakCanary 的原理和使用，结合对 JVM 内存管理的理解，能显著提升我们开发高质量 Android 应用的能力。