在實踐中我們發現對于大多數的應用領域，評估一個垃圾收集(GC)算法如何根據如下兩個標準：

吞吐量越高算法越好

暫停時間越短算法越好

首先讓我們來明確垃圾收集(GC)中的兩個術語:吞吐量(throughput)和暫停時間(pause times)。 JVM在專門的線程(GC threads)中執行GC。 只要GC線程是活動的，它們將與應用程序線程(application threads)爭用當前可用CPU的時鐘周期。 簡單點來說，吞吐量是指應用程序線程用時占程序總用時的比例。 例如，吞吐量99/100意味著100秒的程序執行時間應用程序線程運行了99秒， 而在這一時間段內GC線程只運行了1秒。

術語”暫停時間”是指一個時間段內應用程序線程讓與GC線程執行而完全暫停。 例如，GC期間100毫秒的暫停時間意味著在這100毫秒期間內沒有應用程序線程是活動的。 如果說一個正在運行的應用程序有100毫秒的“平均暫停時間”，那么就是說該應用程序所有的暫停時間平均長度為100毫秒。 同樣，100毫秒的“最大暫停時間”是指該應用程序所有的暫停時間最大不超過100毫秒。

吞吐量 VS 暫停時間

高吞吐量最好因為這會讓應用程序的最終用戶感覺只有應用程序線程在做“生產性”工作。 直覺上，吞吐量越高程序運行越快。 低暫停時間最好因為從最終用戶的角度來看不管是GC還是其他原因導致一個應用被掛起始終是不好的。 這取決于應用程序的類型，有時候甚至短暫的200毫秒暫停都可能打斷終端用戶體驗。 因此，具有低的最大暫停時間是非常重要的，特別是對于一個交互式應用程序。

不幸的是”高吞吐量”和”低暫停時間”是一對相互競爭的目標（矛盾）。這樣想想看，為了清晰起見簡化一下：GC需要一定的前提條件以便安全地運行。 例如，必須保證應用程序線程在GC線程試圖確定哪些對象仍然被引用和哪些沒有被引用的時候不修改對象的狀態。 為此，應用程序在GC期間必須停止(或者僅在GC的特定階段，這取決于所使用的算法)。 然而這會增加額外的線程調度開銷：直接開銷是上下文切換，間接開銷是因為緩存的影響。 加上JVM內部安全措施的開銷，這意味著GC及隨之而來的不可忽略的開銷，將增加GC線程執行實際工作的時間。 因此我們可以通過盡可能少運行GC來最大化吞吐量，例如，只有在不可避免的時候進行GC，來節省所有與它相關的開銷。

然而，僅僅偶爾運行GC意味著每當GC運行時將有許多工作要做，因為在此期間積累在堆中的對象數量很高。 單個GC需要花更多時間來完成， 從而導致更高的平均和最大暫停時間。 因此，考慮到低暫停時間，最好頻繁地運行GC以便更快速地完成。 這反過來又增加了開銷并導致吞吐量下降，我們又回到了起點。
綜上所述，在設計（或使用）GC算法時??，我們必須確定我們的目標：一個GC算法??只可能針對兩個目標之一（即只專注于最大吞吐量或最小暫停時間），或嘗試找到一個二者的折衷。

一、Throughput收集器

1.1、Throughput收集器兩個基本操作介紹

Throughput收集器有兩個基本操作：一是回收新生代垃圾（Minor GC）；二是回收老年代垃圾(Full GC)。

下圖是新生代回收之前和之后的情況

Minor GC通常在新生代空間用盡時。新生代收集器會把Eden空間中的所有對象挪走：一部分被移到Survivor中，其它被移到老年代。

?

下圖是Full gc之前之后的對比圖

老年代垃圾收集會收集新生代中所有的對象（包括Survivor中的對象），只有那些有活躍引用的對象，或者已經經過壓縮整理的對象會繼續在老年代中留存下來。其余對象將被回收。

?

1.2、堆大小的自適應調整和靜態調整

Throughput收集器的調優幾乎都是圍繞停頓時間進行的，尋求堆的總體大小、新生代的大小以及老年代大小之間的平衡。

兩種取舍：

1、經典技術上的取舍，時間和空間上的取舍；

2、第二個取舍與完成垃圾回收所需的時長有關，增大堆能夠減少Full GC停頓發送的頻率，但也有局限性：由于GC時間變得更長，平均響應時間也會變長（老年代空間很大，在回收老年代耗時很長）。類似的，為新生代分配更多的堆空間可以縮短Full GC的停頓時間，不過這又增大老年代垃圾回收的頻率（因為老年代空間保持不變或者變得更小了）。

看一個示例說明堆大小與吞吐量的關系，在該示例中是關閉了JVM自適應調整堆大小的情況

在Throughput收集器中，可自適應調整會重新分配堆（以及代）的大小。使用這些標志可以設置相應的性能指標：-XX:MaxGCPauseMillis=N和-XX:GCTimeRatio=N。

-XX:MaxGCPauseMillis：標志用于設定應用可承受的最大停頓時間。可以設置為0或者一些非常小的值，譬如50毫秒。請注意，這個標志設定的值同時影響Minor GC和Full GC。如果設置的值非常小，那么應用的老年代最終就會非常小，導致頻繁的Full GC（例如，希望程序在50毫秒內完成垃圾回收，這將會觸發非常頻繁的Full GC，對應用程序的性能而言將是災難性的。）。因此，設定該值時，盡量保持理性，將該值設定為可達到的合理值。缺省情況下， 不設置該參數。

-XX:GCTimeRatio：標志可以設置你希望應用程序在垃圾回收上花費多少時間（與應用線程的運行時間相比較）。它是一個百分比，默認值是99。

N值得計算稍微有些復雜。將N值代入下面的公式可以計算理想情況下應用線程的運行時間所占的百分比：

將GCTimeRatio的默認值99代入公式得到0.99，這意味著應用程序的運行時間占總時間的99%，只有1%的時間消耗在垃圾回收上。

再例如GCTimeRatio=95時，并不是意味使用總時間5%去做垃圾回收；它表示的是最多會使用總時間的1.94%去做垃圾回收。所以，如果你期望程序工作時間在95%，則需要變換一下公式計算GCTimeRatio是一個更容易操作的方法。

對于95%（0.95）的吞吐量目標，利用該公式計算出的GCTimeRatio是19。

JVM使用這兩個標志在堆的初始值（-Xms，-XmX）之間的堆的大小。MaxGCPauseMillis的優先級別最高：如果設置了這個值，新生代和老年代會隨之進行調整，直到滿足對應停頓時間的目標。一旦這個目標達成，堆的總容量就開始逐漸增大，直到運行時間的比率達到設定值。這兩個目標都達成后，開始縮減堆大小，盡可能的以最小堆大小來滿足這兩個目標。

二、HotSpot虛擬機上的垃圾收集

該系列的第五部分我們已經討論過年輕代的垃圾收集器。 對于年老代，HotSpot虛擬機提供兩類垃圾收集算法(除了新的G1垃圾收集算法)，第一類算法試圖最大限度地提高吞吐量，而第二類算法試圖最小化暫停時間。 今天我們的重點是第一類，”面向吞吐量”的垃圾收集算法。
我們希望把重點放在JVM配置參數上，所以我只會簡要概述HotSpot提供的面向吞吐量(throughput-oriented)垃圾收集算法。 當年老代中由于缺乏空間導致對象分配失敗時會觸發垃圾收集器(事實上，”分配”的通常是指從年輕代提升到年老代的對象)。 從所謂的”GC根”(GC roots)開始，搜索堆中的可達對象并將其標記為活著的，之后，垃圾收集器將活著的對象移到年老代的一塊無碎片(non-fragmented)內存塊中，并標記剩余的內存空間是空閑的。 也就是說，我們不像復制策略那樣移到一個不同的堆區域，像年輕代垃圾收集算法所做的那樣。 相反地，我們把所有的對象放在一個堆區域中，從而對該堆區域進行碎片整理。 垃圾收集器使用一個或多個線程來執行垃圾收集。 當使用多個線程時，算法的不同步驟被分解，使得每個收集線程大多時候工作在自己的區域而不干擾其他線程。 在垃圾收集期間，所有的應用程序線程暫停，只有垃圾收集完成之后才會重新開始。 現在讓我們來看看跟面向吞吐量垃圾收集算法有關的重要JVM配置參數。

-XX:+UseSerialGC

我們使用該標志來激活串行垃圾收集器，例如單線程面向吞吐量垃圾收集器。 無論年輕代還是年老代都將只有一個線程執行垃圾收集。 該標志被推薦用于只有單個可用處理器核心的JVM。 在這種情況下，使用多個垃圾收集線程甚至會適得其反，因為這些線程將爭用CPU資源，造成同步開銷，卻從未真正并行運行。

-XX:+UseParallelGC

有了這個標志，我們告訴JVM使用多線程并行執行年輕代垃圾收集。 在我看來，Java 6中不應該使用該標志因為-XX:+UseParallelOldGC顯然更合適。 需要注意的是Java 7中該情況改變了一點(詳見本概述)，就是-XX:+UseParallelGC能達到-XX:+UseParallelOldGC一樣的效果。

-XX:+UseParallelOldGC

該標志的命名有點不巧，因為”老”聽起來像”過時”。 然而，”老”實際上是指年老代，這也解釋了為什么-XX:+UseParallelOldGC要優于-XX:+UseParallelGC：除了激活年輕代并行垃圾收集，也激活了年老代并行垃圾收集。 當期望高吞吐量，并且JVM有兩個或更多可用處理器核心時，我建議使用該標志。
作為旁注，HotSpot的并行面向吞吐量垃圾收集算法通常稱為”吞吐量收集器”，因為它們旨在通過并行執行來提高吞吐量。

-XX:ParallelGCThreads

通過-XX:ParallelGCThreads=<value>我們可以指定并行垃圾收集的線程數量。 例如，-XX:ParallelGCThreads=6表示每次并行垃圾收集將有6個線程執行。 如果不明確設置該標志，虛擬機將使用基于可用(虛擬)處理器數量計算的默認值。 決定因素是由Java Runtime。availableProcessors()方法的返回值N，如果N<=8，并行垃圾收集器將使用N個垃圾收集線程，如果N>8個可用處理器，垃圾收集線程數量應為3+5N/8。
當JVM獨占地使用系統和處理器時使用默認設置更有意義。 但是，如果有多個JVM(或其他耗CPU的系統)在同一臺機器上運行，我們應該使用-XX:ParallelGCThreads來減少垃圾收集線程數到一個適當的值。 例如，如果4個以服務器方式運行的JVM同時跑在在一個具有16核處理器的機器上，設置-XX:ParallelGCThreads=4是明智的，它能使不同JVM的垃圾收集器不會相互干擾。

-XX:-UseAdaptiveSizePolicy

吞吐量垃圾收集器提供了一個有趣的(但常見，至少在現代JVM上)機制以提高垃圾收集配置的用戶友好性。 這種機制被看做是HotSpot在Java 5中引入的”人體工程學”概念的一部分。 通過人體工程學，垃圾收集器能將堆大小動態變動像GC設置一樣應用到不同的堆區域，只要有證據表明這些變動將能提高GC性能。 “提高GC性能”的確切含義可以由用戶通過-XX:GCTimeRatio和-XX:MaxGCPauseMillis(見下文)標記來指定。
重要的是要知道人體工程學是默認激活的。 這很好，因為自適應行為是JVM最大優勢之一。 不過，有時我們需要非常清楚對于特定應用什么樣的設置是最合適的，在這些情況下，我們可能不希望JVM混亂我們的設置。 每當我們發現處于這種情況時，我們可以考慮通過-XX:-UseAdaptiveSizePolicy停用一些人體工程學。

-XX:GCTimeRatio

通過-XX:GCTimeRatio=<value>我們告訴JVM吞吐量要達到的目標值。 更準確地說，-XX:GCTimeRatio=N指定目標應用程序線程的執行時間(與總的程序執行時間)達到N/(N+1)的目標比值。 例如，通過-XX:GCTimeRatio=9我們要求應用程序線程在整個執行時間中至少9/10是活動的(因此，GC線程占用其余1/10)。 基于運行時的測量，JVM將會嘗試修改堆和GC設置以期達到目標吞吐量。 -XX:GCTimeRatio的默認值是99，也就是說，應用程序線程應該運行至少99%的總執行時間。

-XX:MaxGCPauseMillis

通過-XX:GCTimeRatio=<value>告訴JVM最大暫停時間的目標值(以毫秒為單位)。 在運行時，吞吐量收集器計算在暫停期間觀察到的統計數據(加權平均和標準偏差)。 如果統計表明正在經歷的暫停其時間存在超過目標值的風險時，JVM會修改堆和GC設置以降低它們。 需要注意的是，年輕代和年老代垃圾收集的統計數據是分開計算的，還要注意，默認情況下，最大暫停時間沒有被設置。
如果最大暫停時間和最小吞吐量同時設置了目標值，實現最大暫停時間目標具有更高的優先級。 當然，無法保證JVM將一定能達到任一目標，即使它會努力去做。 最后，一切都取決于手頭應用程序的行為。
當設置最大暫停時間目標時，我們應注意不要選擇太小的值。 正如我們現在所知道的，為了保持低暫停時間，JVM需要增加GC次數，那樣可能會嚴重影響可達到的吞吐量。 這就是為什么對于要求低暫停時間作為主要目標的應用程序(大多數是Web應用程序)，我會建議不要使用吞吐量收集器，而是選擇CMS收集器。 CMS收集器是本系列下一部分的主題。

總結

以上是生活随笔為你收集整理的评估一个垃圾收集(GC)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。