内存管理的目的就是让我们在开发中怎么有效的避免我们的应用出现内存泄漏的问题。内存泄漏大家都不陌生了，简单粗俗的讲，就是该被释放的对象没有释放，一直被某个或某些实例所持有却不再被使用导致 GC 不能回收。
我会从 Java 内存泄漏的基础知识开始，并且通过具体例子来说明 Android 引起内存泄漏的各种原因，以及如何利用工具来分析应用内存泄漏，最后再做总结。
篇幅略长，大家可以分几节来看！

Java 内存分配策略

Java 程序运行时的内存分配策略有三种，分别是静态分配、栈式分配、堆式分配，对应的三种存储策略使用的内存空间主要分别是静态存储区（也称方法区）、栈区和堆区。

  • 静态存储区(方法区)：主要存放静态数据、全局 static 数据和常量。这块内存在程序编译时就已经分配好，并且在程序整个运行期间都存在。
  • 栈区：当方法被执行时，方法体内的局部变量都在栈上创建，并在方法执行结束时这些局部变量所持有的内存将会自动被释放。因为栈内存分配运算内置于处理器的指令集中，效率很高，但是分配的内存容量有限。
  • 堆区：又称动态内存分配，通常就是指在程序运行时直接 new 出来的内存。这部分内存在不使用时将会由 Java 垃圾回收器来负责回收。

栈与堆的区别：

在方法体内定义的（局部变量）一些基本类型的变量和对象的引用变量都是在方法的栈内存中分配的。挡在一段方法块中定义一个变量时，Java 就会在栈中为该变量分配内存空间，当超过该变量的作用域后，该变量也就无效了，分配给它的内存空间也将被释放掉，该内存空间可以被重新使用。
堆内存用来存放所有由 new 创建的对象（包括该对象其中的所有成员变量）和数组。在堆中分配的内存，将由 Java 垃圾回收器来自动管理。在堆中产生了一个数组或者对象后，还可以在栈中定义一个特殊的变量，这个变量的取值等于数组或者对象在堆内存中的首地址，这个特殊的变量就是我们上面说的引用变量。我们可以通过这个引用变量来访问堆中的对象或者数组。
举个🌰：

1
2
3
4
5
6
7
8
9
10
11
public class Sample(){
  int s1 = 0;
  Sample mSample1 = new Sample();
  public void method(){
    int s2 = 1;
    Sample mSample2 = new Sample();
  }
}
Sample mSample3 = new Sample();

Sample 类的局部变量 s2 和引用变量 mSample2 都是存在于栈中，但 mSample2 指向的对象是存在于堆上的。mSample3 指向的对象实体存放在堆上，包括这个对象的所有成员变量 s1 和 mSample1，而它自己存在于栈中。
结论：

  • 局部变量的基本数据类型和引用存储于栈中，引用的对象实体存储于堆中。因为它们属于方法中的变量，生命周期随方法而结束。
  • 成员变量全部存储于堆中（包括基本数据类型，引用和引用的对象实体）。因为它们属于类，类对象终究是要被 new 出来使用的。

了解了 Java 的内存分配之后，我们来看看 Java 是怎么管理内存的。

Java 是如何管理内存

Java 的内存管理就是对象的分配和释放问题。在 Java 中，程序员需要通过关键字 new 为每个对象申请内存（基本类型除外），所有的对象都在堆（Heap）中分配空间。另外，对象的释放是由 GC 决定和执行的。在 Java 中，内存的分配是由程序完成的，而内存的释放是由 GC 完成的，这种收支两条线的方法确实简化了程序员的工作。但同时，它也加重了 JVM 的工作。这也是 Java 程序运行速度较慢的原因之一。因为，GC 为了能够正确释放对象，GC 必须监控每一个对象的运行状态，包括对象的申请、引用、被引用、赋值等，GC 都需要进行监控。

监视对象状态是为了更加准确地、及时地释放对象，而释放对象的根本原则就是该对象不再被引用。

为了更好理解 GC 的工作原理，我们可以将对象考虑为有向图的顶点，将引用关系考虑为图的有向边，有向边从引用这指向被引用对象。另外，每个线程对象可以作为一个图的起始顶点，例如大多程序从 main 进程开始执行，那么该图就是以 main 进程顶点开始的一棵根树。在这个有向图中，根顶点科大的对象都是有效对象，GC 将不回收这些对象。如果某个对象（连通子图）与这个根顶点不可达（注意，该图为有向图），那么我们认为这个（这些）对象不再被引用，可以被 GC 回收。一下，我们举一个例子说明 JVM 的内存分配情况。以下右图，就是左边程序运行到第 6 行的示意图。

1552315574(1).jpg
1552315574(1).jpg

Java 使用有向图的方式进行内存管理，可以消除引用循环的问题，例如有三个对象，相互引用，只要它们和根进程不可达的，那么 GC 也是可以回收它们的。这种方式的优点是管理内存的精度很高，但是效率较低。另外一种常用的内存管理技术是使用计数器，例如 COM 模型采用计数器方式管理构建，它与有向图相比，精度很低（很难处理循环引用的问题），但执行效率很高。

什么是 Java 中的内存泄漏

在 Java 中，内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点，首先，这些对象是可达的，即在有向图中，存在通路可以与其相连；其次，这些对象是无用的，即 程序以后不会再使用这些对象。如果对象满足这两个条件，这些对象就可以判定为 Java 中的内存泄漏，这些对象不会被 GC 所回收，然而它却占用内存。
在 C++ 中，内存泄漏的范围更大一些。有些对象被分配了内存空间，然后却不可达，由于 C++ 中没有 GC，这些内存将永远回收不回来。在 Java 中，这些不可达的对象都是由 GC 负责回收，因此程序员不需要考虑这部分的内存泄漏。
通过分析，我们得知，对于 C++，程序员需要自己管理边和顶点，而对于 Java 程序员只要管理边就可以了（不需要管理顶点的释放）。通过这种方式，Java 提高了编程的效率。

1552357959(1).jpg
1552357959(1).jpg

因此，通过以上分析，我们知道在 Java 中也有内存泄漏，但范围比 C++ 要小一些。因为 Java 从语言上保证，任何对象都是可达，所有的不可达对象都是由 GC 管理。

对于程序员来说，GC 基本是透明的，不可见的。虽然我们只有几个函数可以访问 GC，例如运行 GC 的函数 System.gc()，但是根据 Java 语言规范定义，该函数不保证 JVM 的垃圾收集器一定会执行。因为，不同的 JVM 实现者可能使用不同的算法管理 GC。通常，GC 的线程的优先级别较低。JVM 调用 GC 的策略也有很多种，有的是内存使用达到一定程度时，GC 才开始工作，也有定时执行的，有的是平缓执行 GC，有的是中断式执行 GC。但通常来说，我们不需要关心这些。除非在一些特定的场合，GC 的执行影响应用程序的性能，例如对于基本 Web 的实时系统，如网络游戏等，用户不希望 GC 突然中断应用程序执行而进行垃圾回收，那么我们需要调整 GC 的参数，让 GC 能够通过平缓的方式释放内存，例如将垃圾回收分解为一系列的小步骤执行，Sun 提供的 HotSpot JVM 就支持这一特性。
同样给出一个 Java 内存泄漏的典型例子，

1
2
3
4
5
Vector v = new Vector(10);
for(int i = 1; i < 100; i++){
  Object o = new Object();
  v.add
}

在这个例子中，我们循环申请 Object 对象，并将所申请的对象放入一个 Vector 中，如果我们仅仅释放引用本身，那么 Vector 仍然引用该对象，所以这个对象对 GC 来说是不可回收的。因此，如果对象加入到 Vector 后，还必须从 Vector 中删除，最简单的方法就是将 Vector 对象设置为 null。

Android 中常见的内存泄漏汇总

  • 集合类泄漏
    集合类如果仅仅有添加元素的方法，而没有相应的删除机制，导致内存被占用。如果这个集合类是全局性的变量（比如类中的静态属性，全局性的 map 等即有静态引用或 final 一直指向它），那么没有相应的删除机制，很可能导致集合锁占用的内存只增不减。比如上面的典型例子就是其中一种情况，当然实际上我们在项目中肯定不会写这么 2B 的代码，但稍不注意还是很容易出现这种情况，比如我们都喜欢通过 HashMap 做一些缓存之类的事，这种情况要多留一些心眼。

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

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    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;
      }
    }

这是一个普通的单例模式，当创建这个单例的时候，由于需要传入一个 Context，所以这个 Context 的生命周期的长短至关重要：

  1. 如果此时传入的是 Application 的 Context，因为 Application 的生命周期就是整个应用的生命周期，所以这将没有任何问题。
  2. 如果此时传入的是 Activity 的 Context，当这个 Context 所对应的 Activity 退出时，由于该 Context 的引用被单例对象所持有，其生命周期等于整个应用程序的生命周期，友谊当前 Activity 退出时它的内存并不会被回收，这就造成泄漏了。

正确的方式应该改为下面这种方式：

1
2
3
4
5
6
7
8
9
10
11
12
13
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;
  }
}

或者这样写，连 Context 都不用传过来了：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
//在你的Application中添加一个静态方法，getContext() 返回 Application 的 context
···
context = getApplicationContext();
···
/** 
  * 获取全局的context 
  * @return 返回全局context对象 
  */
  pulic static Context getContext(){
    return context;
  }
public class AppManager{
  private static AppManager instance;
  private Context context;
  private AppManager(){
    this.context = MyApplication.getContext();//使用Application的context
  }
  public static AppManager getInstance(){
    if(instance == null){
      instance = new AppManager();
    }
    return instance;
  }
}

  • 匿名内部类/非静态内部类和异步线程
    • 非静态内部类创建静态实例造成的内存泄漏
      有时候我们为了避免可能会在启动频繁的 Activity 中，为了避免重复创建相同的数据资源，可能会出现这种写法：
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      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{
         //···
         }
      }

这样就在 Activity 内部创建了一个非静态内部类的单例，每次启动 Activity 时都会使用该单例的数据，这样虽然避免了资源的重复创建，不过这种写法会造成内存泄漏，因为非静态内部类默认会有外部类的引用，而该非静态内部类又创建了一个静态实例，该实例的生命周期和应用的一样长，这就导致了该静态实例一直会持有该 Activity 的引用，导致 Activity 的内存资源不能正常回收。正确的做法为：
将该内部类设为静态内部类或者将该内部类抽取出来封装成一个单例，如果需要使用 Context，请按照上面推荐的使用 Application 的 context。当然，Application 的 context 不是万能的，所以也不能随便乱用，对于有些地方则必须使用 Activity 的 Context，对于 Application，Service，Activity 三者的 Context 的应用场景如下：

功能 Application Service Acativity
Start an Activity NO1 NO1 YES
Show a Dialog NO NO YES
Layout Inflation YES YES YES
Start a Service YES YES YES
Bind to a Service YES YES YES
Send a Broadcast YES YES YES
Register BroadcastReceiver YES YES YES
Load Resource Values YES YES YES

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

  • 匿名内部类
    Android 开发经常会继承实现 Activity/Fragment/View,此时如果你使用了匿名类，并被异步线程持有了，那要小心了，如果没有任何措施这样一定会导致泄漏
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    public class MainActivity extends Activity{
      ···
      Runnable ref1 = new MyRunnable();
      Runnable ref2 = new Runnable(){
        @Override
        public void run(){
        }
      };
      ···
    }

ref1 和 ref2 的区别是，ref2 使用了匿名内部类。我们来看看运行时这两个引用的内存：

1552370991(1).png
1552370991(1).png

可以看到，ref1 没有什么特别的。但 ref2 这个匿名类的实现对象里面多了一个引用：
this$0 这个引用指向 MainActivity.this，也就是说当前的 MainActivity 实例会被 ref2 持有，如果将这个引用再传入一个异步线程，此线程和此 Activity 生命周期不一致的时候，就造成了 Activity 的泄漏。

  • Handler 造成的内存泄漏
    Handler 的使用造成的内存泄漏问题应该说是最为常见了，很多时候我们为了避免 ANR 而不在主线程进行耗时操作，在处理网络任务或者封装一些请求回调等 api 都借助 Handler 来处理，但 Handler 不是万能的，对于 Handler 的使用代码编写一不规范即有可能造成内存泄漏。另外，我们知道 Handler、Message 和 MessageQueue 都是相互关联在一起的，万一 Handler 发送的 Message 尚未被处理，则该 Message 及发送它的 Handler 对象被线程 MessageQueue 一直持有。由于 Handler 属于 TLS（Thread Local Storage）变量，生命周期和 Activity 是不一致的。因此这种实现方式一般很难保证跟 View 或者 Activity 的生命周期保持一致，故很容易导致无法正常释放。
    举个例子：
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    public class SampleActivity extends Activity{
      private final Handler mLeakyHandler = new Handler(){
        @Override
        public void handleMessage(Message msg){
          // ...
        }
      }
      @Override
      protected void onCreate(Bundle savedInstanceState){
        super.onCreate(savedInstanceState);
        // Post a message and delay its execution for 10 minutes.
        mLeakyHandler.postDdelayed(new Runnable {
          @Override
          public void run(){/** ... */}
        }, 1000 * 60 * 10);
        //Go back to the previous Activity.
        finish();
      }
    }

在该 SampleActivity 中声明了一个延迟 10 分钟执行的消息 Message，mLeakyHandler 将其 push 进了消息队列 MessageQueue 里。当该 Activity 被 finish()掉时，延迟执行任务的 Message 还会继续存在于主线程中，它持有该 Activity 的 Handler 引用，所以此时 finish() 掉的 Activity 就不会被回收了从而造成内存泄漏（因 Handler 为非静态内部类，它会持有外部类的引用，在这里就是指 SampleActivity）。
修复方法：在 Activity 中避免使用非静态内部类，比如上面我们将 Handler 声明为静态的，则其存活期跟 Activity 的生命周期就无关了。同时通过弱引用的方式引入 Activity，避免直接将 Activity 作为 context 传进去，见下面代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
public class SampleActivity extends Activity{
  /**
    * Instances of static inner classes do not hold an implicit
    * reference to their outer class
    */
  private static class MyHandler extends Handler{
    private final WeakReference<SampleActivity> mActivity;
    public MyHandler(SampleActivity activity){
      mActivity = new WeakReference<SampleActivity>(activity);
    }
    @Override
    public void handleMessage(Message msg){
      SampleActivity activity = mActivity.get();
      if(activity != null){
        // ...
      }
    }
  }
  private final MyHandler mHandler = new MyHandler(this);
  /**
    * Instances of anonymous classes do not hold an implicit
    * reference to their outer class when they are "static"
    */
  private static final Runnable sRunnable = new Runnable(){
    @Override
    public void run(){/*...*/}
  };
  
}