Android中垃圾回收詳解
阿新 • • 發佈：2019-01-22
在這個例子中，一個新的物件被建立，由於它沒有使用，所以該物件迅速地變為不可達，程式編譯後，執行命令： java -verbosegc TestGC 後結果為：
[Full GC 168K->97K(1984K)， 0.0253873 secs]
機器的環境為，Windows 2000 + JDK1.3.1，箭頭前後的資料168K和97K分別表示垃圾收集GC前後所有存活物件使用的記憶體容量，說明有168K-97K=71K的物件容量被回收，括號內的資料1984K為堆記憶體的總容量，收集所需要的時間是0.0253873秒（這個時間在每次執行的時候會有所不同）。
需要注意的是，呼叫System.gc()也僅僅是一個請求(建議)。JVM接受這個訊息後，並不是立即做垃圾回收，而只是對幾個垃圾回收演算法做了加權，使垃圾回收操作容易發生，或提早發生，或回收較多而已。
在JVM垃圾回收器收集一個物件之前，一般要求程式呼叫適當的方法釋放資源，但在沒有明確釋放資源的情況下，Java提供了預設機制來終止該物件心釋放資源，這個方法就是finalize（）。它的原型為：
protected void finalize() throws Throwable
在finalize()方法返回之後，物件消失，垃圾收集開始執行。原型中的throws Throwable表示它可以丟擲任何型別的異常。
之所以要使用finalize()，是存在著垃圾回收器不能處理的特殊情況。假定你的物件（並非使用new方法）獲得了一塊“特殊”的記憶體區域，由於垃圾回收器只知道那些顯示地經由new分配的記憶體空間，所以它不知道該如何釋放這塊“特殊”的記憶體區域，那麼這個時候java允許在類中定義一個由finalize()方法。
換言之，finalize()的主要用途是釋放一些其他做法開闢的記憶體空間，以及做一些清理工作。因為在JAVA中並沒有提夠像“析構”函式或者類似概念的函式，要做一些類似清理工作的時候，必須自己動手建立一個執行清理工作的普通方法，也就是override Object這個類中的finalize()方法。例如，假設某一個物件在建立過程中會將自己繪製到螢幕上，如果不是明確地從螢幕上將其擦出，它可能永遠都不會被清理。如果在finalize()加入某一種擦除功能，當GC工作時，finalize()得到了呼叫，影象就會被擦除。要是GC沒有發生，那麼這個影象就會
一旦垃圾回收器準備好釋放物件佔用的儲存空間，首先會去呼叫finalize()方法進行一些必要的清理工作。只有到下一次再進行垃圾回收動作的時候，才會真正釋放這個物件所佔用的記憶體空間。
在普通的清除工作中，為清除一個物件，那個物件的使用者必須在希望進行清除的地點呼叫一個清除方法。這與C++"解構函式"的概念稍有抵觸。在C++中，所有物件都會破壞（清除）。或者換句話說，所有物件都"應該"破壞。若將C++物件建立成一個本地物件，比如在堆疊中建立（在Java中是不可能的，Java都在堆中），那麼清除或破壞工作就會在"結束花括號"所代表的、建立這個物件的作用域的末尾進行。若物件是用new建立的（類似於Java），那麼當程式設計師呼叫C++的 delete命令時（Java沒有這個命令），就會呼叫相應的解構函式。若程式設計師忘記了，那麼永遠不會呼叫解構函式，我們最終得到的將是一個記憶體"漏洞"，另外還包括物件的其他部分永遠不會得到清除。
相反，Java不允許我們建立本地（區域性）物件--無論如何都要使用new。但在Java中，沒有"delete"命令來釋放物件，因為垃圾回收器會幫助我們自動釋放儲存空間。所以如果站在比較簡化的立場，我們可以說正是由於存在垃圾回收機制，所以Java沒有解構函式。然而，隨著以後學習的深入，就會知道垃圾收集器的存在並不能完全消除對解構函式的需要，或者說不能消除對解構函式代表的那種機制的需要（原因見下一段。另外finalize()函式是在垃圾回收器準備釋放物件佔用的儲存空間的時候被呼叫的，絕對不能直接呼叫finalize()，所以應儘量避免用它）。若希望執行除釋放儲存空間之外的其他某種形式的清除工作，仍然必須呼叫Java中的一個方法。它等價於C++的解構函式，只是沒後者方便。
在C++中所有的物件運用delete()一定會被銷燬，而JAVA裡的物件並非總會被垃圾回收器回收。In another word, 1 物件可能不被垃圾回收，2 垃圾回收並不等於“析構”，3 垃圾回收只與記憶體有關。也就是說，並不是如果一個物件不再被使用，是不是要在finalize()中釋放這個物件中含有的其它物件呢？不是的。因為無論物件是如何建立的，垃圾回收器都會負責釋放那些物件佔有的記憶體。
5. 觸發主GC（Garbage Collector）的條件
JVM進行次GC的頻率很高,但因為這種GC佔用時間極短,所以對系統產生的影響不大。更值得關注的是主GC的觸發條件,因為它對系統影響很明顯。總的來說,有兩個條件會觸發主GC:
1)當應用程式空閒時,即沒有應用執行緒在執行時,GC會被呼叫。因為GC在優先順序最低的執行緒中進行,所以當應用忙時,GC執行緒就不會被呼叫,但以下條件除外。
2)Java堆記憶體不足時,GC會被呼叫。當應用執行緒在執行,並在執行過程中建立新物件,若這時記憶體空間不足,JVM就會強制地呼叫GC執行緒,以便回收記憶體用於新的分配。若GC一次之後仍不能滿足記憶體分配的要求,JVM會再進行兩次GC作進一步的嘗試,若仍無法滿足要求,則 JVM將報“out of memory”的錯誤,Java應用將停止。
由於是否進行主GC由JVM根據系統環境決定,而系統環境在不斷的變化當中,所以主GC的執行具有不確定性,無法預計它何時必然出現,但可以確定的是對一個長期執行的應用來說,其主GC是反覆進行的。
6. 減少GC開銷的措施
根據上述GC的機制,程式的執行會直接影響系統環境的變化,從而影響GC的觸發。若不針對GC的特點進行設計和編碼,就會出現記憶體駐留等一系列負面影響。為了避免這些影響,基本的原則就是儘可能地減少垃圾和減少GC過程中的開銷。具體措施包括以下幾個方面:
(1)不要顯式呼叫System.gc()
此函式建議JVM進行主GC,雖然只是建議而非一定,但很多情況下它會觸發主GC,從而增加主GC的頻率,也即增加了間歇性停頓的次數。
(2)儘量減少臨時物件的使用
臨時物件在跳出函式呼叫後,會成為垃圾,少用臨時變數就相當於減少了垃圾的產生,從而延長了出現上述第二個觸發條件出現的時間,減少了主GC的機會。
(3)物件不用時最好顯式置為Null
一般而言,為Null的物件都會被作為垃圾處理,所以將不用的物件顯式地設為Null,有利於GC收集器判定垃圾,從而提高了GC的效率。
(4)儘量使用StringBuffer,而不用String來累加字串
由於String是固定長的字串物件,累加String物件時,並非在一個String物件中擴增,而是重新建立新的String物件,如Str5=Str1+Str2+Str3+Str4,這條語句執行過程中會產生多個垃圾物件,因為對次作“+”操作時都必須建立新的String物件,但這些過渡物件對系統來說是沒有實際意義的,只會增加更多的垃圾。避免這種情況可以改用StringBuffer來累加字串,因StringBuffer是可變長的,它在原有基礎上進行擴增,不會產生中間物件。
(5)能用基本型別如Int,Long,就不用Integer,Long物件
基本型別變數佔用的記憶體資源比相應物件佔用的少得多,如果沒有必要,最好使用基本變數。
(6)儘量少用靜態物件變數
靜態變數屬於全域性變數,不會被GC回收,它們會一直佔用記憶體。
(7)分散物件建立或刪除的時間
集中在短時間內大量建立新物件,特別是大物件,會導致突然需要大量記憶體,JVM在面臨這種情況時,只能進行主GC,以回收記憶體或整合記憶體碎片,從而增加主GC的頻率。集中刪除物件,道理也是一樣的。它使得突然出現了大量的垃圾物件,空閒空間必然減少,從而大大增加了下一次建立新物件時強制主GC的機會。
下面這個例子向大家展示了垃圾收集所經歷的過程，並對前面的陳述進行了總結。
[java] view plaincopyprint?
[Full GC 168K->97K(1984K)， 0.0253873 secs]
機器的環境為，Windows 2000 + JDK1.3.1，箭頭前後的資料168K和97K分別表示垃圾收集GC前後所有存活物件使用的記憶體容量，說明有168K-97K=71K的物件容量被回收，括號內的資料1984K為堆記憶體的總容量，收集所需要的時間是0.0253873秒（這個時間在每次執行的時候會有所不同）。
需要注意的是，呼叫System.gc()也僅僅是一個請求(建議)。JVM接受這個訊息後，並不是立即做垃圾回收，而只是對幾個垃圾回收演算法做了加權，使垃圾回收操作容易發生，或提早發生，或回收較多而已。
在JVM垃圾回收器收集一個物件之前，一般要求程式呼叫適當的方法釋放資源，但在沒有明確釋放資源的情況下，Java提供了預設機制來終止該物件心釋放資源，這個方法就是finalize（）。它的原型為：
protected void finalize() throws Throwable
在finalize()方法返回之後，物件消失，垃圾收集開始執行。原型中的throws Throwable表示它可以丟擲任何型別的異常。
之所以要使用finalize()，是存在著垃圾回收器不能處理的特殊情況。假定你的物件（並非使用new方法）獲得了一塊“特殊”的記憶體區域，由於垃圾回收器只知道那些顯示地經由new分配的記憶體空間，所以它不知道該如何釋放這塊“特殊”的記憶體區域，那麼這個時候java允許在類中定義一個由finalize()方法。
換言之，finalize()的主要用途是釋放一些其他做法開闢的記憶體空間，以及做一些清理工作。因為在JAVA中並沒有提夠像“析構”函式或者類似概念的函式，要做一些類似清理工作的時候，必須自己動手建立一個執行清理工作的普通方法，也就是override Object這個類中的finalize()方法。例如，假設某一個物件在建立過程中會將自己繪製到螢幕上，如果不是明確地從螢幕上將其擦出，它可能永遠都不會被清理。如果在finalize()加入某一種擦除功能，當GC工作時，finalize()得到了呼叫，影象就會被擦除。要是GC沒有發生，那麼這個影象就會
一旦垃圾回收器準備好釋放物件佔用的儲存空間，首先會去呼叫finalize()方法進行一些必要的清理工作。只有到下一次再進行垃圾回收動作的時候，才會真正釋放這個物件所佔用的記憶體空間。
在普通的清除工作中，為清除一個物件，那個物件的使用者必須在希望進行清除的地點呼叫一個清除方法。這與C++"解構函式"的概念稍有抵觸。在C++中，所有物件都會破壞（清除）。或者換句話說，所有物件都"應該"破壞。若將C++物件建立成一個本地物件，比如在堆疊中建立（在Java中是不可能的，Java都在堆中），那麼清除或破壞工作就會在"結束花括號"所代表的、建立這個物件的作用域的末尾進行。若物件是用new建立的（類似於Java），那麼當程式設計師呼叫C++的 delete命令時（Java沒有這個命令），就會呼叫相應的解構函式。若程式設計師忘記了，那麼永遠不會呼叫解構函式，我們最終得到的將是一個記憶體"漏洞"，另外還包括物件的其他部分永遠不會得到清除。
相反，Java不允許我們建立本地（區域性）物件--無論如何都要使用new。但在Java中，沒有"delete"命令來釋放物件，因為垃圾回收器會幫助我們自動釋放儲存空間。所以如果站在比較簡化的立場，我們可以說正是由於存在垃圾回收機制，所以Java沒有解構函式。然而，隨著以後學習的深入，就會知道垃圾收集器的存在並不能完全消除對解構函式的需要，或者說不能消除對解構函式代表的那種機制的需要（原因見下一段。另外finalize()函式是在垃圾回收器準備釋放物件佔用的儲存空間的時候被呼叫的，絕對不能直接呼叫finalize()，所以應儘量避免用它）。若希望執行除釋放儲存空間之外的其他某種形式的清除工作，仍然必須呼叫Java中的一個方法。它等價於C++的解構函式，只是沒後者方便。
在C++中所有的物件運用delete()一定會被銷燬，而JAVA裡的物件並非總會被垃圾回收器回收。In another word, 1 物件可能不被垃圾回收，2 垃圾回收並不等於“析構”，3 垃圾回收只與記憶體有關。也就是說，並不是如果一個物件不再被使用，是不是要在finalize()中釋放這個物件中含有的其它物件呢？不是的。因為無論物件是如何建立的，垃圾回收器都會負責釋放那些物件佔有的記憶體。
5. 觸發主GC（Garbage Collector）的條件
JVM進行次GC的頻率很高,但因為這種GC佔用時間極短,所以對系統產生的影響不大。更值得關注的是主GC的觸發條件,因為它對系統影響很明顯。總的來說,有兩個條件會觸發主GC:
1)當應用程式空閒時,即沒有應用執行緒在執行時,GC會被呼叫。因為GC在優先順序最低的執行緒中進行,所以當應用忙時,GC執行緒就不會被呼叫,但以下條件除外。
2)Java堆記憶體不足時,GC會被呼叫。當應用執行緒在執行,並在執行過程中建立新物件,若這時記憶體空間不足,JVM就會強制地呼叫GC執行緒,以便回收記憶體用於新的分配。若GC一次之後仍不能滿足記憶體分配的要求,JVM會再進行兩次GC作進一步的嘗試,若仍無法滿足要求,則 JVM將報“out of memory”的錯誤,Java應用將停止。
由於是否進行主GC由JVM根據系統環境決定,而系統環境在不斷的變化當中,所以主GC的執行具有不確定性,無法預計它何時必然出現,但可以確定的是對一個長期執行的應用來說,其主GC是反覆進行的。
6. 減少GC開銷的措施
根據上述GC的機制,程式的執行會直接影響系統環境的變化,從而影響GC的觸發。若不針對GC的特點進行設計和編碼,就會出現記憶體駐留等一系列負面影響。為了避免這些影響,基本的原則就是儘可能地減少垃圾和減少GC過程中的開銷。具體措施包括以下幾個方面:
(1)不要顯式呼叫System.gc()
此函式建議JVM進行主GC,雖然只是建議而非一定,但很多情況下它會觸發主GC,從而增加主GC的頻率,也即增加了間歇性停頓的次數。
(2)儘量減少臨時物件的使用
臨時物件在跳出函式呼叫後,會成為垃圾,少用臨時變數就相當於減少了垃圾的產生,從而延長了出現上述第二個觸發條件出現的時間,減少了主GC的機會。
(3)物件不用時最好顯式置為Null
一般而言,為Null的物件都會被作為垃圾處理,所以將不用的物件顯式地設為Null,有利於GC收集器判定垃圾,從而提高了GC的效率。
(4)儘量使用StringBuffer,而不用String來累加字串
由於String是固定長的字串物件,累加String物件時,並非在一個String物件中擴增,而是重新建立新的String物件,如Str5=Str1+Str2+Str3+Str4,這條語句執行過程中會產生多個垃圾物件,因為對次作“+”操作時都必須建立新的String物件,但這些過渡物件對系統來說是沒有實際意義的,只會增加更多的垃圾。避免這種情況可以改用StringBuffer來累加字串,因StringBuffer是可變長的,它在原有基礎上進行擴增,不會產生中間物件。
(5)能用基本型別如Int,Long,就不用Integer,Long物件
基本型別變數佔用的記憶體資源比相應物件佔用的少得多,如果沒有必要,最好使用基本變數。
(6)儘量少用靜態物件變數
靜態變數屬於全域性變數,不會被GC回收,它們會一直佔用記憶體。
(7)分散物件建立或刪除的時間
集中在短時間內大量建立新物件,特別是大物件,會導致突然需要大量記憶體,JVM在面臨這種情況時,只能進行主GC,以回收記憶體或整合記憶體碎片,從而增加主GC的頻率。集中刪除物件,道理也是一樣的。它使得突然出現了大量的垃圾物件,空閒空間必然減少,從而大大增加了下一次建立新物件時強制主GC的機會。
下面這個例子向大家展示了垃圾收集所經歷的過程，並對前面的陳述進行了總結。
[java] view plaincopyprint?