美文网首页
内存泄漏的原因及案例

内存泄漏的原因及案例

作者: niudeyang | 来源:发表于2018-04-11 16:43 被阅读64次

    1.单例导致

    由于单例的静态特性使得其生命周期跟应用的生命周期一样长,所以如果使用不恰当的话,很容易造成内存泄漏。比如下面一个典型的例子:

    public class AppManager {
         private static AppManager instance;
         private Context context;
         private AppManager(Context context) {
               this.context = context;
         }
         public static AppManager getInstance(Context context) {
              if (instance != null) {
                    instance = new AppManager(context);
              }
              return instance;
         }
    }
    

    如果此时传入的是 Activity 的 Context,当这个 Context 所对应的 Activity 退出时,由于该 Context 的引用被单例对象所持有,其生命周期等于整个应用程序的生命周期,所以当前 Activity 退出时它的内存并不会被回收,这就造成泄漏了,可以换成以下写法

    public class AppManager {
         private static AppManager instance;
         private Context context;
         private AppManager(Context context) {
               this.context = context.getApplicationContext();// 使用Application 的context
         }
         public static AppManager getInstance(Context context) {
              if (instance != null) {
                    instance = new AppManager(context);
              }
              return instance;
        }
    }
    

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

    public class MainActivity extends AppCompatActivity {
         private static TestResource mResource = null;
         @Override
         protected void onCreate(Bundle savedInstanceState) {
                super.onCreate(savedInstanceState);
                setContentView(R.layout.activity_main);
                if(mManager == null){
                      mManager = new TestResource();
                }
                //...
         }
         class TestResource {
              //...
         }
    }
    

    正确的做法应该是

    将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例,如果需要使用Context,请按照上面推荐的使用Application 的 Context。

    2 非静态内部类导致

    原因
    1非静态内部类对外部类会存在一个隐式引用

    class Out extends Activity{
        @Override
        protected void onCreate(Bundle savedInstanceState) {
         launch.setOnClickListener(new View.OnClickListener() {
                @Override
                public void onClick(View view) {
                    outmethod();
                }
            });}
    void outmethod(){
    }
    }
    内部类能调用外部类的方法是因为持有外部类的引用
    

    2非静态内部类中存在异步任务,可能会导致其对应的外部类内存资源无法正常释放

    class Out extends Activity{
        @Override
        protected void onCreate(Bundle savedInstanceState) {
         launch.setOnClickListener(new View.OnClickListener() {
                @Override
                public void onClick(View view) {
                    mPresenter.getData();
                }
            });}
    void outmethod(){
    }
    }
    这里面有网络请求的耗时任务
    

    解决方案:

    解决思路
    1去除隐式引用(通过静态内部类来去除隐式引用)
    2手动管理对象引用(修改静态内部类的构造方式,手动引入其外部类引用)
    3当内存不可用时,不执行不可控代码(Android可以结合智能指针,WeakReference包裹外部类实例)

    class Out extends Activity{
        @Override
        protected void onCreate(Bundle savedInstanceState) {
         launch.setOnClickListener(new listener(Out.this));
    }
         void outmethod(){}
     static  class listener implements View.OnClickListener{
            private WeakReference<Out> weakReference;
            public listener(Out out) {
                this.weakReference=new WeakReference<Out>(out);
            }
            
    
            @Override
              public void onClick(View view) {
                weakReference.get().outmethod();
    
              }
          }
    }
    

    android中的几类引用
    StrongReference强引用可以直接访问目标对象,强引用所关联的对象,在任何时候都不会被内存回收,JVM宁肯抛出OOM异常,也不会对其进行回收,所以,在通常的内存泄漏中,大多都有强引用的身影
    (SoftReference)
    软引用是除了硬引用之外最强的一种引用,软引用和硬引用的不同点在于,软引用是可被回收的;回收机制是:当内存充足的时候,在GC时,不会去回收当前的软引用,当内存临近阈值或不足的时候,在GC时,发现某一对象的引用只具有软引用当前软引用就会被回收。
    (WeakReference)
    弱引用是比软引用和硬引用更弱的一种引用,在GC时,不论内存是否充足,发现某一对象的引用只具有弱引用当前弱引用就会被回收。
    (PhantomReference)
    虚引用不能保证其保存对象生命周期,其保存对象若只有虚引用,则其有效期完全随机于GC的回收,在任何一个不确定的时间内,都可能会被回收;而虚引用与其他几者的引用不同在于,在使用PhantomReference,必须要和Reference联合使用。

    引用使用方式

    ReferenceQueue queue = new ReferenceQueue();
    WeakReference weakReference = new WeakReference(this,queue);
    SoftReference softReference = new SoftReference(this,queue);
    PhantomReference phantomReference = new PhantomReference(this,queue);

    那么这个ReferenceQueue有什么用呢?

    引用对象本身,也是一个强引用,其除了具有保存一个对象本身特有的引用属性之外,引用对象本身也具有java对象的一般性,那么在其本身保存的对象被回收之后,引用对象本身也就没有了实用性质,需要一个适当的清理机制,来清理这些对象,避免大量这些引用对象而带来的内存泄漏;这时候,就可以用到ReferenceQueue。

    当引用(SoftReference/WeakReference/PhantomReference)中保存的的对象,被GC回收时,引用本身的这个对象会被加入到ReferenceQueue中,那么,也就是说,ReferenceQueue中保存的对象是Reference,并且是失去了其保存的对象的Reference。这个时候我们可以通过调用ReferenceQueue中提供的poll()这个API来获取队列中的对象,当队列中不存在对象的时候,返回的会是null,当存在或存在多个的时候,都是返回最前面的一个Reference对象,这个时候我们就需要将这个对象进行清除,让相应的内存可以被释放掉。

    Reference ref = null;
    while ((ref = queue.poll()) != null) {
    // 清除ref
    }

    3静态内部类中创建了一个静态实例,会导致内存泄漏(参考上面单例导致的内存泄漏)

    3.资源回收

    对于使用了BraodcastReceiver,ContentObserver,File,Cursor,Stream,Bitmap等资源,应该在Activity销毁时及时关闭或者注销,否则这些资源将不会被回收,从而造成内存泄漏。

    4ListView

    初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的View对象,同时ListView会将这些View对象缓存起来。当向上滚动ListView时,原先位于最上面的Item的View对象会被回收,然后被用来构造新出现在下面的Item。这个构造过程就是由getView()方法完成的,getView()的第二个形参convertView就是被缓存起来的Item的View对象(初始化时缓存中没有View对象则convertView是null)。构造Adapter时,没有使用缓存的convertView。

    5webview

    我们不要使用WebView对象时,应该调用它的destory()函数来销毁它,并释放其占用的内存,否则其长期占用的内存也不能被回收,从而造成内存泄露。

    6集合

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

    相关文章

      网友评论

          本文标题:内存泄漏的原因及案例

          本文链接:https://www.haomeiwen.com/subject/yxczhftx.html