Android 内存管理系列之一：内存泄露

前言：

    明年就要出去实习了，大学这两年来，学了很多东西，但是大多都是停留在基础上，原因就是学了太多了，现在有时间可以静下心来好好整理资料，深入研究。

进入主题：

    大家都知道，Android应用层是由java开发的，Android的davlik虚拟机与JVM也类似，只不过它是基于寄存器的。因此要了解Android的内存管理就必须得了解Java的内存分配和垃圾回收机制。在java中，是通过new关键字来为对象分配内存的，而内存的释放是由垃圾收集器（GC）来回收的，工程师在开发的过程中，不需要显式的去管理内存。但是这样有可能在不知不觉中就会浪费了很多内存，最终导致java虚拟机花费很多时间去进行垃圾回收，更严重的是造成JVM的OOM。因此，Java工程师还是有必要了解JAVA的内存分配和垃圾回收机制。

1. 内存结构

上面这张图是JVM的结构图，它主要四个部分组成：Class Loader子系统和执行引擎，运行时方法区和本地方法区，我们主要来看下RUNTIME DATA AREA区，也就是我们常说的JVM内存。从图中可以看出，RUNTIMEDATA AREA区主要由5个部分组成：

• Method Area:被装载的class的元信息存储在Method Area中，它是线程共享的
• Heap(堆)：一个java虚拟机实例中只存在一个堆空间，存放一些对象信息，它是线程共享的
• Java栈： java虚拟机直接对java栈进行两种操作，以帧为单位的压栈和出栈（非线程共享）
• 程序计数器（非线程共享）
• 本地方法栈（非线程共享）

2. JVM的垃圾回收（GC）

JVM的垃圾原理是这样的，它把对象分为年轻代（Young）、年老代（Tenured）、持久代（Perm），对不同生命周期的对象使用不同的垃圾回收算法。

• 年轻代(Young)

年轻代分为三个区，一个eden区，两个Survivor区。程序中生成的大部分新的对象都在Eden区中，当Eden区满时，还存活的对象将被复制到其中一个Survivor区，当此Survivor区的对象占用空间满了时，此区存活的对象又被复制到另外一个Survivor区，当这个Survivor区也满了的时候，从第一个Survivor区复制过来的并且此时还存活的对象，将被复制到年老代。

• 年老代（Tenured）

年老代存放的是上面年轻代复制过来的对象，也就是在年轻代中还存活的对象，并且区满了复制过来的。一般来说，年老代中的对象生命周期都比较长。

• 持久代（Perm）

用于存放静态的类和方法，持久代对垃圾回收没有显著的影响。

参考网址：http://www.cnblogs.com/zhengtao/articles/2154098.html

   说到Android的内存管理，现在进入主题：内存泄露，内存溢出，大家可能都很熟悉，参考了网上一些比较好的博客和自己的一些项目中实践的总结，谈谈自己对内存泄露的一些看法。

一、什么是内存泄露？

     内存泄漏简单地说就是申请了一块内存空间，使用完毕后没有释放掉。它的一般表现方式是程序运行时间越长，占用内存越多，最终用尽全部内存，整个 系统崩溃（内存溢出OOM）。由程序申请的一块内存，且没有任何一个引用（C++称之为指针）指向它，那么这块内存就泄露了。

       从用户使用程序的角度来看，内存泄漏本身不会产生什么危害，作为一般的用户，根本感觉不到内存泄漏的存在。真正有危害的是内存泄漏的堆积，这会最终消耗尽系统所有的内存。从这个角度来说，一次性内存泄漏并没有什么危害，因为它不会堆积，而隐式内存泄漏危害性则非常大，因为较之于常发性和偶发性内存泄漏它更难被检测到。

二、内存泄露产生的一些常见的原因

   1.Static修饰符
      Static是Java中的一个关键字，当用它来修饰成员变量时，那么该变量就属于该类，而不是该类的实例。所以用Static修饰的变量，它的生命周期是很长的，如果用它来引用一些资源耗费过多的实例（Context的情况最多），这时就要谨慎对待了。 

public class ClazzName {      
    private static Context mContext;  
}

以上的代码是很危险的，如果将Activity赋值到么mContext的话。那么即使该Activity已经onDestroy，但是由于仍有对象保存它的引用，因此该Activity依然不会被释放. 

如何才能有效的避免这种引用的发生呢？ 
 第一、应该尽量避免static成员变量引用资源耗费过多的实例，比如Context。 
 第二、Context尽量使用Application Context，因为Application的Context的生命周期比较长，引用它不会出现内存泄露的问题。 
 第三、使用WeakReference代替强引用。比如可以使用WeakReference<Context> mContextRef; 

   2.线程惹的祸 

   线程也是造成内存泄露的一个重要的源头。线程产生内存泄露的主要原因在于线程生命周期的不可控。我们来考虑下面一段代码。 

public class MyActivity extends Activity {     
@Override     
public void onCreate(Bundle savedInstanceState) {         
  super.onCreate(savedInstanceState);         
  setContentView(R.layout.main_layout);         
  new MyThread().start();     
}       
private class MyThread extends Thread{         
@Override         
  public void run() {             
  

}

}

}

    这段代码很平常也很简单，是我们经常使用的形式。我们思考一个问题：假设MyThread的run函数是一个很费时的操作，当我们开启该线程后，将设备的横屏变为了竖屏，一般情况下当屏幕转换时会重新创建Activity，按照我们的想法，老的Activity应该会被销毁才对，然而事实上并非如此。 
    由于我们的线程是Activity的内部类，所以MyThread中保存了Activity的一个引用，当MyThread的run函数没有结束时,MyThread是不会被销毁的，因此它所引用的老的Activity也不会被销毁，因此就出现了内存泄露的问题。

 

这种线程导致的内存泄露问题应该如何解决呢？ 
    第一、将线程的内部类，改为静态内部类。 
    第二、在线程内部采用弱引用保存Context引用。 

      3.Service中开启线程

       在一些场合需要我们开启一些服务去不断访问服务器或者网络些资源，这样当我们需要关闭服务时，此时不要以为线程中的循环也会结束，需要自己去停止，可以设置一个标志停止线程，要不然线程中引用的资源就会造成内存泄露。

      4.注册没取消造成的内存泄露

这种Android的内存泄露比纯java的内存泄露还要严重，因为其他一些Android程序可能引用我们的Anroid程序的对象（比如注册机制）。即使我们的Android程序已经结束了，但是别的引用程序仍然还有对我们的Android程序的某个对象的引用，泄露的内存依然不能被垃圾回收。

比如

 假设我们希望在锁屏界面(LockScreen)中，监听系统中的电话服务以获取一些信息(如信号强度等)，则可以在LockScreen中定义一个PhoneStateListener的对象，同时将它注册到TelephonyManager服务中。对于LockScreen对象，当需要显示锁屏界面的时候就会创建一个LockScreen对象，而当锁屏界面消失的时候LockScreen对象就会被释放掉。

但是如果在释放LockScreen对象的时候忘记取消我们之前注册的PhoneStateListener对象，则会导致LockScreen无法被垃圾回收。如果不断的使锁屏界面显示和消失，则最终会由于大量的LockScreen对象没有办法被回收而引起OutOfMemory,使得system_process进程挂掉。

虽然有些系统程序，它本身好像是可以自动取消注册的（当然不及时），但是我们还是应该在我们的程序中明确的取消注册，程序结束时应该把所有的注册都取消掉。

5.集合中对象没清理造成的内存泄露

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

6.资源对象没关闭造成的内存泄露

资源性对象比如（Cursor，File文件等）往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们，以便它们的缓冲及时回收内存。它们的缓冲不仅存在于java虚拟机内，还存在于java虚拟机外。如果我们仅仅是把它的引用设置为null,而不关闭它们，往往会造成内存泄露。因为有些资源性对象，比如SQLiteCursor（在析构函数finalize（）,如果我们没有关闭它，它自己会调close()关闭），如果我们没有关闭它，系统在回收它时也会关闭它，但是这样的效率太低了。因此对于资源性对象在不使用的时候，应该调用它的close()函数，将其关闭掉，然后才置为null.在我们的程序退出时一定要确保我们的资源性对象已经关闭。

程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor后没有关闭的情况。如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险。

   7.WebView对象没有销毁

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

8.ThreadLocal使用不当

如果我们粗暴的把ThreadLocal设置null,而不调用remove()方法或set(null),那么就可能造成ThreadLocal绑定的对象长期也能被回收，因而产出内存泄露。可能新手对ThreadLocal不怎熟悉，很据API文档的说明， All threads share the same object, but each sees a different value when accessing it, and changes made by one thread do not affect the other threads. 

ThreadLocal维护变量时，ThreadLocal会为每个使用该变量的线程提供独立的变量副本，所以每一个线程都可以独立地改变自己的副本，而不会影响其它线程所对应的副本。

详细介绍请参考以下网址：

http://blog.csdn.net/androidzhaoxiaogang/article/details/6788489

三、内存泄露检测以及定位。

   前面说了下可能会发生内存泄露的情况，现在说说如何去检测和定位内存泄露。

   内存监测工具 DDMS -> Heap

   无论怎么小心，想完全避免bad code是不可能的，此时就需要一些工具来帮助我们检查代码中是否存在会造成内存泄漏的地方。Android tools中的DDMS就带有一个很不错的内存监测工具Heap(这里我使用eclipse的ADT插件，并以真机为例，在模拟器中的情况类似，操作步骤如图所示：

     如何才能知道我们的程序是否有内存泄漏的可能性呢。这里需要注意一个值：Heap视图中部有一个Type叫做dataobject，即数据对象，也就是我们的程序中大量存在的类类型的对象。在data object一行中有一列是“Total Size”，其值就是当前进程中所有 正常情况下Total Size值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良好，没有造成对象不被垃圾回收的情况，所以说虽然我们不断的操作会不断的生成很多对象，而在虚拟机不断的进行GC的过程中，这些对象都被回收了，内存占用量会会落到一个稳定的水平； 反之如果代码中存在没有释放对象引用的情况，则dataobject的Total Size值在每次GC后不会有明显的回落，随着操作次数的增多Total Size的值会越来越大。

    内存定位MAT(Memory Analyzer Tools)

     至于他的安装很容易，可以在线安装,也可以下载安装，下载安装如下图：

    

    在线安装如下图所示：

     

   如果已经成功安装好了MAT工具，使用起来非常简单，首先将需要分析的应用程序跑起来，打开eclipse的devices视图你将会看到点击“Dump Hprof file”按钮，注意点击一下就可以了，然后等待（等待几秒）dump一个内存快照出来，接下来就会自动打开mat的视图了，如果mat没有安装成功，会让你保存一个.hprof文件到本地。安装好的界面如图所示：

   

    并不是所有的内存泄漏都可以用观察heap size的方法检测出来，因为有的程序只是泄漏了几个对象，而且泄漏的对象个数不会随着程序的运行而增加，这种内存泄漏不会直接导致OOM，但是无用对象无法回收，无疑是对内存的浪费，会影响到程序的性能，我们需要使用MAT工具才能发现这种比较隐蔽的内存泄漏。
使用MAT之前有2个概念是要掌握的：Shallow heap和Retained heap。Shallow heap表示对象本身所占内存大小，一个内存大小100bytes的对象Shallow heap就是100bytes。Retained heap表示通过回收这一个对象总共能回收的内存，比方说一个100bytes的对象还直接或者间接地持有了另外3个100bytes的对象引用，回收这个对象的时候如果另外3个对象没有其他引用也能被回收掉的时候，Retained heap就是400bytes。这里有一篇很好的关于MAT的文章，还附带了一个例子，参考网址：http://my.oschina.net/u/2285044/blog/471027

这里附上一些好的文章的链接：

http://blog.csdn.net/cyq1028/article/details/19980369

http://dyf128.iteye.com/blog/1711404

http://www.2cto.com/kf/201112/113452.html

最后的最后

   有些内容是参考了网上一些好的文章，特把他们归纳起来，以后也好复习，也可以分享给一些新手作参考。