亚洲乱码中文字幕综合,中国熟女仑乱hd,亚洲精品乱拍国产一区二区三区,一本大道卡一卡二卡三乱码全集资源,又粗又黄又硬又爽的免费视频

android的GC內(nèi)存泄露問題

 更新時間:2016年11月18日 17:14:54   作者:Devin Zhang  
本篇文章主要介紹了android GC內(nèi)存泄露問題,具有一定的參考價值,有需要的可以了解一下。

1. android內(nèi)存泄露概念

不少人認(rèn)為JAVA程序,因為有垃圾回收機(jī)制,應(yīng)該沒有內(nèi)存泄露。其實如果我們一個程序中,已經(jīng)不再使用某個對象,但是因為仍然有引用指向它,垃圾回收器就無法回收它,當(dāng)然該對象占用的內(nèi)存就無法被使用,這就造成了內(nèi)存泄露。如果我們的java運(yùn)行很久,而這種內(nèi)存泄露不斷的發(fā)生,最后就沒內(nèi)存可用了。當(dāng)然java的,內(nèi)存泄漏和C/C++是不一樣的。如果java程序完全結(jié)束后,它所有的對象就都不可達(dá)了,系統(tǒng)就可以對他們進(jìn)行垃圾回收,它的內(nèi)存泄露僅僅限于它本身,而不會影響整個系統(tǒng)的。C/C++的內(nèi)存泄露就比較糟糕了,它的內(nèi)存泄露是系統(tǒng)級,即使該C/C++程序退出,它的泄露的內(nèi)存也無法被系統(tǒng)回收,永遠(yuǎn)不可用了,除非重啟機(jī)器。

Android的一個應(yīng)用程序的內(nèi)存泄露對別的應(yīng)用程序影響不大。為了能夠使得Android應(yīng)用程序安全且快速的運(yùn)行,Android的每個應(yīng)用程序都會使用一個專有的Dalvik虛擬機(jī)實例來運(yùn)行,也就是說每個應(yīng)用程序都是在屬于自己的進(jìn)程中運(yùn)行的。Android為不同類型的進(jìn)程分配了不同的內(nèi)存使用上限,如果程序在運(yùn)行過程中出現(xiàn)了內(nèi)存泄漏的而造成應(yīng)用進(jìn)程使用的內(nèi)存超過了這個上限,則會被系統(tǒng)視為內(nèi)存泄漏,從而被kill掉,這使得僅僅自己的進(jìn)程被kill掉,而不會影響其他進(jìn)程(如果是system_process等系統(tǒng)進(jìn)程出問題的話,則會引起系統(tǒng)重啟)。

內(nèi)存泄露示例:

/*此時,所有的Object對象都沒有被釋放,因為變量v引用這些對象。實際上這些對象已經(jīng)是無用的,但還被引用,GC就無能為力了(事實上GC認(rèn)為它還有用),這一點是導(dǎo)致內(nèi)存泄漏最重要的原因。*/
Vector v = new Vector(10);   
for (int i = 1; i < 100; i++)   {    
  Object o = new Object();    
  v.add(o);    
  o = null;   
 }

循環(huán)申請Object對象,并將所申請的對象放入一個Vector中,如果僅僅釋放對象本身,但因為Vector仍然引用該對象,所以這個對象對GC來說是不可回收的。因此,如果對象加入到Vector后,還必須從Vector中刪除,最簡單的方法就是將Vector對象設(shè)置為null。

總的來說,內(nèi)存管理中的內(nèi)存泄漏產(chǎn)生的主要原因:保留下來卻永遠(yuǎn)不再使用的對象引用。

2.引起內(nèi)存泄露的情況

1)資源對象沒關(guān)閉造成的內(nèi)存泄露

資源性對象比如(Cursor,F(xiàn)ile文件等)往往都用了一些緩沖,我們在不使用的時候,應(yīng)該及時關(guān)閉它們,以便它們的緩沖及時回收內(nèi)存。它們的緩沖不僅存在于java虛擬機(jī)內(nèi),還存在于java虛擬機(jī)外。如果我們僅僅是把它的引用設(shè)置為null,而不關(guān)閉它們,往往會造成內(nèi)存泄露。因為有些資源性對象,比如SQLiteCursor(在析構(gòu)函數(shù)finalize(),如果我們沒有關(guān)閉它,它自己會調(diào)close()關(guān)閉),如果我們沒有關(guān)閉它,系統(tǒng)在回收它時也會關(guān)閉它,但是這樣的效率太低了。因此對于資源性對象在不使用的時候,應(yīng)該調(diào)用它的close()函數(shù),將其關(guān)閉掉,然后才置為null.在我們的程序退出時一定要確保我們的資源性對象已經(jīng)關(guān)閉。

程序中經(jīng)常會進(jìn)行查詢數(shù)據(jù)庫的操作,但是經(jīng)常會有使用完畢Cursor后沒有關(guān)閉的情況。如果我們的查詢結(jié)果集比較小,對內(nèi)存的消耗不容易被發(fā)現(xiàn),只有在常時間大量操作的情況下才會復(fù)現(xiàn)內(nèi)存問題,這樣就會給以后的測試和問題排查帶來困難和風(fēng)險。

2)一些不良代碼成內(nèi)存壓力

有些代碼并不造成內(nèi)存泄露,但是它們,或是對沒使用的內(nèi)存沒進(jìn)行有效及時的釋放,或是沒有有效的利用已有的對象而是頻繁的申請新內(nèi)存,對內(nèi)存的回收和分配造成很大影響的,容易迫使虛擬機(jī)不得不給該應(yīng)用進(jìn)程分配更多的內(nèi)存,造成不必要的內(nèi)存開支。

a.Bitmap沒調(diào)用recycle()

Bitmap對象在不使用時,我們應(yīng)該先調(diào)用recycle()釋放內(nèi)存,然后才它設(shè)置為null。

雖然recycle()從源碼上看,調(diào)用它應(yīng)該能立即釋放Bitmap的主要內(nèi)存,但是測試結(jié)果顯示它并沒能立即釋放內(nèi)存。但是我它應(yīng)該還是能大大的加速Bitmap的主要內(nèi)存的釋放。

b.構(gòu)造Adapter時,沒有使用緩存的convertView

以構(gòu)造ListView的BaseAdapter為例,在BaseAdapter中提共了方法:

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

來向ListView提供每一個item所需要的view對象。初始時ListView會從BaseAdapter中根據(jù)當(dāng)前的屏幕布局實例化一定數(shù)量的view對象,同時ListView會將這些view對象緩存起來。當(dāng)向上滾動ListView時,原先位于最上面的list item的view對象會被回收,然后被用來構(gòu)造新出現(xiàn)的最下面的list item。這個構(gòu)造過程就是由getView()方法完成的,getView()的第二個形參View convertView就是被緩存起來的list item的view對象(初始化時緩存中沒有view對象則convertView是null)。

由此可以看出,如果我們不去使用convertView,而是每次都在getView()中重新實例化一個View對象的話,即浪費時間,也造成內(nèi)存垃圾,給垃圾回收增加壓力,如果垃圾回收來不及的話,虛擬機(jī)將不得不給該應(yīng)用進(jìn)程分配更多的內(nèi)存,造成不必要的內(nèi)存開支。

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>

能引起內(nèi)存泄露的代碼: 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;
  }
}

修正優(yōu)化示例代碼示例代碼: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使用不當(dāng)

如果我們粗暴的把ThreadLocal設(shè)置null,而不調(diào)用remove()方法或set(null),那么就可能造成ThreadLocal綁定的對象長期也能被回收,因而產(chǎn)出內(nèi)存泄露。

以上就是本文的全部內(nèi)容,希望對大家的學(xué)習(xí)有所幫助,也希望大家多多支持腳本之家。

相關(guān)文章

最新評論