android的GC内存泄露问题

概述1.android内存泄露概念不少人认为JAVA程序，因为有垃圾回收机制，应该没有内存泄露。其实如果我们一个程序中，已经不再使用某个对象，但是因为仍然有引用指向它，垃圾回收器就无法回收它，当然该对象占用的内存就无

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,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,"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绑定的对象长期也能被回收，因而产出内存泄露。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持编程小技巧。

总结

以上是内存溢出为你收集整理的android的GC内存泄露问题全部内容，希望文章能够帮你解决android的GC内存泄露问题所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。