Android 非静态内部类导致内存泄漏原因深入剖析
背景
上周发现蘑菇街IM-Android代码里面,一些地方代码编写不当,存在内存泄漏的问题,在和疯紫交流的过程中,发现加深了一些理解,所以决定写一下分析思路,相互学习。
内存泄漏
一个不会被使用的对象,因为另一个正在使用的对象持有该对象的引用,导致它不能正常被回收,而停留在堆内存中。
内存泄漏的危害
最坏的情况,App可能会因为大量的内存泄漏而导致内存耗尽,引发Crash,如果内存未耗尽,App也会犹豫内存空间不足,出现频繁的GC(垃圾回收),每次一出GC都是非常耗时的阻塞性操作,会造成设备非常严重的卡顿,给用户的体验就是,手机无论做什么操作,都是卡的,这也是android设备玩久了之后常见的现象。
泄漏代码(案例)
在sendGoodsMessage方法中,使用了一个非静态匿名内部类IMValueCallback,而这个非静态匿名内部类对其外部类存在一个隐式引用
,其外部类在销毁之前,如果该非静态内部类的sendMessage异步任务还未完成,将会导致外部类的内存资源无法正常释放,造成了内存泄漏。
所以这个问题总结为: 非静态内部类中线程生命周期不可控,能否正常回收完全由线程的生命周期决定。如果线程是永久运行的,那么将永远无法释放,因为在Java中线程是垃圾回收机制的根源,在运行系统中DVM虚拟机总会硬件持有所有运行状态的进程的引用,结果导致处于运行状态的线程将永远不会被回收。
非静态内部类还有一种的情况的内存泄漏
非静态内部类中创建了一个静态实例,导致该实例的生命周期和应用ClassLoader级别,又因为该静态实例又会隐式持有其外部类的引用,所以导致其外部类无法正常释放,出现了泄漏问题。
深入分析
针对非静态内部类引发的内存泄漏这个点,进行深入分析
- 为什么非静态内部类对外部类会存在一个隐式引用?
- 为什么非静态内部类中存在异步任务,可能会导致其对应的外部类内存资源无法正常释放?
- 为什么非静态内部类中创建了一个静态实例,会导致内存泄漏?
深入剖析-隐式引用
为什么在非静态匿名内部类中,我们可以访问到外部类的testMethod方法?这就是隐式引用的作用。
通过编写一个简单的测试代码,进行深入的分析
非静态匿名内部类的源码和编译后的字节码
args_size:这个代表着隐式引用的个数, 可以看出非静态匿名内部类中确实持有外部类的引用。
非静态内部类的源码和编译后的字节码
静态内部类的源码和编译后的字节码
结论:非静态内部类和非静态匿名内部类中确实都持有外部类的引用, 静态内部类中未持有外部类的引用
那么这个引用是从何而来的?
可以通过蘑菇街线上代码进行反编译,我找了一个比较有代表性的代码,分析一下:
反编译线上版本, c.class 这个就是MessagePresender类的字节码
可以发现,在编译器编译过程中,帮我们隐式的传入了this这个参数,这也是为什么,我们平时在方法中能使用this这个关键字的原因。
了解了隐式引用,那么为什么它会是导致内存泄漏的根本原因? 这里又得说明一下,虚拟机的垃圾回收策略。
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等等造成的泄漏,也是能融会贯通的,只要大家多想一下它们之间的引用关系即可。
转自:http://blog.csdn.net/linyukun6422/article/details/52514447