在C++中，對象所佔的內存在程序結束運行之前一直被佔用，在明確釋放之前不能分配給其它對象；而在Java中，當沒有對象引用指向原先分配給某個對象的內存時，該內存便成爲垃圾。JVM的一個系統級線程會自動釋放該內存塊。垃圾收集器系統有自己的一套方案來判斷哪個內存塊是應該被回收的，哪個是不符合要求暫不回收的。垃圾收集器在一個Java程序中的執行是自動的，不能強制執行，即使程序員能明確地判斷出有一塊內存已經無用了，是應該回收的，程序員也不能強制垃圾收集器回收該內存塊。程序員唯一能做的就是通過調用System. gc 方法來”建議”執行垃圾收集器，但其是否可以執行，什麼時候執行卻都是不可知的。這也是垃圾收集器的最主要的缺點。當然相對於它給程序員帶來的巨大方便性而言，這個缺點是瑕不掩瑜的。
1.垃圾收集器的主要特點
1．垃圾收集器的工作目標是回收已經無用的對象的內存空間，從而避免內存滲漏體的產生，節省內存資源，避免程序代碼的崩潰。
2．垃圾收集器判斷一個對象的內存空間是否無用的標準是：如果該對象不能再被程序中任何一個”活動的部分”所引用，此時我們就說，該對象的內存空間已經無用。所謂”活動的部分”，是指程序中某部分參與程序的調用，正在執行過程中，尚未執行完畢。
當一個方法執行完畢，其中的局部變量就會超出使用範圍，此時可以被當作垃圾收集，但以後每當該方法再次被調用時，其中的局部變量便會被重新創建。
3．垃圾收集器線程雖然是作爲低優先級的線程運行，但在系統可用內存量過低的時候，它可能會突發地執行來挽救內存資源。當然其執行與否也是不可預知的。
4．垃圾收集器不可以被強制執行，但程序員可以通過調用System. gc方法來建議執行垃圾收集器。
5．不能保證一個無用的對象一定會被垃圾收集器收集，也不能保證垃圾收集器在一段Java語言代碼中一定會執行。因此在程序執行過程中被分配出去的內存空間可能會一直保留到該程序執行完畢，除非該空間被重新分配或被其他方法回收。由此可見，完全徹底地根絕內存滲漏體的產生也是不可能的。但是請不要忘記，Java的垃圾收集器畢竟使程序員從手工回收內存空間的繁重工作中解脫了出來。設想一個程序員要用C或C++來編寫一段10萬行語句的代碼，那麼他一定會充分體會到Java的垃圾收集器的優點！
6．同樣沒有辦法預知在一組均符合垃圾收集器收集標準的對象中，哪一個會被首先收集。
7．循環引用對象不會影響其被垃圾收集器收集。
8．可以通過將對象的引用變量（reference variables，即句柄handles）初始化爲null值，來暗示垃圾收集器來收集該對象。但此時，如果該對象連接有事件監聽器（典型的 AWT組件），那它還是不可以被收集。所以在設一個引用變量爲null值之前，應注意該引用變量指向的對象是否被監聽，若有，要首先除去監聽器，然後纔可以賦空值。
9．每一個對象都有一個finalize( )方法，這個方法是從Object類繼承來的。
10．finalize( )方法用來回收內存以外的系統資源，就像是文件處理器和網絡連接器。該方法的調用順序和用來調用該方法的對象的創建順序是無關的。換句話說，書寫程序時該方法的順序和方法的實際調用順序是不相干的。請注意這只是finalize( )方法的特點。
11．每個對象只能調用finalize( )方法一次。如果在finalize( )方法執行時產生異常（exception），則該對象仍可以被垃圾收集器收集。
12．垃圾收集器跟蹤每一個對象，收集那些不可到達的對象（即該對象沒有被程序的任何”活的部分”所調用），回收其佔有的內存空間。但在進行垃圾收集的時候，垃圾收集器會調用finalize( )方法，通過讓其他對象知道它的存在，而使不可到達的對象再次”復甦”爲可到達的對象。既然每個對象只能調用一次finalize( )方法，所以每個對象也只可能”復甦”一次。
13．finalize( )方法可以明確地被調用，但它卻不能進行垃圾收集。
14．finalize( )方法可以被重載（overload），但只有具備初始的finalize( )方法特點的方法纔可以被垃圾收集器調用。
15．子類的finalize( )方法可以明確地調用父類的finalize( )方法，作爲該子類對象的最後一次適當的操作。但Java編譯器卻不認爲這是一次覆蓋操作（overriding），所以也不會對其調用進行檢查。
16．當finalize( )方法尚未被調用時，System. runFinalization( )方法可以用來調用finalize( )方法，並實現相同的效果，對無用對象進行垃圾收集。
17．當一個方法執行完畢，其中的局部變量就會超出使用範圍，此時可以被當作垃圾收集，但以後每當該方法再次被調用時，其中的局部變量便會被重新創建。
18．Java語言使用了一種”標記交換區的垃圾收集算法”。該算法會遍歷程序中每一個對象的句柄，爲被引用的對象做標記，然後回收尚未做標記的對象。所謂遍歷可以簡單地理解爲”檢查每一個”。
19．Java語言允許程序員爲任何方法添加finalize( )方法，該方法會在垃圾收集器交換回收對象之前被調用。但不要過分依賴該方法對系統資源進行回收和再利用，因爲該方法調用後的執行結果是不可預知的。
總之，在Java語言中，判斷一塊內存空間是否符合垃圾收集器收集標準的標準只有兩個：
1．給對象賦予了空值null，以下再沒有調用過。
2．給對象賦予了新值，既重新分配了內存空間。
最後再次提醒一下，一塊內存空間符合了垃圾收集器的收集標準，並不意味着這塊內存空間就一定會被垃圾收集器收集。
Java語言建立了垃圾收集機制，用以跟蹤正在使用的對象和發現並回收不再使用(引用)的對象。該機制可以有效防範動態內存分配中可能發生的兩個危險：因內存垃圾過多而引發的內存耗盡，以及不恰當的內存釋放所造成的內存非法引用。
垃圾收集算法的核心思想是：對虛擬機可用內存空間，即堆空間中的對象進行識別，如果對象正在被引用，那麼稱其爲存活對象，反之，如果對象不再被引用，則爲垃圾對象，可以回收其佔據的空間，用於再分配。垃圾收集算法的選擇和垃圾收集系統參數的合理調節直接影響着系統性能，因此需要開發人員做比較深入的瞭解。
2.finalize()方法
在JVM垃圾回收器收集一個對象之前，一般要求程序調用適當的方法釋放資源，但在沒有明確釋放資源的情況下，Java提供了缺省機制來終止該對象心釋放資源，這個方法就是finalize（）。它的原型爲：
protected void finalize() throws Throwable
在finalize()方法返回之後，對象消失，垃圾收集開始執行。原型中的throws Throwable表示它可以拋出任何類型的異常。
之所以要使用finalize()，是存在着垃圾回收器不能處理的特殊情況。假定你的對象（並非使用new方法）獲得了一塊“特殊”的內存區域，由於垃圾回收器只知道那些顯示地經由new分配的內存空間，所以它不知道該如何釋放這塊“特殊”的內存區域，那麼這個時候java允許在類中定義一個由finalize()方法。
特殊的區域例如：
1）由於在分配內存的時候可能採用了類似 C語言的做法，而非JAVA的通常new做法。這種情況主要發生在native method中，比如native method調用了C/C++方法malloc()函數系列來分配存儲空間，但是除非調用free()函數，否則這些內存空間將不會得到釋放，那麼這個時候就可能造成內存泄漏。但是由於free()方法是在C/C++中的函數，所以finalize()中可以用本地方法來調用它。以釋放這些“特殊”的內存空間。
2）又或者打開的文件資源，這些資源不屬於垃圾回收器的回收範圍。
換言之，finalize()的主要用途是釋放一些其他做法開闢的內存空間，以及做一些清理工作。因爲在JAVA中並沒有提夠像“析構”函數或者類似概念的函數，要做一些類似清理工作的時候，必須自己動手創建一個執行清理工作的普通方法，也就是override Object這個類中的finalize()方法。例如，假設某一個對象在創建過程中會將自己繪製到屏幕上，如果不是明確地從屏幕上將其擦出，它可能永遠都不會被清理。如果在finalize()加入某一種擦除功能，當GC工作時，finalize()得到了調用，圖像就會被擦除。要是GC沒有發生，那麼這個圖像就會被一直保存下來。
一旦垃圾回收器準備好釋放對象佔用的存儲空間，首先會去調用finalize()方法進行一些必要的清理工作。只有到下一次再進行垃圾回收動作的時候，纔會真正釋放這個對象所佔用的內存空間。
在普通的清除工作中，爲清除一個對象，那個對象的用戶必須在希望進行清除的地點調用一個清除方法。這與C++”析構函數”的概念稍有抵觸。在C++中，所有對象都會破壞（清除）。或者換句話說，所有對象都”應該”破壞。若將C++對象創建成一個本地對象，比如在堆棧中創建（在Java中是不可能的，Java都在堆中），那麼清除或破壞工作就會在”結束花括號”所代表的、創建這個對象的作用域的末尾進行。若對象是用new創建的（類似於Java），那麼當程序員調用C++的 delete命令時（Java沒有這個命令），就會調用相應的析構函數。若程序員忘記了，那麼永遠不會調用析構函數，我們最終得到的將是一個內存”漏洞”，另外還包括對象的其他部分永遠不會得到清除。
在C++中所有的對象運用delete()一定會被銷燬，而JAVA裏的對象並非總會被垃圾回收器回收。In another word, 1 對象可能不被垃圾回收，2 垃圾回收並不等於“析構”，3 垃圾回收只與內存有關。也就是說，並不是如果一個對象不再被使用，是不是要在finalize()中釋放這個對象中含有的其它對象呢？不是的。因爲無論對象是如何創建的，垃圾回收器都會負責釋放那些對象佔有的內存。
3.觸發主GC(Garbage Collector)的條件
JVM進行次GC的頻率很高,但因爲這種GC佔用時間極短,所以對系統產生的影響不大。更值得關注的是主GC的觸發條件,因爲它對系統影響很明顯。總的來說,有兩個條件會觸發主GC:
①當應用程序空閒時,即沒有應用線程在運行時,GC會被調用。因爲GC在優先級最低的線程中進行,所以當應用忙時,GC線程就不會被調用,但以下條件除外。
②Java堆內存不足時,GC會被調用。當應用線程在運行,並在運行過程中創建新對象,若這時內存空間不足,JVM就會強制地調用GC線程,以便回收內存用於新的分配。若GC一次之後仍不能滿足內存分配的要求,JVM會再進行兩次GC作進一步的嘗試,若仍無法滿足要求,則 JVM將報“out of memory”的錯誤,Java應用將停止。
由於是否進行主GC由JVM根據系統環境決定,而系統環境在不斷的變化當中,所以主GC的運行具有不確定性,無法預計它何時必然出現,但可以確定的是對一個長期運行的應用來說,其主GC是反覆進行的。
4.減少GC開銷的措施
根據上述GC的機制,程序的運行會直接影響系統環境的變化,從而影響GC的觸發。若不針對GC的特點進行設計和編碼,就會出現內存駐留等一系列負面影響。爲了避免這些影響,基本的原則就是儘可能地減少垃圾和減少GC過程中的開銷。具體措施包括以下幾個方面:
(1)不要顯式調用System.gc()
此函數建議JVM進行主GC,雖然只是建議而非一定,但很多情況下它會觸發主GC,從而增加主GC的頻率,也即增加了間歇性停頓的次數。
(2)儘量減少臨時對象的使用
臨時對象在跳出函數調用後,會成爲垃圾,少用臨時變量就相當於減少了垃圾的產生,從而延長了出現上述第二個觸發條件出現的時間,減少了主GC的機會。
(3)對象不用時最好顯式置爲Null
一般而言,爲Null的對象都會被作爲垃圾處理,所以將不用的對象顯式地設爲Null,有利於GC收集器判定垃圾,從而提高了GC的效率。
(4)儘量使用StringBuffer,而不用String來累加字符串(詳見blog另一篇文章Java中String與StringBuffer)
由於String是固定長的字符串對象,累加String對象時,並非在一個String對象中擴增,而是重新創建新的String對象,如Str5=Str1+Str2+Str3+Str4,這條語句執行過程中會產生多個垃圾對象,因爲對次作“+”操作時都必須創建新的String對象,但這些過渡對象對系統來說是沒有實際意義的,只會增加更多的垃圾。避免這種情況可以改用StringBuffer來累加字符串,因StringBuffer是可變長的,它在原有基礎上進行擴增,不會產生中間對象。
(5)能用基本類型如Int,Long,就不用Integer,Long對象 基本類型變量佔用的內存資源比相應對象佔用的少得多,如果沒有必要,最好使用基本變量。
(6)儘量少用靜態對象變量
靜態變量屬於全局變量,不會被GC回收,它們會一直佔用內存。
(7)分散對象創建或刪除的時間
集中在短時間內大量創建新對象,特別是大對象,會導致突然需要大量內存,JVM在面臨這種情況時,只能進行主GC,以回收內存或整合內存碎片,從而增加主GC的頻率。集中刪除對象,道理也是一樣的。它使得突然出現了大量的垃圾對象,空閒空間必然減少,從而大大增加了下一次創建新對象時強制主GC的機會。
5.Java 內存泄漏
由於採用了垃圾回收機制，任何不可達對象(對象不再被引用)都可以由垃圾收集線程回收。因此通常說的Java 內存泄漏其實是指無意識的、非故意的對象引用，或者無意識的對象保持。無意識的對象引用是指代碼的開發人員本來已經對對象使用完畢，卻因爲編碼的錯誤而意外地保存了對該對象的引用(這個引用的存在並不是編碼人員的主觀意願)，從而使得該對象一直無法被垃圾回收器回收掉，這種本來以爲可以釋放掉的卻最終未能被釋放的空間可以認爲是被“泄漏了”。
考慮下面的程序,在ObjStack類中,使用push和pop方法來管理堆棧中的對象。兩個方法中的索引(index)用於指示堆棧中下一個可用位置。push方法存儲對新對象的引用並增加索引值,而pop方法減小索引值並返回堆棧最上面的元素。在main方法中,創建了容量爲64的棧,並64次調用push方法向它添加對象,此時index的值爲64,隨後又32次調用pop方法,則index的值變爲32,出棧意味着在堆棧中的空間應該被收集。但事實上,pop方法只是減小了索引值,堆棧仍然保持着對那些對象的引用。故32個無用對象不會被GC回收,造成了內存滲漏。
通過以上對垃圾收集器特點的瞭解，你應該可以明確垃圾收集器的作用，和垃圾收集器判斷一塊內存空間是否無用的標準。簡單地說，當你爲一個對象賦值爲null並且重新定向了該對象的引用者，此時該對象就符合垃圾收集器的收集標準。
判斷一個對象是否符合垃圾收集器的收集標準，這是SUN公司程序員認證考試中垃圾收集器部分的重要考點（可以說，這是唯一的考點）。所以，考生在一段給定的代碼中，應該能夠判斷出哪個對象符合垃圾收集器收集的標準，哪個不符合。下面結合幾種認證考試中可能出現的題型來具體講解：
Object obj = new Object ( )
我們知道，obj爲Object的一個句柄。當出現new關鍵字時，就給新建的對象分配內存空間，而obj的值就是新分配的內存空間的首地址，即該對象的值(請特別注意，對象的值和對象的內容是不同含義的兩個概念：對象的值就是指其內存塊的首地址，即對象的句柄；而對象的內容則是其具體的內存塊)。此時如果有 obj = null； 則obj指向的內存塊此時就無用了，因爲下面再沒有調用該變量了。
請再看以下三種認證考試時可能出現的題型：
程序段1：
1．fobj = new Object ( )
2．fobj. Method ( )
3．fobj = new Object ( )
4．fobj. Method ( )
問：這段代碼中，第幾行的fobj 符合垃圾收集器的收集標準？
答：第3行。因爲第3行的fobj被賦了新值，產生了一個新的對象，即換了一塊新的內存空間，也相當於爲第1行中的fobj賦了null值。這種類型的題在認證0考試中是最簡單的。
程序段2：
1．Object sobj = new Object ( )
2．Object sobj = null
3．Object sobj = new Object ( )
4．sobj = new Object ( )
問：這段代碼中，第幾行的內存空間符合垃圾收集器的收集標準？
答：第1行和第3行。因爲第2行爲sobj賦值爲null，所以在此第1行的sobj符合垃圾收集器的收集標準。而第4行相當於爲sobj賦值爲null，所以在此第3行的sobj也符合垃圾收集器的收集標準。
如果有一個對象的句柄a，且你把a作爲某個構造器的參數，
即 new Constructor ( a )的時候，即使你給a賦值爲null，a也不符合垃圾收集器的收集標準。直到由上面構造器構造的新對象被賦空值時，a纔可以被垃圾收集器收集。
程序段3：
1．Object aobj = new Object ( )
2．Object bobj = new Object ( )
3．Object cobj = new Object ( )
4．aobj = bobj;
5．aobj = cobj;
6．cobj = null;
7．aobj = null;
問：這段代碼中，第幾行的內存空間符合垃圾收集器的收集標準？
答：第7行。注意這類題型是認證考試中可能遇到的最難題型了。
行1-3分別創建了Object類的三個對象：aobj，bobj，cobj
行4：此時對象aobj的句柄指向bobj，所以該行的執行不能使aobj符合垃圾收集器的收集標準。
行5：此時對象aobj的句柄指向cobj，所以該行的執行不能使aobj符合垃圾收集器的收集標準。
行6：此時仍沒有任何一個對象符合垃圾收集器的收集標準。
行7：對象cobj符合了垃圾收集器的收集標準，因爲cobj的句柄指向單一的地址空間。在第6行的時候，cobj已經被賦值爲null，但由cobj同時還指向了aobj（第5行），所以此時cobj並不符合垃圾收集器的收集標準。而在第7行，aobj所指向的地址空間也被賦予了空值null，這就說明了，由cobj所指向的地址空間已經被完全地賦予了空值。所以此時cobj最終符合了垃圾收集器的收集標準。 但對於aobj和bobj，仍然無法判斷其是否符合收集標準。