zoukankan      html  css  js  c++  java
  • 【知识必备】内存泄漏全解析,从此拒绝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、内存抖动,这样的图很熟悉有木有?当这样的时候,说明你的内存真的在变少了。

      

      

    三、内存泄漏检测工具

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

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

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

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

    四、内存泄漏解析 

    1)永远的Singleton

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

     1 package com.example.nanchen.anrsolutiondemo.singleton;
     2 
     3 import android.content.Context;
     4 
     5 /**
     6  * @author nanchen
     7  * @fileName ANRSolutionDemo
     8  * @packageName com.example.nanchen.anrsolutiondemo.singleton
     9  * @date 2016/09/23  11:27
    10  */
    11 public class SingletonBad {
    12     private static SingletonBad singletonBad;
    13     private Context context;
    14 
    15     private SingletonBad(Context context){
    16         this.context = context;
    17     }
    18 
    19     public static SingletonBad getInstance(Context context){
    20         if (singletonBad == null){
    21             singletonBad = new SingletonBad(context);
    22         }
    23         return singletonBad;
    24     }
    25 }

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

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

     1 package com.example.nanchen.anrsolutiondemo.singleton;
     2 
     3 import android.content.Context;
     4 
     5 /**
     6  * @author nanchen
     7  * @fileName ANRSolutionDemo
     8  * @packageName com.example.nanchen.anrsolutiondemo.singleton
     9  * @date 2016/09/23  11:29
    10  */
    11 public class SingletonGood {
    12     private static SingletonGood singletonGood;
    13     private Context context;
    14 
    15     private SingletonGood(Context context){
    16         this.context = context.getApplicationContext();//获取Application的context避免内存泄漏
    17     }
    18 
    19     public static SingletonGood getInstance(Context context){
    20         if (singletonGood == null){
    21             singletonGood = new SingletonGood(context);
    22         }
    23         return singletonGood;
    24     }
    25 }

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

     1 package com.example.nanchen.anrsolutiondemo.singleton;
     2 
     3 import android.app.Application;
     4 import android.content.Context;
     5 
     6 /**
     7  * @author nanchen
     8  * @fileName ANRSolutionDemo
     9  * @packageName com.example.nanchen.anrsolutiondemo.singleton
    10  * @date 2016/09/23  11:32
    11  */
    12 public class DemoApplication extends Application {
    13     private static DemoApplication demoApplication;
    14 
    15     public static DemoApplication getInstance(){
    16         return demoApplication;
    17     }
    18 
    19     public static Context getContext(){
    20         return demoApplication.getApplicationContext();
    21     }
    22 
    23     @Override
    24     public void onCreate() {
    25         super.onCreate();
    26         demoApplication = this;
    27     }
    28 }

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

     1 package com.example.nanchen.anrsolutiondemo.singleton;
     2 
     3 import android.content.Context;
     4 
     5 /**
     6  * @author nanchen
     7  * @fileName ANRSolutionDemo
     8  * @packageName com.example.nanchen.anrsolutiondemo.singleton
     9  * @date 2016/09/23  11:32
    10  */
    11 public class SingletonGoodNew {
    12     private static SingletonGoodNew singletonGoodNew;
    13 
    14     private Context context;
    15     
    16     private SingletonGoodNew(){
    17         this.context = DemoApplication.getContext();
    18     }
    19 
    20     public static SingletonGoodNew getInstance(){
    21         if (singletonGoodNew == null){
    22             singletonGoodNew = new SingletonGoodNew();
    23         }
    24         return singletonGoodNew;
    25     }
    26 }

    2)令人心塞的Handler

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

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

     1 package com.example.nanchen.anrsolutiondemo.handler;
     2 
     3 import android.os.Bundle;
     4 import android.os.Handler;
     5 import android.os.Message;
     6 import android.support.v7.app.AppCompatActivity;
     7 
     8 import com.example.nanchen.anrsolutiondemo.R;
     9 
    10 public class HandlerBadActivity extends AppCompatActivity {
    11 
    12     private final Handler handler = new Handler(){
    13         @Override
    14         public void handleMessage(Message msg) {
    15             super.handleMessage(msg);
    16         }
    17     };
    18 
    19     @Override
    20     protected void onCreate(Bundle savedInstanceState) {
    21         super.onCreate(savedInstanceState);
    22         setContentView(R.layout.activity_handler_bad);
    23 
    24         // 延迟10s发送一个消息
    25         handler.postDelayed(new Runnable() {
    26             @Override
    27             public void run() {
    28                 // write something
    29             }
    30         },1000*60*5);
    31 
    32         this.finish();
    33     }
    34 }

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

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

     1 package com.example.nanchen.anrsolutiondemo.handler;
     2 
     3 import android.os.Bundle;
     4 import android.os.Handler;
     5 import android.os.Message;
     6 import android.support.v7.app.AppCompatActivity;
     7 
     8 import com.example.nanchen.anrsolutiondemo.R;
     9 
    10 import java.lang.ref.WeakReference;
    11 
    12 public class HandlerGoodActivity extends AppCompatActivity {
    13 
    14     private static final class MyHandler extends Handler{
    15         private final WeakReference<HandlerGoodActivity> mActivity;
    16 
    17         public MyHandler(HandlerGoodActivity activity){
    18             this.mActivity = new WeakReference<HandlerGoodActivity>(activity);//使用弱引用
    19         }
    20 
    21         @Override
    22         public void handleMessage(Message msg) {
    23             super.handleMessage(msg);
    24             HandlerGoodActivity activity = mActivity.get();
    25             if (activity != null){
    26                 // write something
    27             }
    28         }
    29     }
    30 
    31     private final MyHandler myHandler = new MyHandler(this);
    32 
    33     // 匿名内部类在static的时候绝对不会持有外部类的引用
    34     private static final Runnable RUNNABLE = new Runnable() {
    35         @Override
    36         public void run() {
    37 
    38         }
    39     };
    40 
    41     @Override
    42     protected void onCreate(Bundle savedInstanceState) {
    43         super.onCreate(savedInstanceState);
    44         setContentView(R.layout.activity_handler_good);
    45 
    46         myHandler.postDelayed(RUNNABLE,1000*60*5);
    47     }
    48 }

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

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

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

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

     1 package com.example.nanchen.anrsolutiondemo.photo;
     2 
     3 import android.graphics.Bitmap;
     4 import android.graphics.BitmapFactory;
     5 
     6 import java.lang.ref.SoftReference;
     7 import java.util.HashMap;
     8 
     9 /**
    10  * @author nanchen
    11  * @fileName ANRSolutionDemo
    12  * @packageName com.example.nanchen.anrsolutiondemo.photo
    13  * @date 2016/09/23  11:58
    14  */
    15 public class CacheBySoftRef {
    16 
    17     // 首先定义一个HashMap,保存软应用对象
    18     private HashMap<String,SoftReference<Bitmap>> imageCache =  new HashMap<>();
    19     // 再来定义一个方法,保存Bitmap的软引用到HashMap
    20     public void addBitmapToCache(String path){
    21         // 强引用的Bitmap对象
    22         Bitmap bitmap = BitmapFactory.decodeFile(path);
    23         // 软引用的Bitmap对象
    24         SoftReference<Bitmap> softBitmap = new SoftReference<Bitmap>(bitmap);
    25         // 添加该对象到Map使其缓存
    26         imageCache.put(path,softBitmap);
    27     }
    28 
    29     // 获取的时候,可以通过SoftReference的get()的方法得到Bitmap对象
    30     public Bitmap getBitmapByPath(String path){
    31         // 从缓存中取软引用的Bitmap对象
    32         SoftReference<Bitmap> softBitmap = imageCache.get(path);
    33         // 判断是否存在软引用
    34         if (softBitmap == null){
    35             return null;
    36         }
    37         // 通过软引用取出Bitmap对象,如果由于内存不足Bitmap被回收,则取得空;
    38         // 如果未被回收,则可重复使用,提高速度
    39         Bitmap bitmap = softBitmap.get();
    40         return bitmap;
    41     }
    42 }

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

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

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

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

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

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

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

     1 package com.example.nanchen.anrsolutiondemo.innerClass;
     2 
     3 import android.os.Bundle;
     4 import android.support.v7.app.AppCompatActivity;
     5 
     6 import com.example.nanchen.anrsolutiondemo.R;
     7 
     8 public class MainActivity extends AppCompatActivity {
     9 
    10     private static TestInnerBad testInnerBad = null;
    11 
    12     class TestInnerBad{
    13 
    14     }
    15 
    16     @Override
    17     protected void onCreate(Bundle savedInstanceState) {
    18         super.onCreate(savedInstanceState);
    19         setContentView(R.layout.activity_inner_bad);
    20 
    21         if (testInnerBad == null){
    22             testInnerBad = new TestInnerBad();
    23         }
    24 
    25         Runnable runnable1 = new MyRunnable();
    26         Runnable runnable2 = new Runnable() {
    27             @Override
    28             public void run() {
    29 
    30             }
    31         };
    32     }
    33 
    34     private static class MyRunnable implements Runnable{
    35 
    36         @Override
    37         public void run() {
    38 
    39         }
    40     }
    41 
    42 }

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

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

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

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

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

    这里修复的方法是:

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

     

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

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

          

       

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

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

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

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

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

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

     1 private List<String> nameList;
     2     private List<Fragment> list;
     3 
     4     @Override
     5     public void onDestroy() {
     6         super.onDestroy();
     7         if (nameList != null){
     8             nameList.clear();
     9             nameList = null;
    10         }
    11         if (list != null){
    12             list.clear();
    13             list = null;
    14         }
    15     }

    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 官网介绍中,有这样一段话。

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

  • 相关阅读:
    Eclipse 导入项目乱码问题(中文乱码)
    sql中视图视图的作用
    Java基础-super关键字与this关键字
    Android LayoutInflater.inflate(int resource, ViewGroup root, boolean attachToRoot)的参数理解
    Android View和ViewGroup
    工厂方法模式(java 设计模式)
    设计模式(java) 单例模式 单例类
    eclipse乱码解决方法
    No resource found that matches the given name 'Theme.AppCompat.Light 的完美解决方案
    【转】使用 Eclipse 调试 Java 程序的 10 个技巧
  • 原文地址:https://www.cnblogs.com/liushilin/p/5900089.html
Copyright © 2011-2022 走看看