Java垃圾收集器概述

垃圾收集器的操做

• 查找未使用的對象，釋放內存，並壓縮堆，避免內存碎片

• 一個java程序，有執行應用程序邏輯的線程和執行GC的線程組。當GC跟蹤對象引用，或在內存中移動對象，它必須確保應用程序線程沒有使用這些對象。 尤爲如此在GC移動對象：在該操做期間對象的內存位置發生變化，所以沒有應用程序線程能夠訪問該對象。全部應用程序線程中止時的暫停叫作 stop-the-world 暫停.

Generational Garbage Collectors（分代垃圾收集器）

• 儘管細節有所不一樣，但全部垃圾收集器都經過拆分堆爲不一樣的代來工做。這些被稱爲老年代，和年輕代。年輕代進一步分爲eden、survivor。劃分年輕代的基本原理是：許多對象被使用很是短的時間。

minor GC

• 當年輕代內存滿時，垃圾收集器將中止全部應用程序線程並清空 
  年輕代。 丟棄再也不使用的對象，仍在使用的對象被轉移到survivor之一或者老年代。

優勢：

• 由於年輕代只是整個堆的一部分，處理它比處理整個堆更快
• 因爲移動了全部倖存對象到survivor之一或者老年代，所以年輕代自動的在收集時壓縮。

全部GC算法在收集年輕代時都會 stop-the-world pauses

full GC

• 隨着對象被移動到老年代，最終它也將填滿，JVM將須要在老年代中找到再也不使用的任何對象並丟棄它們。這是GC算法最大的區別。 這最簡單算法是中止全部應用程序線程，找到未使用的對象並釋放內存，而後壓縮堆。此過程稱爲 full GC，它一般會致使應用程序線程的長暫停。

• 另外一方面，有可能 - 雖然計算複雜 - 找到不使用的對象在應用程序線程運行時; CMS和G1都採用這種方法。由於掃描未使用對象的階段能夠在不中止應用程序線程的狀況下發生，CMS和G1稱爲併發收集器。 他們也是稱爲低暫停（有時是不正確的，沒法暫停）的收集器，由於它們最小化須要中止全部應用程序線程。 併發收集器也有不一樣壓縮老年代的方法。

• 使用CMS或G1收集器時，應用程序一般會更少（和更短暫）停頓。 權衡是應用程序將使用更多的CPU

• 在任何狀況下都須要權衡利弊。在測量單獨響應時間的應用程序（如Java EE服務器）中，請考慮如下幾點：

  • 個別請求將受到暫停時間的影響 - 更重要的是對於 full GC，須要很長的暫停時間。 若是最小化暫停對響應的影響時間是目標，併發收集器將更合適。
  • 若是平均響應時間比異常值更重要（即90％響應時間），吞吐量收集器一般會產生更好的結果。
  • 使用併發收集器避免長時間停頓的好處來自於額外的CPU使用費用。

• 相似地，批處理應用程序中垃圾收集器的選擇由如下指導權衡：

  • 若是有足夠的CPU可用，則使用併發收集器以免full GC暫停將使工做更快完成。
  • 若是CPU受限，則併發收集器的額外CPU消耗將會增長 致使批處理做業須要更多時間。