1.垃圾收集算法的核心思想

　　Java語言建立了垃圾收集機制，用以跟蹤正在使用的對象和發(fā)現(xiàn)并回收不再使用(引用)的對象。該機制可以有效防范動態(tài)內(nèi)存分配中可能發(fā)生的兩個危險：因內(nèi)存垃圾過多而引發(fā)的內(nèi)存耗盡，以及不恰當?shù)膬?nèi)存釋放所造成的內(nèi)存非法引用。

　　垃圾收集算法的核心思想是：對虛擬機可用內(nèi)存空間，即堆空間中的對象進行識別，如果對象正在被引用，那么稱其為存活對象，反之，如果對象不再被引用，則為垃圾對象，可以回收其占據(jù)的空間，用于再分配。垃圾收集算法的選擇和垃圾收集系統(tǒng)參數(shù)的合理調(diào)節(jié)直接影響著系統(tǒng)性能，因此需要開發(fā)人員做比較深入的了解。

2.觸發(fā)主GC(Garbage Collector)的條件

　　JVM進行次GC的頻率很高,但因為這種GC占用時間極短,所以對系統(tǒng)產(chǎn)生的影響不大。更值得關(guān)注的是主GC的觸發(fā)條件,因為它對系統(tǒng)影響很明顯?？偟膩碚f,有兩個條件會觸發(fā)主GC:
　?、佼攽?yīng)用程序空閑時,即沒有應(yīng)用線程在運行時,GC會被調(diào)用。因為GC在優(yōu)先級最低的線程中進行,所以當應(yīng)用忙時,GC線程就不會被調(diào)用,但以下條件除外。

　?、贘ava堆內(nèi)存不足時,GC會被調(diào)用。當應(yīng)用線程在運行,并在運行過程中創(chuàng)建新對象,若這時內(nèi)存空間不足,JVM就會強制地調(diào)用GC線程,以便回收內(nèi)存用于新的分配。若GC一次之后仍不能滿足內(nèi)存分配的要求,JVM會再進行兩次GC作進一步的嘗試,若仍無法滿足要求,則 JVM將報“out of memory”的錯誤,Java應(yīng)用將停止。

　　由于是否進行主GC由JVM根據(jù)系統(tǒng)環(huán)境決定,而系統(tǒng)環(huán)境在不斷的變化當中,所以主GC的運行具有不確定性,無法預(yù)計它何時必然出現(xiàn),但可以確定的是對一個長期運行的應(yīng)用來說,其主GC是反復(fù)進行的。

3.減少GC開銷的措施

　　根據(jù)上述GC的機制,程序的運行會直接影響系統(tǒng)環(huán)境的變化,從而影響GC的觸發(fā)。若不針對GC的特點進行設(shè)計和編碼,就會出現(xiàn)內(nèi)存駐留等一系列負面影響。為了避免這些影響,基本的原則就是盡可能地減少垃圾和減少GC過程中的開銷。具體措施包括以下幾個方面:

　　(1)不要顯式調(diào)用System.gc()

　　此函數(shù)建議JVM進行主GC,雖然只是建議而非一定,但很多情況下它會觸發(fā)主GC,從而增加主GC的頻率,也即增加了間歇性停頓的次數(shù)。

　　(2)盡量減少臨時對象的使用

　　臨時對象在跳出函數(shù)調(diào)用后,會成為垃圾,少用臨時變量就相當于減少了垃圾的產(chǎn)生,從而延長了出現(xiàn)上述第二個觸發(fā)條件出現(xiàn)的時間,減少了主GC的機會。

　　(3)對象不用時最好顯式置為Null

　　一般而言,為Null的對象都會被作為垃圾處理,所以將不用的對象顯式地設(shè)為Null,有利于GC收集器判定垃圾,從而提高了GC的效率。

　　(4)盡量使用StringBuffer,而不用String來累加字符串(詳見blog另一篇文章JAVA中String與StringBuffer)

　　由于String是固定長的字符串對象,累加String對象時,并非在一個String對象中擴增,而是重新創(chuàng)建新的String對象,如 Str5=Str1+Str2+Str3+Str4,這條語句執(zhí)行過程中會產(chǎn)生多個垃圾對象,因為對次作“+”操作時都必須創(chuàng)建新的String對象,但這些過渡對象對系統(tǒng)來說是沒有實際意義的,只會增加更多的垃圾。避免這種情況可以改用StringBuffer來累加字符串,因StringBuffer 是可變長的,它在原有基礎(chǔ)上進行擴增,不會產(chǎn)生中間對象。

　　(5)能用基本類型如Int,Long,就不用Integer,Long對象

　　基本類型變量占用的內(nèi)存資源比相應(yīng)對象占用的少得多,如果沒有必要,最好使用基本變量。

　　(6)盡量少用靜態(tài)對象變量

　　靜態(tài)變量屬于全局變量,不會被GC回收,它們會一直占用內(nèi)存。

　　(7)分散對象創(chuàng)建或刪除的時間

　　集中在短時間內(nèi)大量創(chuàng)建新對象,特別是大對象,會導(dǎo)致突然需要大量內(nèi)存,JVM在面臨這種情況時,只能進行主GC,以回收內(nèi)存或整合內(nèi)存碎片, 從而增加主GC的頻率。集中刪除對象,道理也是一樣的。它使得突然出現(xiàn)了大量的垃圾對象,空閑空間必然減少,從而大大增加了下一次創(chuàng)建新對象時強制主GC 的機會。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

很多人把Java的“效率低下”歸咎于不能自由管理內(nèi)存，但我們也知道將內(nèi)存管理封裝起來的好處，這里就不贅述。

Java中的內(nèi)存分配是隨著new一個新的對象來實現(xiàn)的，這個很簡單，而且也還是有一些可以“改進”內(nèi)存回收的機制的，其中最顯眼的就是這個System.gc()函數(shù)。

乍一看這個函數(shù)似乎是可以進行垃圾回收的，可事實并不是那么簡單。

其實這個gc()函數(shù)的作用只是提醒虛擬機：程序員希望進行一次垃圾回收。但是它不能保證垃圾回收一定會進行，而且具體什么時候進行是取決于具體的虛擬機的，不同的虛擬機有不同的對策。

那么下一個問題就是：gc()進行回收的準則是什么？也就是說什么樣的對象可以被回收？

簡單來說就是：沒有被任何可達變量指向的對象。這里的可達是我發(fā)明的……意思就是能夠找到的，那什么樣的是不可達的呢？

比如說：

a.v = b;
b.v = c;
/*
*Watch out !
*/
a.v = d;

看一下這段代碼：

第一行：對象a的變量v指向了對象b
第二行：對象b的變量v指向了對象c
第六行：對象a的變量v指向了變量d。

這個時候，雖然變量c指向的對象有c 以及b.v指向它，但是它們都已經(jīng)不可達了，為什么？因為唯一可以找到它們的是a.v，但是現(xiàn)在a.v指向了d，所以他們就是不可達的了。
理由也很直觀：沒有任何可達變量指向你，你還有活下去的理由嗎？你就算活下去誰能找得到你呢？

所以說，C++中將釋放了的指針置為null的習慣要保留到Java中，因為這有可能是你釋放內(nèi)存的唯一途徑。

最后的箴言：不要頻繁使用gc函數(shù)。

最后給大家說下為什么需要GC

應(yīng)用程序?qū)Y源操作，通常簡單分為以下幾個步驟：

1、為對應(yīng)的資源分配內(nèi)存

2、初始化內(nèi)存

3、使用資源

4、清理資源

5、釋放內(nèi)存

應(yīng)用程序?qū)Y源（內(nèi)存使用）管理的方式，常見的一般有如下幾種：

1、手動管理：C,C++

2、計數(shù)管理：COM

3、自動管理：.NET,Java,PHP,GO…

但是，手動管理和計數(shù)管理的復(fù)雜性很容易產(chǎn)生以下典型問題：

1.程序員忘記去釋放內(nèi)存

2.應(yīng)用程序訪問已經(jīng)釋放的內(nèi)存

產(chǎn)生的后果很嚴重，常見的如內(nèi)存泄露、數(shù)據(jù)內(nèi)容亂碼，而且大部分時候，程序的行為會變得怪異而不可預(yù)測，還有Access Violation等。

.NET、Java等給出的解決方案，就是通過自動垃圾回收機制GC進行內(nèi)存管理。這樣，問題1自然得到解決，問題2也沒有存在的基礎(chǔ)。

總結(jié)：無法自動化的內(nèi)存管理方式極容易產(chǎn)生bug，影響系統(tǒng)穩(wěn)定性，尤其是線上多服務(wù)器的集群環(huán)境，程序出現(xiàn)執(zhí)行時bug必須定位到某臺服務(wù)器然后dump內(nèi)存再分析bug所在，極其打擊開發(fā)人員編程積極性，而且源源不斷的類似bug讓人厭惡。

最新評論