面试记录第十六节——（内存泄露）

一、java内存泄露基础知识

答：简单的讲就是该被释放的对象没有得到释放，一直被某个实例所持有，导致不能垃圾回

---

二、java内存的分配策略

答：在java程序运行当中，它的内存分配策略是分为三个部分。

（一）静态存储区（也叫方法区）：此处主要存放一些静态数据、全局遍历等等。在java内存当中，程序编译的时候，他已经分配好了内存，并且在静态存储区中存储的变量，在整个程序运行期间都存在。

（二）栈区：他被方法执行的时候，方法体内的局部变量，它会在栈内创建内存控件，并在方法结束后，这些变量所持有的内存，他会被自动释放。因为占内存分配运算，它内置于处理器中，所以它效率很高。但是栈区 的内存空间容量有限。

（三）堆区（动态内存分配）：通常就是我们new对象出来的内存，这部分内存在不适用的时候，他将会有java 的垃圾回收器来负责回收。

• 建议课下复习：栈区和堆区的区别。

---

三、java是如何管理内存的。

答：简单来说，java管理内存就是对象的分配和释放问题，在java中啊，程序员需要new为每个对象分配内存空间，所有的对象都是在堆中分配空间的。对象的释放是有GC（垃圾回收器）决定，在java中内存分配是由我们开发者来完成的，而内存的释放是由GC来自动完成的。这两条先减轻了我们开发者的工作，但是加重了java虚拟机的工作，这也是java相比较C语言、C++运行较慢的原因之一。但是GC有很大的作用，它为了能够正确的释放对象，他必须监控每个对象的运行状态，包括对象的申请、引用、被引用、赋值等等都需要进行监控。

如图01

我们都知道，我们java程序一般都是从main方法开始执行的，main是程序执行的根顶点，根顶点可达到的对象都是有效对象，例如o1、o2、Obj1都是有效对象。GC的时候不会回收这些对象，而Obj2对象，它是跟顶点不可达到的（不再被引用），所以Obj2是可以被GC垃圾回收的，这就是java管理内存的整体机制。

---

四、java中的内存泄露？

答：内存泄露是指无用对象（不再被使用的对象）持续占有内存或者无用对象的内存得不到释放，从而造成的内存空间的浪费，称之为内存泄露。内存泄露不断地积累就会造成OOM现象。

---

五、java中的内存泄露有哪些原因导致？

答：单利、匿名内部类、handler造成的内存泄露等、static乱用、资源未关闭、AsyncTask等

第一点、单利

我们开发者对单利模式都很熟悉，不过不恰当的使用单利就会造成内存泄露，因为我们知道单利的静态特性，使他生命周期和APP的生命周期一样长，这也就表明如果一个对象不再被使用了，而这个单利还持有该对象的引用，想要将被释放的对象将不能被正常回收。就会造成内存泄露。

• 例如下面代码：

public class DanLi {
    private  static DianPingData instance;
    private Context context;

    public DanLi(Context context) {
        this.context = context;
    }

    public static DianPingData getInstance(Context context){
        if (instance == null){
            instance = new DianPingData();
        }
        return instance;
    }
}

在构造函数中，我们传入了context，其实是activity.context。这里如果你的某个activity想要被回收的时候，但是却被单利所持有，就会导致无法被回收。正确的写法如下：

public class DanLi {
    private  static DianPingData instance;
    private Context context;

    public DanLi(Context context) {
        this.context = context.getApplicationContext();
    }

    public static DianPingData getInstance(Context context){
        if (instance == null){
            instance = new DianPingData();
        }
        return instance;
    }
}

也就是说，这里传入的context，应该是getApplicationContext。他持有的是整个应用的context。这种写法就说明这个application的生命周期和我们单利的生命周期是一样的，也就不会导入想刚才我们传入activity的context,从而影响activity得不到及时回收，所引起的内存泄露。

第二点、匿名内部类

我们都知道，非静态内部类默认会持有外部类的MainActivity的引用，而用非静态内部类创建一个静态实例的话，该实例的声明周期就会和应用的生命周期一样长。这就导致了改静态实例一直会持有该Activity的引用。从而导致Activity得资源不到正常回收，例如：（这种写法就会造成内存泄露）

public class TwoActivity extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
    }
}

class TextDate{
    private static String name = "666";
}

正确的写法：

public class TwoActivity extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
    }
}

static  class TextDate{
    private static String name = "666";
}

//这样静态内部类就不会持有外部类的引用，从而就不会有内存泄露的问题。

第三点、handler造成的内存泄露

handler：线程之间发送消息异步的框架。而handler使我们开发中造成内存泄露最常见的。比如我们平常使用handler来处理一些网络数据获取的时候，会请求一个回调，这时候我们借助一个handler来处理，如果这个时候你没有考虑到handler引起的内存泄露，就会造成严重问题。例如：

    private Handler mhandler = new Handler(){
        @Override
        public void handleMessage(Message msg) {
         //...
        }
    };

上面的handler写法就会造成内存泄露，因为我们这个mhandler它是handler的非静态内部类的使实例，所以他持有外部类的引用，我们知道handler的消息队列是在一个looper线程中不断的轮训处理消息，当我们的Activity要退出的时候，消息对列中还有未处理的消息或正在处理的消息，而消息队列中的msg他又持有了mhandler的实例引用，这就导致了Activity资源想回收的时候无法回收，从而造成内存泄露。正确的写法如下：

public class TwoActivity extends Activity {

//    private Handler handler = new Handler(){
//        @Override
//        public void handleMessage(Message msg) {
//            //...
//        }
//    };


    private MyHandler myHandler = new MyHandler();
    private static class MyHandler extends Handler{

        private WeakReference<Context> reference;

        private MyHandler (Context context){
            reference = new WeakReference<Context>(context);
        }

        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
        }
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        getdata();
    }

    private void getdata() {
        Message msg = Message.obtain();
        myHandler.sendMessage(msg);
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        myHandler.removeCallbacksAndMessages(null);
    }
}

我们会把handler的内部类，改为静态的内部类，同时我们会在MyHandler的内部持有外部类的弱引用，这样就能解决好内存泄露问题。

• 总结

第一步：把handler设置为静态内部类。

第二步：我们在handler的内部持有外部类的弱引用。这样就可以了

第四点、尽量避免使用static变量。

如果我们把成员变量设置为了static，这个成员变量的生命周期就会和APP的生命周期是一致的，这样就会导致一个问题。如果你的APP进程是常驻内存的，即使APP切换到后台，这部分的stitic的变量他也是不会被释放的，按照我们现在APP的内存管理机制，占内存较大的进程将优先被回收。所以说当你的进程被回收了之后，你所存在的那些变量其实他的数据是不安全的。对于static造成的内存泄露，解决的方法就是在类设计的时候，你要考虑好是不是初始化的时候去设为静态成员，是否可以考虑一下懒加载，尽量避免static变量，如果必须要涉及到了static变量，那么一定要对这些变量的生命周期进行管理起来。

第五点、资源未关闭造成的内存泄露，这个无需多说，大家都理解

第六点、AsyncTask

原因和handler差不多，但是有一点是不一样的，我们可以在onDestory(）方法中取消掉AsyncTask任务，这样就可以避免造成内存泄露。