2. 内存泄漏的定义与危害：深入理解内存泄漏原理及其对应用性能的影响
2.1 到底什么是内存泄漏？
说实话，我见过不少开发者把内存泄漏和内存溢出搞混。这两者有关系，但定义完全不同。
内存泄漏，说白了就是：一块内存被分配后，程序已经不再需要它了，但GC（垃圾回收器）却无法把它回收掉。它还被某个“活着的”对象引用着，所以GC认为它“还有用”，于是它就一直霸占着堆空间。
你想想看，这种“僵尸对象”会随着时间越积越多。它们不干活，却占着茅坑不拉屎。最终导致可用堆空间越来越少，GC不得不频繁触发回收——这就是性能崩盘的开始。
2.2 内存泄漏的经典产生场景
我在项目中排查过上百个泄漏案例，大部分逃不出下面这几类。记住它们，你至少能躲开80%的坑。
| 场景 | 典型表现 | 根因 |
|---|---|---|
| 静态集合持有对象 | Activity/Fragment 无法被回收 | static 变量持有了 Activity 引用，生命周期错配 |
| 内部类 / 匿名类持有外部引用 | Handler、Thread、AsyncTask 造成泄漏 | 非静态内部类隐式持有外部类实例 |
| 注册监听器未反注册 | BroadcastReceiver、EventBus 注册后忘记移除 | 观察者模式中引用链未被剪断 |
| 资源对象未关闭 | Cursor、Stream、Bitmap、Socket 耗尽 | 未调用 close() / recycle() / release() |
| 单例模式持有短生命周期对象 | 大型单例保存了 Context（尤其是 Activity） | 单例生命周期 = 进程生命周期 > Activity 生命周期 |
我曾经接手过一个项目，首页的列表越滑越卡，最终必崩。一查堆转储——一个 static 的 ArrayList 里存了几百个泄漏的 Fragment。这还只是冰山一角。
2.3 内存泄漏的危害：从“微卡”到“闪退”
很多开发者觉得“稍微漏一点没事”。我最初也这么想，直到一个线上版本因为泄漏导致崩溃率飙升到3%……老板差点让我走人。
来看一下泄漏带来的连锁效应：
- 堆空间膨胀 —— 无用对象挤占有效内存，可用堆容量不断缩小。
- GC 频率暴增 —— 系统为了腾出空间，不断触发 Young GC 甚至 Full GC。GC 会暂停所有线程（Stop-The-World），造成肉眼可见的卡顿。
- 抖动与帧率下降 —— 特别是 Android 平台，16ms 内完不成一帧渲染，掉帧、冻屏就来了。
- OOM（OutOfMemoryError） —— 当堆被泄漏占满，连新对象都分配不了，应用直接闪退。
- 电量消耗加剧 —— 频繁 GC 和内存交换导致 CPU 持续高负载，手机发热、掉电快。
2.4 从原理层面看：GC 为什么“看不到”泄漏对象
要理解为什么泄漏对象逃不过GC，得先明白Java/Android的GC根（GC Roots）机制。
GC Roots 包括：
- 栈帧中的本地变量
- 静态变量
- 活跃线程
- JNI 全局引用
- 系统类加载器等
GC 从这些根出发，沿着引用链遍历。凡是能到达的对象都是“存活”的，不能到达的就是垃圾。但泄漏对象的特点正好是：它明明应该死了，却因为被某个GC Roots（比如一个static变量）间接引用着，所以活着。
// 一个典型的泄漏案例
public class MainActivity extends AppCompatActivity {
private static List<Object> leakList = new ArrayList<>();
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
// 重点：匿名内部类持有 Activity 引用
new Thread(new Runnable() {
@Override
public void run() {
while (true) {
// 模拟耗时操作
SystemClock.sleep(1000);
// 这个 Runnable 隐式持有 MainActivity.this
// 虽然 run() 永远不会结束，但 Activity 被它引用着
}
}
}).start();
// 更糟糕的是，还有 static 集合
leakList.add(new Object());
}
}上面这段代码，泄漏了三条引用链：
- Thread 对象 → 其 target 属性是 Runnable → Runnable 持有外部 Activity 引用
- static 集合 leakList 一直存活 → 其中的 Object 对象无法释放
- 如果 Thread 在 Activity 销毁后仍继续运行，Activity 永远无法被回收
2.5 泄漏性能影响的量化指标
我习惯用这几个指标来评估泄漏严重程度。你在做性能监控时可以照着看：
| 指标 | 健康值 | 警戒值 | 危险值 |
|---|---|---|---|
| GC 次数/分钟（Young GC） | < 10 | 10 ~ 30 | > 30 |
| GC 暂停总时长/分钟 | < 200ms | 200ms ~ 500ms | > 500ms |
| 堆使用率（活跃对象占比） | > 70% | 50% ~ 70% | < 50% （大量泄漏） |
| OOM 崩溃率（每千用户） | < 0.01% | 0.01% ~ 0.1% | > 0.1% |
2.6 一张图看懂内存泄漏的完整链条
下面这张图把泄漏从产生到崩溃的路径画清楚了。你可以把它贴在工作站旁边，每次写代码时扫一眼提醒自己。
2.7 我如何判断一个对象“该不该被回收”
最后分享一个思考框架。每当我在 code review 中看到可疑的引用，我就会问自己三个问题：
- 这个对象的生命周期应该多长？ 比如 Activity 的生命周期就是 onDestroy 结束。
- 它被谁引用了？ 这个“引用者”的生命周期比它长吗？如果更长，就危险。
- 有没有办法剪断这条引用链？ 比如用弱引用、在 onDestroy 里置 null、反注册等。
这三个问题能解决90%的泄漏判断。记住：生命周期错配是内存泄漏的根源。