android GC內存泄露問題

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綁定的對象長期也能被回收，於是產出內存泄露。

 

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