【知识必备】内存泄漏全解析,从此拒绝ANR,让OOM远离你的身边,跟内存泄漏say byebye

时间:2023-03-08 16:25:03
【知识必备】内存泄漏全解析,从此拒绝ANR,让OOM远离你的身边,跟内存泄漏say byebye

*本篇文章已授权微信公众号 guolin_blog (郭霖)独家发布

一、写在前面

  对于C++来说,内存泄漏就是new出来的对象没有delete,俗称野指针;而对于java来说,就是new出来的Object放在Heap上无法被GC回收;而这里就把我之前的一篇内存泄漏的总结翻新,做一个更加全面规范的讲解,希望能帮到各位。

二、一些杂谈

  1、这里先安利一下java的内存分配:

    a)  静态存储区:编译时就分配好,在程序整个运行期间都存在。它主要存放静态数据和常量;

    b)  栈区:当方法执行时,会在栈区内存中创建方法体内部的局部变量,方法结束后自动释放内存;

    c)  堆区:通常用来存放new出来的对象。由java垃圾回收期回收。

  2、四种引用类型的介绍

    a)  强引用(StrongReference):JVM 宁可抛出 OOM ,也不会让 GC 回收具有强引用的对象;

    b)  软引用(SoftReference):只有在内存空间不足时,才会被回的对象;

    c)  弱引用(WeakReference):在 GC 时,一旦发现了只具有弱引用的对象,不管当前内存空间足够与否,都会回收它的内存;

    d)  虚引用(PhantomReference):任何时候都可以被GC回收,当垃圾回收器准备回收一个对象时,如果发现它还有虚引用,就会在回收对象的内存之前,把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否存在该对象的虚引用,来了解这个对象是否将要被回收。可以用来作为GC回收Object的标志。

  3、内存抖动,这样的图很熟悉有木有?当这样的时候,说明你的内存真的在变少了。

  【知识必备】内存泄漏全解析,从此拒绝ANR,让OOM远离你的身边,跟内存泄漏say byebye

  

三、内存泄漏检测工具

  在这里先推荐两种内存检查的方式:

  • MAT(Memory Analyzer Tool),点我下载。具体使用这个网上一大篇,楼主一有时间也会为大家一步步奉上。
  • 强大的开源内存检测工具LeakCanary。

leakcanary是一个开源项目,一个内存泄露自动检测工具,是著名的GitHub开源组织Square贡献的,它的主要优势就在于自动化过早的发觉内存泄露、配置简单、抓取贴心,缺点在于还存在一些bug,不过正常使用百分之九十情况是OK的,其核心原理与MAT工具类似。

因为配置十分简单,只需要几句话就好!!!这里就不多说了,大家可以看官方文档,简单直白。

四、内存泄漏解析 

1)永远的Singleton

单例的使用在我们的程序中随处可见,因为使用它可以完美的解决我们在程序中重复创建对象的问题,不过可别小瞧它。由于单例的静态特性,使得它的生命周期和应用的生命周期会一样长,所以一旦使用有误,小心无限制的持有Activity的引用而导致内存泄漏。比如,下面的例子。

 package com.example.nanchen.anrsolutiondemo.singleton;

 import android.content.Context;

 /**
* @author nanchen
* @fileName ANRSolutionDemo
* @packageName com.example.nanchen.anrsolutiondemo.singleton
* @date 2016/09/23 11:27
*/
public class SingletonBad {
private static SingletonBad singletonBad;
private Context context; private SingletonBad(Context context){
this.context = context;
} public static SingletonBad getInstance(Context context){
if (singletonBad == null){
singletonBad = new SingletonBad(context);
}
return singletonBad;
}
}

这个错误在生活中再普遍不过,很正常的一个单例模式,可就由于传入的是一个Context,而这个Context的生命周期的长短就尤为重要了。如果我们传入的是Activity的Context,当这个Context所对应的Activity退出的时候,由于该Context的引用被单例对象所持有,其生命周期等于整个应用程序的生命周期,所以当前Activity退出时它的内存并不会回收,这造成的内存泄漏就可想而知了。

正确的方式应该是把传入的Context换为和应用的生命周期一样长的Application的Context;

 package com.example.nanchen.anrsolutiondemo.singleton;

 import android.content.Context;

 /**
* @author nanchen
* @fileName ANRSolutionDemo
* @packageName com.example.nanchen.anrsolutiondemo.singleton
* @date 2016/09/23 11:29
*/
public class SingletonGood {
private static SingletonGood singletonGood;
private Context context; private SingletonGood(Context context){
this.context = context.getApplicationContext();//获取Application的context避免内存泄漏
} public static SingletonGood getInstance(Context context){
if (singletonGood == null){
singletonGood = new SingletonGood(context);
}
return singletonGood;
}
}

当然,你也可以直接连Context都不用传入了。重写application,提供静态的getContext方法

 package com.example.nanchen.anrsolutiondemo.singleton;

 import android.app.Application;
import android.content.Context; /**
* @author nanchen
* @fileName ANRSolutionDemo
* @packageName com.example.nanchen.anrsolutiondemo.singleton
* @date 2016/09/23 11:32
*/
public class DemoApplication extends Application {
private static DemoApplication demoApplication; public static DemoApplication getInstance(){
return demoApplication;
} public static Context getContext(){
return demoApplication.getApplicationContext();
} @Override
public void onCreate() {
super.onCreate();
demoApplication = this;
}
}

自然就可以直接不用传入Context

 package com.example.nanchen.anrsolutiondemo.singleton;

 import android.content.Context;

 /**
* @author nanchen
* @fileName ANRSolutionDemo
* @packageName com.example.nanchen.anrsolutiondemo.singleton
* @date 2016/09/23 11:32
*/
public class SingletonGoodNew {
private static SingletonGoodNew singletonGoodNew; private Context context; private SingletonGoodNew(){
this.context = DemoApplication.getContext();
} public static SingletonGoodNew getInstance(){
if (singletonGoodNew == null){
singletonGoodNew = new SingletonGoodNew();
}
return singletonGoodNew;
}
}

2)令人心塞的Handler

这个东西在我最近遇到的最多了,而它也是我们在内存泄漏中最为常见的,也许你的一个小忽略就会导致内存泄漏。在android的新版本中,我们被要求必须把网络任务等耗时操作置于新线程来处理,我们通常会采用Handler。但Handler不是万能的,若是我们的编写不规范就有可能会造成内存泄漏。另外,我们知道,Handler、Message和MessageQueue都是相互关联在一起的,万一Handler发送的Message尚未被处理,则该Message及发送它的Handler对象将会被线程MessageQueue一直持有。

由于Handler属于TLS(Thread Local Storage)变量,生命周期和Activity是不一致的。因此这种实现方式一般很难保证跟View或者Activity的生命周期一致,故很容易导致无法正确释放。比如:

 package com.example.nanchen.anrsolutiondemo.handler;

 import android.os.Bundle;
import android.os.Handler;
import android.os.Message;
import android.support.v7.app.AppCompatActivity; import com.example.nanchen.anrsolutiondemo.R; public class HandlerBadActivity extends AppCompatActivity { private final Handler handler = new Handler(){
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
}
}; @Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_handler_bad); // 延迟10s发送一个消息
handler.postDelayed(new Runnable() {
@Override
public void run() {
// write something
}
},1000*60*5); this.finish();
}
}

在例子中,我们申明了一个延迟5分钟执行的消息Message。当该Activity被finish的时候,延迟任务的Message还存在于主线程中,它持有该Activity的Handler引用,所以此时Finish掉的Activity就不会回收了,所以造成了内存泄漏(因handler为非静态内部类,它会持有外部类的引用,在这里就是当前的Activity)。

修复:这个解决也是可以通过把其声明为static的,则其存活期就跟activity的生命周期无关了。不过倘若用到Context等外部类的非static对象,还是应该通过弱引用传入。比如:

 package com.example.nanchen.anrsolutiondemo.handler;

 import android.os.Bundle;
import android.os.Handler;
import android.os.Message;
import android.support.v7.app.AppCompatActivity; import com.example.nanchen.anrsolutiondemo.R; import java.lang.ref.WeakReference; public class HandlerGoodActivity extends AppCompatActivity { private static final class MyHandler extends Handler{
private final WeakReference<HandlerGoodActivity> mActivity; public MyHandler(HandlerGoodActivity activity){
this.mActivity = new WeakReference<HandlerGoodActivity>(activity);//使用弱引用
} @Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
HandlerGoodActivity activity = mActivity.get();
if (activity != null){
// write something
}
}
} private final MyHandler myHandler = new MyHandler(this); // 匿名内部类在static的时候绝对不会持有外部类的引用
private static final Runnable RUNNABLE = new Runnable() {
@Override
public void run() { }
}; @Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_handler_good); myHandler.postDelayed(RUNNABLE,1000*60*5);
}
}

综述:推荐使用静态内部类+弱引用WeakReference这种方式,但要注意每次使用前判空。

说到若引用,这里再提下java的几种引用类型:Strong reference,SoftReference,WeakReference和PhatomReference

【知识必备】内存泄漏全解析,从此拒绝ANR,让OOM远离你的身边,跟内存泄漏say byebye

在android开发中,为了防止内存溢出,在处理一些占用内存大并且生命周期较长的对象的时候,可以尽量地使用软引用和弱引用技术。

比如,保存Bitmap的软引用到HashMap。

 package com.example.nanchen.anrsolutiondemo.photo;

 import android.graphics.Bitmap;
import android.graphics.BitmapFactory; import java.lang.ref.SoftReference;
import java.util.HashMap; /**
* @author nanchen
* @fileName ANRSolutionDemo
* @packageName com.example.nanchen.anrsolutiondemo.photo
* @date 2016/09/23 11:58
*/
public class CacheBySoftRef { // 首先定义一个HashMap,保存软应用对象
private HashMap<String,SoftReference<Bitmap>> imageCache = new HashMap<>();
// 再来定义一个方法,保存Bitmap的软引用到HashMap
public void addBitmapToCache(String path){
// 强引用的Bitmap对象
Bitmap bitmap = BitmapFactory.decodeFile(path);
// 软引用的Bitmap对象
SoftReference<Bitmap> softBitmap = new SoftReference<Bitmap>(bitmap);
// 添加该对象到Map使其缓存
imageCache.put(path,softBitmap);
} // 获取的时候,可以通过SoftReference的get()的方法得到Bitmap对象
public Bitmap getBitmapByPath(String path){
// 从缓存中取软引用的Bitmap对象
SoftReference<Bitmap> softBitmap = imageCache.get(path);
// 判断是否存在软引用
if (softBitmap == null){
return null;
}
// 通过软引用取出Bitmap对象,如果由于内存不足Bitmap被回收,则取得空;
// 如果未被回收,则可重复使用,提高速度
Bitmap bitmap = softBitmap.get();
return bitmap;
}
}

使用软引用以后,在OutOfMemory异常发生之前,这些缓存的图片资源的内存空间可以被释放掉的,从而避免内存达到上限,避免Crash发生。

如果只是想避免OutOfMemory异常的发生,则可以使用软引用。如果对于应用的性能更在意,想尽快回收一些占用内存比较大的对象,则可以使用弱引用。

另外可以根据对象是否经常使用来判断选择软引用还是弱引用。如果该对象可能会经常使用的,就尽量用软引用。如果该对象不被使用的可能性更大些,就可以用弱引用。

ok,继续回到主题。前面所说的,创建一个静态Handler内部类,然后对 Handler 持有的对象使用弱引用,这样在回收时也可以回收 Handler 持有的对象,但是这样做虽然避免了 Activity 泄漏,不过 Looper 线程的消息队列中还是可能会有待处理的消息,所以我们在 Activity 的 Destroy 时或者 Stop 时应该移除消息队列 MessageQueue 中的消息。

下面几个方法都可以移除 Message:

【知识必备】内存泄漏全解析,从此拒绝ANR,让OOM远离你的身边,跟内存泄漏say byebye

3)匿名内部类/非静态内部类,它们方便却暗藏杀机

android开发经常会继承实现Activity或者Fragment或者View。如果你使用了匿名类,而又被异步线程所引用,那得小心,如果没有任何措施同样会导致内存泄漏的

 package com.example.nanchen.anrsolutiondemo.innerClass;

 import android.os.Bundle;
import android.support.v7.app.AppCompatActivity; import com.example.nanchen.anrsolutiondemo.R; public class MainActivity extends AppCompatActivity { private static TestInnerBad testInnerBad = null; class TestInnerBad{ } @Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_inner_bad); if (testInnerBad == null){
testInnerBad = new TestInnerBad();
} Runnable runnable1 = new MyRunnable();
Runnable runnable2 = new Runnable() {
@Override
public void run() { }
};
} private static class MyRunnable implements Runnable{ @Override
public void run() { }
} }

runnable1 和 runnable2的区别就是,runnable2使用了匿名内部类,我们看看引用时的引用内存

【知识必备】内存泄漏全解析,从此拒绝ANR,让OOM远离你的身边,跟内存泄漏say byebye

可以看到,runnable1是没有什么特别的。但runnable2多出了一个MainActivity的引用,若是这个引用再传入到一个异步线程,此线程在和Activity生命周期不一致的时候,也就造成了Activity的泄露。

4)前辈箴言——善用static成员变量

前面就很明显,当我们的成员变量是static的时候,那么它的生命周期将和整个app的生命周期一致。

这必然会导致一系列问题,如果你的app进程设计上是长驻内存的,那即使app切到后台,这部分内存也不会被释放。按照现在手机app内存管理机制,占内存较大的后台进程将优先回收,因为如果此app做过进程互保保活,那会造成app在后台频繁重启。当手机安装了你参与开发的app以后一夜时间手机被消耗空了电量、流量,你的app不得不被用户卸载或者静默。

这里修复的方法是:

不要在类初始时初始化静态成员。可以考虑lazy初始化(延迟加载)。架构设计上要思考是否真的有必要这样做,尽量避免。如果架构需要这么设计,那么此对象的生命周期你有责任管理起来。

5)远离非静态内部类和匿名类,多用private static class。

在我们的日常代码中,这样的情况似乎很常见,及直接写一个class就这么光秃秃的情况。

【知识必备】内存泄漏全解析,从此拒绝ANR,让OOM远离你的身边,跟内存泄漏say byebye

   

这样就在Activity内部创建了一个非静态内部类的单例,每次启动Activity时都会使用该单例的数据,这样虽然避免了资源的重复创建,不过这种写法却会造成内存泄漏,因为非静态内部类默认会持有外部类的引用,而该非静态内部类又创建了一个静态的实例,该实例的生命周期和应用的一样长,这就导致了该静态实例一直会持有该Activity的引用,导致Activity的内存资源不能正常回收。正确的做法为:

将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例,如果需要使用Context,请按照上面推荐的使用Application 的 Context。当然,Application 的 context 不是万能的,所以也不能随便乱用,对于有些地方则必须使用 Activity 的 Context,对于Application,Service,Activity三者的Context的应用场景如下:

【知识必备】内存泄漏全解析,从此拒绝ANR,让OOM远离你的身边,跟内存泄漏say byebye

其中: NO1表示 Application 和 Service 可以启动一个 Activity,不过需要创建一个新的 task 任务队列。而对于 Dialog 而言,只有在 Activity 中才能创建

6) 集合对象善清除,以免内存泄漏触不及防

  我们通常会把一些对象的引用加入到集合容器(比如ArrayList)中,当我们不再需要该对象时,并没有把它的引用从集合中清理掉,这样这个集合就会越来越大。如果这个集合是static的话,那情况就更严重了。

  所以在退出程序之前,将集合里面的东西clear,然后置为null,再退出程序,如下:

 private List<String> nameList;
private List<Fragment> list; @Override
public void onDestroy() {
super.onDestroy();
if (nameList != null){
nameList.clear();
nameList = null;
}
if (list != null){
list.clear();
list = null;
}
}

7)webView虽火,内存泄漏却也火的其所

  当我们不再需要使用webView的时候,应该调用它的destory()方法来销毁它,并释放其占用的内存,否则其占用的内存长期也不能回收,从而造成内存泄漏。

  解决方案:

    为webView开启另外一个进程,通过AIDL与主线程进行通信,webView所在的进程可以根据业务的需要选择合适的时机进行销毁,从而达到内存的完整释放。

  而另外一些诸如listView的Adapter没有缓存之类的这里就不再多提了。

8)做一个小的总结

  • 构造Adapter时,没有使用缓存的 convertView
  • Bitmap对象不在使用时调用recycle()释放内存
  • Context使用不当造成内存泄露:不要对一个Activity Context保持长生命周期的引用。尽量在一切可以使用应用ApplicationContext代替Context的地方进行替换。
  • 非静态内部类的静态实例容易造成内存泄漏:即一个类中如果你不能够控制它其中内部类的生命周期(譬如Activity中的一些特殊Handler等),则尽量使用静态类和弱引用来处理(譬如ViewRoot的实现)。
  • 警惕线程未终止造成的内存泄露;譬如在Activity中关联了一个生命周期超过Activity的Thread,在退出Activity时切记结束线程。一个典型的例子就是HandlerThread的run方法是一个死循环,它不会自己结束,线程的生命周期超过了Activity生命周期,我们必须手动在Activity的销毁方法中中调运thread.getLooper().quit();才不会泄露。
  • 对象的注册与反注册没有成对出现造成的内存泄露;譬如注册广播接收器、注册观察者(典型的譬如数据库的监听)等。
  • 创建与关闭没有成对出现造成的泄露;譬如Cursor资源必须手动关闭,WebView必须手动销毁,流等对象必须手动关闭等。
  • 不要在执行频率很高的方法或者循环中创建对象(比如onmeasure),可以使用HashTable等创建一组对象容器从容器中取那些对象,而不用每次new与释放。
  • 避免代码设计模式的错误造成内存泄露;譬如循环引用,A持有B,B持有C,C持有A,这样的设计谁都得不到释放。

五、真相只有一个

  内存泄漏实在太普遍了,真是防不胜防。不过我想告诉广大的小伙伴,程序员嘛,谁还不踩个坑,跳出来,拍拍身上的灰尘,总结一下,过两天又是一条帮帮的coder。你可以的。

————————————————————————————————————————————————————————————

2017-03-21 补充  增对软/弱引用的说明

资源来自 https://developer.android.com/topic/performance/graphics/cache-bitmap.html(Google官网,你可能需要*)

在 Google 官网介绍中,有这样一段话。

【知识必备】内存泄漏全解析,从此拒绝ANR,让OOM远离你的身边,跟内存泄漏say byebye

大意是说,从API 9 开始,垃圾收集器会更积极收集软/弱引用,使软/弱引用相当无效。而且在API 3 之前,位图的备份数据存储在本地内存中,该内存不以可预测的方式释放,可能导致应用程序短暂超出其内存限制和崩溃。