Android 非静态内部类导致内存泄漏原因深入剖析

背景

上周发现蘑菇街IM－Android代码里面。一些地方代码编写不当。存在内存泄漏的问题。在和疯紫交流的过程中。发现加深了一些理解，所以决定写一下分析思路，相互学习。

内存泄漏

一个不会被使用的对象。由于另一个正在使用的对象持有该对象的引用。导致它不能正常被回收，而停留在堆内存中。

内存泄漏的危害

最坏的情况，App可能会由于大量的内存泄漏而导致内存耗尽。引发Crash，假设内存未耗尽，App也会犹豫内存空间不足，出现频繁的GC（垃圾回收），每次一出GC都是很耗时的堵塞性操作，会造成设备很严重的卡顿，给用户的体验就是，手机不管做什么操作。都是卡的。这也是Android设备玩久了之后常见的现象。

泄漏代码（案例）

在sendGoodsMessage方法中，使用了一个非静态匿名内部类IMValueCallback，而这个非静态匿名内部类对其外部类存在一个隐式引用，其外部类在销毁之前，假设该非静态内部类的sendMessage异步任务还未完毕。将会导致外部类的内存资源无法正常释放。造成了内存泄漏。

所以这个问题总结为：非静态内部类中线程生命周期不可控，是否能正常回收全然由线程的生命周期决定。假设线程是永久执行的，那么将永远无法释放，由于在Java中线程是垃圾回收机制的根源，在执行系统中DVM虚拟机总会硬件持有全部执行状态的进程的引用，结果导致处于执行状态的线程将永远不会被回收。

非静态内部类另一种的情况的内存泄漏

非静态内部类中创建了一个静态实例。导致该实例的生命周期和应用ClassLoader级别，又由于该静态实例又会隐式持有其外部类的引用，所以导致其外部类无法正常释放，出现了泄漏问题。

深入分析

针对非静态内部类引发的内存泄漏这个点。进行深入分析

为什么非静态内部类对外部类会存在一个隐式引用？
为什么非静态内部类中存在异步任务。可能会导致其相应的外部类内存资源无法正常释放？
为什么非静态内部类中创建了一个静态实例，会导致内存泄漏？

深入剖析－隐式引用

为什么在非静态匿名内部类中，我们能够訪问到外部类的testMethod方法？这就是隐式引用的作用。

通过编写一个简单的測试代码，进行深入的分析

非静态匿名内部类的源代码和编译后的字节码

args_size：这个代表着隐式引用的个数。能够看出非静态匿名内部类中确实持有外部类的引用。

非静态内部类的源代码和编译后的字节码

静态内部类的源代码和编译后的字节码

结论：非静态内部类和非静态匿名内部类中确实都持有外部类的引用。静态内部类中未持有外部类的引用

那么这个引用是从何而来的？

能够通过蘑菇街线上代码进行反编译，我找了一个比較有代表性的代码，分析一下：

反编译线上版本号。 c.class 这个就是MessagePresender类的字节码

能够发现。在编译器编译过程中，帮我们隐式的传入了this这个參数，这也是为什么。我们平时在方法中能使用this这个keyword的原因。

了解了隐式引用。那么为什么它会是导致内存泄漏的根本原因？这里又得说明一下，虚拟机的垃圾回收策略。

java垃圾回收机制

垃圾回收机制：Java採用根搜索算法，当GC Roots不可达时。而且对象finalize没有自救的情况下，才会回收。

回收对象：GC会收集那些不是GC roots且没有被GC roots引用的对象。

(图片来自网络：http://www.infoq.com/cn/articles/jvm-memory-collection)

而这些引用就是对象之间的连线。垃圾回收的判定条件就在这些连线上，更具体的说明就不在这里描写叙述，有兴趣的自行Google。或者查阅《深入理解Java虚拟机》。

解决方式

通过上述的分析，要预防非静态内部类的泄漏问题，就得管理好对象间的引用关系。

解决思路

去除隐式引用（通过静态内部类来去除隐式引用）
手动管理对象引用（改动静态内部类的构造方式。手动引入其外部类引用）
当内存不可用时，不执行不可控代码（Android能够结合智能指针，WeakReference包裹外部类实例）

最后

并非全部的内部类仅仅能使用静态内部类。仅仅有在该内部类中的生命周期不可控制的情况下，我们要採用静态内部类，其他时候大家能够照旧。

假设了解了这些，比方Context、Handler、Timer、静态Acitivity、静态View、Thread等等造成的泄漏，也是能融会贯通的，仅仅要大家多想一下它们之间的引用关系就可以。