android GC内存泄露问题

来自：http://www.cnblogs.com/devinzhang/archive/2012/01/28/2330738.html

1. android内存泄露概念

     不少人认为JAVA程序，因为有垃圾回收机制，应该没有内存泄露。其实如果我们一个程序中，已经不再使用某个对象，但是因为仍然有引用指向它，垃圾回收器就无法回收它，当然该对象占用的内存就无法被使用，这就造成了内存泄露。如果我们的java运行很久,而这种内存泄露不断的发生，最后就没内存可用了。当然java的，内存泄漏和C/C++是不一样的。如果java程序完全结束后，它所有的对象就都不可达了，系统就可以对他们进行垃圾回收，它的内存泄露仅仅限于它本身，而不会影响整个系统的。C/C++的内存泄露就比较糟糕了，它的内存泄露是系统级，即使该C/C++程序退出，它的泄露的内存也无法被系统回收，永远不可用了，除非重启机器。

Android的一个应用程序的内存泄露对别的应用程序影响不大。为了能够使得Android应用程序安全且快速的运行，Android的每个应用程序都会使用一个专有的Dalvik虚拟机实例来运行，也就是说每个应用程序都是在属于自己的进程中运行的。Android为不同类型的进程分配了不同的内存使用上限，如果程序在运行过程中出现了内存泄漏的而造成应用进程使用的内存超过了这个上限，则会被系统视为内存泄漏，从而被kill掉，这使得仅仅自己的进程被kill掉，而不会影响其他进程（如果是system_process等系统进程出问题的话，则会引起系统重启）。

    内存泄露示例：

/*此时，所有的Object对象都没有被释放，因为变量v引用这些对象。实际上这些对象已经是无用的，但还被引用，GC就无能为力了(事实上GC认为它还有用)，这一点是导致内存泄漏最重要的原因。*/
Vector v = new Vector(10);      
for (int i = 1; i < 100; i++)      {      　
    Object o = new Object();      　
    v.add(o);      　
    o = null;     
 }

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

　　总的来说，内存管理中的内存泄漏产生的主要原因：保留下来却永远不再使用的对象引用。

2.引起内存泄露的情况

1）资源对象没关闭造成的内存泄露

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

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

 

2）一些不良代码成内存压力

　　有些代码并不造成内存泄露，但是它们，或是对没使用的内存没进行有效及时的释放，或是没有有效的利用已有的对象而是频繁的申请新内存，对内存的回收和分配造成很大影响的，容易迫使虚拟机不得不给该应用进程分配更多的内存，造成不必要的内存开支。

　　a．Bitmap没调用recycle()

　　Bitmap对象在不使用时，我们应该先调用recycle()释放内存，然后才它设置为null。

虽然recycle()从源码上看，调用它应该能立即释放Bitmap的主要内存，但是测试结果显示它并没能立即释放内存。但是我它应该还是能大大的加速Bitmap的主要内存的释放。

　　b．构造Adapter时，没有使用缓存的convertView

　　以构造ListView的BaseAdapter为例，在BaseAdapter中提共了方法：

public View getView(int position, View convertView, ViewGroup parent)

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

　　由此可以看出，如果我们不去使用convertView，而是每次都在getView()中重新实例化一个View对象的话，即浪费时间，也造成内存垃圾，给垃圾回收增加压力，如果垃圾回收来不及的话，虚拟机将不得不给该应用进程分配更多的内存，造成不必要的内存开支。

layout.xml

 <?xml version="1.0" encoding="utf-8" ?> 
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android" android:orientation="vertical" android:layout_width="fill_parent" android:layout_height="60dip">
  <ImageView android:id="@+id/icon" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_alignParentLeft="true" android:paddingLeft="9px" /> 
  <TextView android:id="@+id/text" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_toRightOf="@id/icon" android:textAppearance="?android:attr/textAppearanceMedium" android:paddingLeft="9px" /> 
  </RelativeLayout>

能引起内存泄露的代码: BadAdapter.java

public class BadAdapter extends BaseAdapter {

    ......

    @Override

    public View getView(int position, View convertView, ViewGroup parent) {
        Log.d("MyAdapter", "Position:" + position + "---"
                + String.valueOf(System.currentTimeMillis()));
        final LayoutInflater inflater = (LayoutInflater) mContext
                .getSystemService(Context.LAYOUT_INFLATER_SERVICE);
        View v = inflater.inflate(R.layout.list_item_icon_text, null);
        ((ImageView) v.findViewById(R.id.icon)).setImageResource(R.drawable.icon);
        ((TextView) v.findViewById(R.id.text)).setText(mData[position]);
        return v;
    }
}

修正优化示例代码示例代码：GoodAdapter.java

public class GoodAdapter extends BaseAdapter {

    ......

    @Override
    public View getView(int position, View convertView, ViewGroup parent) {
        Log.d("MyAdapter", "Position:" + position + "---"
                + String.valueOf(System.currentTimeMillis()));
        ViewHolder holder;
        if (convertView == null) {
            final LayoutInflater inflater = (LayoutInflater) mContext
                    .getSystemService(Context.LAYOUT_INFLATER_SERVICE);
            convertView = inflater.inflate(R.layout.list_item_icon_text, null);
            holder = new ViewHolder();
            holder.icon = (ImageView) convertView.findViewById(R.id.icon);
            holder.text = (TextView) convertView.findViewById(R.id.text);
            convertView.setTag(holder);
        } else {
            holder = (ViewHolder) convertView.getTag();
        }
        holder.icon.setImageResource(R.drawable.icon);
        holder.text.setText(mData[position]);
        return convertView;
    }

    static class ViewHolder {
        ImageView icon;
        TextView text;
    }
}

MainActivity.java

public class MainActivity extends ListActivity {
    private BadAdapter/GoodAdapter mAdapter;

    private String[] mArrData;

    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
        mArrData = new String[1000];
        for (int i = 0; i < 1000; i++) {
            mArrData[i] = "Google IO Adapter";
        }
        mAdapter = new BadAdapter/GoodAdapter(this, mArrData);
        setListAdapter(mAdapter);
    }
}

3）ThreadLocal使用不当

　　如果我们粗暴的把ThreadLocal设置null,而不调用remove()方法或set(null),那么就可能造成ThreadLocal绑定的对象长期也能被回收，因而产出内存泄露。

1：查找内存泄露的方法。

与C++的内存不同，C++的内存泄露是由于分配了内存给某程序但是又没有回收造成的。Java的内存泄露则是引用了一些垃圾对象，意思就是说程序引用了某些对象，但是又从来没有使用过。

Jave中的引用分为3种：

强引用：引用为空的时候，Java的垃圾回收器会处理。一般来说自己写的程序大部分都是强引用。

软引用：堆内存不够的时候，Java的垃圾回收器会处理这类引用。

弱引用：Jave的垃圾回收器每次都会回收这类引用。

如何用MAT来分析，前提是Android开发和测试的工具安装完整，SDK，Eclipse：

1.打开Eclipse

2.选择 Help->Install New Software;

3.在Work with中添加站点：http://download.eclipse.org/mat/1.0/update-site/（这个地址可能会变化，但是新的地址可以在官方网站上找到：http://www.eclipse.org/mat/downloads.php ）

4.生成.hprof文件:插入SD卡（Android机器很多程序都需要插入SD卡），并将设备连接到PC，在Eclipse中的DDMS中选择要测试的进程，然后点击Update Heap 和Dump HPROF file两个Button。

.hprof 文件会自动保存在SD卡上，把 .hprof 文件拷贝到PC上的\ android-sdk-windows\tools目录下。这个由DDMS生成的文件不能直接在MAT打开，需要转换。

运行cmd打开命令行，cd到\ android-sdk-windows\tools所在目录，并输入命令hprof-conv xxxxx.hprof yyyyy.hprof，其中xxxxx.hprof为原始文件，yyyyy.hprof为转换过后的文件。转换过后的文件自动放在android-sdk-windows\tools 目录下。

OK，到此为止，.hprof文件处理完毕，可以用来分析内存泄露情况了。

5.打开MAT：

在Eclipse中点击Windows->Open Perspective->Other->Memory Analysis

6.导入.hprof文件

在MAT中点击 File->Open File,浏览到刚刚转换而得到的.hprof文件，并Cancel掉自动生成报告,点击Dominator Tree，并按Package分组，选择自己所定义的Package 类点右键，在弹出菜单中选择List objects->With incoming references。

这时会列出所有可疑类，右键点击某一项，并选择Path to GC Roots->exclude weak/soft references,会进一步筛选出跟程序相关的所有有内存泄露的类。据此，可以追踪到代码中的某一个产生泄露的类。

2：相关知识

Android将进程分为六大类：

前台进程（foreground）：目前正在屏幕上显示的进程和一些系统进程。举例来说，Dialer Storage，Google Search等系统进程就是前台进程；再举例来说，当你运行一个程序，如浏览器，当浏览器界面在前台显示时，浏览器属于前台进程（foreground），但一旦你按home回到主界面，浏览器就变成了后台程序（background）。我们最不希望终止的进程就是前台进程。
　　可见进程（visible）：可见进程是一些不再前台，但用户依然可见的进程，举个例来说：widget、输入法等，都属于visible。这部分进程虽然不在前台，但与我们的使用也密切相关，我们也不希望它们被终止（你肯定不希望时钟、天气，新闻等widget被终止，那它们将无法同步，你也不希望输入法被终止，否则你每次输入时都需要重新启动输入法）
　　次要服务（secondary server）：目前正在运行的一些服务（主要服务，如拨号等，是不可能被进程管理终止的，故这里只谈次要服务），举例来说：谷歌企业套件，Gmail内部存储，联系人内部存储等。这部分服务虽然属于次要服务，但很一些系统功能依然息息相关，我们时常需要用到它们，所以也太希望他们被终止。
　　后台进程（hidden）：虽然作者用了hidden这个词，但实际即是后台进程（background），就是我们通常意义上理解的启动后被切换到后台的进程，如浏览器，阅读器等。当程序显示在屏幕上时，他所运行的进程即为前台进程（foreground），一旦我们按home返回主界面（注意是按home，不是按back），程序就驻留在后台，成为后台进程（background）。后台进程的管理策略有多种：有较为积极的方式，一旦程序到达后台立即终止，这种方式会提高程序的运行速度，但无法加速程序的再次启动；也有较消极的方式，尽可能多的保留后台程序，虽然可能会影响到单个程序的运行速度，但在再次启动已启动的程序时，速度会有所提升。这里就需要用户根据自己的使用习惯找到一个平衡点
　　内容供应节点（content provider）：没有程序实体，进提供内容供别的程序去用的，比如日历供应节点，邮件供应节点等。在终止进程时，这类程序应该有较高的优先权
　　空进程（empty）：没有任何东西在内运行的进程，有些程序，比如BTE，在程序退出后，依然会在进程中驻留一个空进程，这个进程里没有任何数据在运行，作用往往是提高该程序下次的启动速度或者记录程序的一些历史信息。这部分进程无疑是应该最先终止的。系统会对进程的重要性进行评估，并将重要性以“oom_adj”这个数值表示出来，赋予各个进程；（系统会根据“oom_adj”来判断需要结束哪些进程，一般来说，“oom_adj”的值越大，该进程被系统选中终止的可能就越高）
　　前台程序的“oom_adj”值为0，这意味着它不会被系统终止，一旦它不可访问后，会获得个更高的“oom_adj”，作者推测“oom_adj”的值是根据软件在LRU列表中的位置所决定的； 
Android不同于Linux，有一套自己独特的进程管理模块，这个模块有更强的可定制性，可根据“oom_adj”值的范围来决定进程管理策略，比如可以设定“当内存小于X时，结束“oom_adj”大于Y的进程”。这给了进程管理脚本的编写以更多的选择。