JDK1.8使用的垃圾回收器和執(zhí)行GC的時長以及GC的頻率

GC介紹        

GC就是垃圾回收器。因為內(nèi)存空間是有限的，創(chuàng)建的每個對象和變量都會占據(jù)內(nèi)存，gc做的就是對象清除將內(nèi)存釋放出來。其中堆是虛擬機中進行垃圾回收的主要場所，其次是方法區(qū)。

垃圾回收器 

新生代收集器：       

• Serial：是一類用于新生代的單線程收集器，采用復(fù)制算法。        
• ParNew：是Serial的多線程版本。        
• Parallel Scavenge：多線程收集器，其注重點在于盡可能的縮短垃圾收集時用戶線程的停頓時間。

老年代收集器：       

• Serial Old：是Serial收集器的老年代版本，也是單線程收集器，采用標記-整理算法。        
• Parallel Old：是Parallel收集器的老年代版本，采用標記-整理算法。        
• CMS：一種以獲取最短回收停頓時間為目標的收集器。采用的算法是“標記-清除”。

新生代和老年代收集器：

G1收集器：G1收集器是一款面向服務(wù)端應(yīng)用的垃圾收集器，目前是JDK9的默認垃圾收集器。

Java詳細信息

java -XX:+PrintCommandLineFlags -version

cmd展示信息：

C:\Users\xx>java -XX:+PrintCommandLineFlags -version
-XX:InitialHeapSize=266295296 -XX:MaxHeapSize=4260724736 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)

JDK1.8默認使用的垃圾回收器是-XX:+UseParallelGC，代表為 “Parallel Scavenge” + “Parallel Old”。

在JVM中垃圾回收器配置實現(xiàn)的搭配組合如下：

GC優(yōu)化條件

若滿足一下條件，則GC一般不需要優(yōu)化。

• Minor GC執(zhí)行時間不超過50ms;
• Minor GC執(zhí)行不頻繁，大概10秒執(zhí)行一次；
• Full GC執(zhí)行時間不到1s;
• Full GC執(zhí)行頻率不算頻繁，不低于10分鐘1次。

垃圾收集器分類與GC性能指標

概述

垃圾收集器沒有在規(guī)范中進行過多的規(guī)定，可以由不同的廠商、不同版本的JVM來實現(xiàn)。

由于JDK的版本處于高速迭代過程中，因此Java發(fā)展至今已經(jīng)衍生了眾多的GC版本。

從不同角度分析垃圾收集器，可以將GC分為不同的類型。

Java不同版本新特性：

• 語法層面：Lambda表達式、switch、自動拆箱裝箱、enum
• API層面：Stream API、新的日期時間、Optional、String、集合框架
• 底層優(yōu)化：JVM優(yōu)化、GC的變化、元空間、靜態(tài)域、字符串常量池位置變化

垃圾收集器分類

(一)、按線程數(shù)分（垃圾回收線程數(shù)），可以分為：串行垃圾回收器和并行垃圾回收器

串行回收指的是在同一時間段內(nèi)只允許有一個CPU用于執(zhí)行垃圾回收操作，此時工作線程被暫停（STW），直至垃圾收集工作結(jié)束。

• 在諸如單CPU處理器或者較小的應(yīng)用內(nèi)存等硬件平臺不是特別優(yōu)越的場合，串行回收器的性能表現(xiàn)可以超過并行回收器和并發(fā)回收器。所以，串行回收默認被應(yīng)用在客戶端的Client模式下的JVM中。
• 在并發(fā)能力比較強的CPU上，并行回收器產(chǎn)生的停頓時間要短于串行回收器。

和串行回收相反，并行收集可以運用多個CPU同時執(zhí)行垃圾回收，因此提升了應(yīng)用的吞吐量，不過并行回收仍然與串行回收一樣，采用獨占式，使用了“stop-the-world”機制。

(二)、按工作模式，可以分為：并發(fā)式垃圾回收器和獨占式垃圾回收器。

• 并發(fā)式垃圾回收器與應(yīng)用程序線程交替工作，以盡可能減少應(yīng)用程序的停頓時間。
• 獨占式垃圾回收器（Stop the world）一旦運行，就停止應(yīng)用程序中的所有用戶線程，直到垃圾回收過程完全結(jié)束。

(三)、按碎片處理方式分，可以分為：壓縮式垃圾回收器和非壓縮式垃圾回收器

• 壓縮式垃圾回收器會在回收完成后，對存活對象進行壓縮整理，消除回收后的碎片。
• 非壓縮式的垃圾回收器不進行這步操作。

(四)、按工作的內(nèi)存區(qū)間分，可以分為：年輕代垃圾回收器和老年代垃圾回收器

評估GC的性能指標

• 吞吐量：運行用戶代碼的時間占總運行時間的比例（總運行時間 = 程序的運行時間 + 內(nèi)存回收的時間）
• 垃圾收集開銷：吞吐量的補數(shù)，垃圾收集所用時間與總運行時間的比例。
• 暫停時間：執(zhí)行垃圾收集時，程序的工作線程被暫停的時間。
• 收集頻率：相對于應(yīng)用程序的執(zhí)行，收集操作發(fā)生的頻率。
• 內(nèi)存占用：Java堆區(qū)所占的內(nèi)存大小。
• 快速：一個對象從誕生到被回收所經(jīng)歷的時間。

吞吐量、暫停時間、內(nèi)存占用 這三者共同構(gòu)成一個“不可能三角”。三者總體的表現(xiàn)會隨著技術(shù)進步而越來越好。一款優(yōu)秀的收集器通常最多同時滿足其中的兩項。 這三項里，暫停時間的重要性日益凸顯。因為隨著硬件發(fā)展，內(nèi)存占用多些越來越能容忍，硬件性能的提升也有助于降低收集器運行時對應(yīng)用程序的影響，即提高了吞吐量。而內(nèi)存的擴大，對延遲反而帶來負面效果。 簡單來說，主要抓住兩點：

這三項里，暫停時間的重要性日益凸顯。因為隨著硬件發(fā)展，內(nèi)存占用多些越來越能容忍，硬件性能的提升也有助于降低收集器運行時對應(yīng)用程序的影響，即提高了吞吐量。而內(nèi)存的擴大，對延遲反而帶來負面效果。 簡單來說，主要抓住兩點：

(一)、吞吐量

吞吐量就是CPU用于運行用戶代碼的時間與CPU總消耗時間的比值，即吞吐量 = 運行用戶代碼時間 /（運行用戶代碼時間 + 垃圾收集時間）。

比如：虛擬機總共運行了100分鐘，其中垃圾收集花掉1分鐘，那吞吐量就是99%。

這種情況下，應(yīng)用程序能容忍較高的暫停時間，因此，高吞吐量的應(yīng)用程序有更長的時間基準，快速響應(yīng)是不必考慮的。

吞吐量優(yōu)先，意味著在單位時間內(nèi)，STW的時間最短：0.2+0.2 = 0.4。

(二)、暫停時間

“暫停時間”是指一個時間段內(nèi)應(yīng)用程序線程暫停，讓GC線程執(zhí)行的狀態(tài)。

例如，GC期間100毫秒的暫停時間意味著在這100毫秒期間內(nèi)沒有應(yīng)用程序線程是活動的。暫停時間優(yōu)先，意味著盡可能讓單次STW的時間最短：0.1+0.1 + 0.1+ 0.1+ 0.1 = 0.5。

(三)、吞吐量vs暫停時間

高吞吐量較好，因為這會讓應(yīng)用程序的最終用戶感覺只有應(yīng)用程序線程在做“生產(chǎn)性”工作。直覺上，吞吐量越高程序運行越快。

低暫停時間（低延遲）較好，因為從最終用戶的角度來看不管是GC還是其他原因?qū)е乱粋€應(yīng)用被掛起始終是不好的。這取決于應(yīng)用程序的類型，有時候甚至短暫的200毫秒暫停都可能打斷終端用戶體驗。因此，具有低的較大暫停時間是非常重要的，特別是對于一個交互式應(yīng)用程序。

不幸的是”高吞吐量”和”低暫停時間”是一對相互競爭的目標（矛盾）。

因為如果選擇以吞吐量優(yōu)先，那么必然需要降低內(nèi)存回收的執(zhí)行頻率，但是這樣會導(dǎo)致GC需要更長的暫停時間來執(zhí)行內(nèi)存回收。

相反的，如果選擇以低延遲優(yōu)先為原則，那么為了降低每次執(zhí)行內(nèi)存回收時的暫停時間，也只能頻繁地執(zhí)行內(nèi)存回收，但這又引起了年輕代內(nèi)存的縮減和導(dǎo)致程序吞吐量的下降。

在設(shè)計（或使用）GC算法時，我們必須確定我們的目標：一個GC算法只可能針對兩個目標之一（即只專注于較大吞吐量或最小暫停時間），或嘗試找到一個二者的折衷。

現(xiàn)在標準：在最大吞吐量優(yōu)先的情況下，降低停頓時間。

7種經(jīng)典的垃圾收集器

• 串行回收器：Serial、Serial old
• 并行回收器：ParNew、Parallel Scavenge、Parallel old
• 并發(fā)回收器：CMS、G1

7款經(jīng)典收集器與垃圾分代之間的關(guān)系如下圖：

• 新生代收集器：Serial、ParNew、Paralle1 Scavenge；
• 老年代收集器：Serial old、Parallel old、CMS；
• 整堆收集器：G1；

垃圾收集器的組合關(guān)系

兩個收集器間有連線，表明它們可以搭配使用：Serial/Serial old、Serial/CMS、ParNew/Serial old、ParNew/CMS、Parallel Scavenge/Serial 0ld、Parallel Scavenge/Parallel 0ld、G1；
其中Serial old作為CMS出現(xiàn)"Concurrent Mode Failure"失敗的后備預(yù)案。

• （紅色虛線）由于維護和兼容性測試的成本，在JDK 8時將Serial+CMS、ParNew+Serial old這兩個組合聲明為廢棄（JEP173），并在JDK9中完全取消了這些組合的支持（JEP214），即：移除。
• （綠色虛線）JDK14中：棄用Paralle1 Scavenge和Serialold GC組合（JEP366）
• （青色虛線）JDK14中：刪除CMS垃圾回收器（JEP363）

為什么要有很多收集器，一個不夠嗎？因為Java的使用場景很多，移動端，服務(wù)器等。所以就需要針對不同的場景，提供不同的垃圾收集器，提高垃圾收集的性能。

雖然我們會對各個收集器進行比較，但并非為了挑選一個最好的收集器出來。沒有一種放之四海皆準、任何場景下都適用的完美收集器存在，更加沒有萬能的收集器。所以我們選擇的只是對具體應(yīng)用最合適的收集器。

如何查看默認垃圾收集器?

第一種方式：-XX:+PrintCommandLineFlags：查看命令行相關(guān)參數(shù)（包含使用的垃圾收集器）

輸出結(jié)果如下：-XX:+UseParallelGC，可以看到，在JDK1.8中默認使用的Parallel Scavenge/Parallel 0ld這一對垃圾回收器。

-XX:InitialHeapSize=257920192 -XX:MaxHeapSize=4126723072 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC?

第二種方式：使用命令行指令：jps查看進程ID +  jinfo -flag 相關(guān)垃圾回收器參數(shù) 進程ID。

總結(jié)

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論