這一篇內容就只有滿滿的干貨,可以說是拿來即用。下面我們廢話少說,走起。
1.GC算法種類
目前OpenJDK中有以下幾種常見的GC算法。
- Serial GC
- Parallel GC
- CMS GC (Concurrent Mark & Sweep)
- G1 GC
- Z GC
目前大多數的人使用Java8居多。如果沒有明確指定GC算法,那么Java8會使用默認Parallel GC。Java9開始 ,默認GC 是G1 GC算法。Java 17 默認也是G1 GC,其中個別版本會有點差異。
下面是常用GC算法使用命令。
GC Algorithm | JVM argument |
---|---|
Serial GC | -XX:+UseSerialGC |
Parallel GC | -XX:+UseParallelGC |
CMS GC | -XX:+UseConcMarkSweepGC |
G1 GC | -XX:+UseG1GC |
ZGC | -XX:+UseZGC |
網上大多數人都對ZGC算法的性能比較稱贊,如果是使用Java11以上的版本,那么可以考慮使用ZGC。奈何大多數同學們包括筆者都在Java8中久久不能自拔,所以我們這一篇就避開ZGC吧。
2. JVM的一些重要參數
JVM中的參數分為3類:
- 標準參數(-),所有的JVM都必須實現這些參數的功能,并且必須向后兼容. 如java -version等
- 非標準參數(-X),默認JVM實現這些功能,不保證所有的JVM都能使用,且不向后兼容。
- 非Stable參數(-XX),這些參數每個JVM實現都會不同,而且將來可能取消,需要謹慎使用
關于非標準參數,我們使用 java -X 命令 即可找到這些參數,
- -Xmn 新生代內存大小,包括E區和兩個S區,使用方法如下:-Xmn65535,-Xmn2048k,-Xmn512m, -Xmn2g (-Xms,-Xmx 也是同一種寫法)
- -Xms 初始堆的大小,堆大小的最小值,默認值是物理內存的1/64(小于1G), 默認情況下,如果堆中可用內存小于40%時(調整參數 -X:MinHeapFreeRatio=40),堆內存會開始增加,一直增加到-Xmx的大小
- -Xmx 堆的最大值,默認是物理內存的1/64,如果Xms和Xmx都不設置的話,兩者的大小會相同,默認情況下,當堆中可用內存大于70%時(調整參數 -X:MaxHeapFreeRatio=70),堆內存會開始減少,一直減少到-Xms的大小
- -Xss 線程的棧內存,默認時1m, 如果項目使用lombok過多的情況下,編譯的時候可能會有棧溢出,就需要配置多一點棧內存。
- -XX:MaxTeurningThreashold 新生代存活對象晉升到老年代的年齡閾值,對象頭中存儲age用了4個bit,所以其最大值為15。默認值是15,如果年輕代垃圾回收后總有一段時間內存的占用仍然保持在某一個高位,過一段時間恢復正常。那么可以適當降低年齡閾值,讓存活對象更早的進入到老年代,提高年輕代的可用率。
3.使用哪種GC最合適
既然大多數同學都使用Java8,那么一定會在Parallel GC 和G1 GC中選擇了。
關于那種GC最合適,我們下面分別來看看。
3.1 如果選擇ParallelGC
ParallelGC是Java8的默認GC算法,對于新生代其使用Parallel Scavenge (復制算法),老年代垃圾回收則不同。
有兩種組合:
- 使用 -XX:UseParallelGC 參數,新生代使用 Parallel Scavenge 垃圾回收算法 ,老年代使用PSMarkSweep(Serial Old)垃圾回收算法(標記-整理算法)。
- 使用 -XX:UseParallelOldGC 參數, 新生代使用 Parallel Scavenge 垃圾回收算法,老年代使用Parallel Old垃圾回收算法(標記整理算法)。
3.1.1 Parallel Scavenge
Parallel Scavenge 是新生代并行回收器,使用復制算法。主要關注的是吞吐量,吞吐量就是JVM運行期間非垃圾回收用時百分比。
Parallel Scavenge 收集器控制吞吐量有兩個重要參數:
- 最大停頓時間 -XX:MaxGCPauseMills=100
其值為大于0的毫秒數,垃圾收集器盡可能保證回收的耗時不超過設定的值,但是并不是越小越好,如果值設置太小,那么GC的頻率會提高,這樣吞吐量就降低了。 - 控制吞吐量大小 -XX:GCTimeRatio=99
其值為0-100的整數,表示吞吐量,默認值是99,表示允許1%的垃圾回收時間占比。 - -XX:UseAdaptiveSizePolicy 自動調節新生代大小比例
啟用這個參數之后,JVM會根據當前系統運行情況收集監控信息,動態調整新生代的比例等等。如果設置了這個參數之后,就不需要在設置新生代大小,Eden以及 S0/S1的比例等參數。
3.1.2 Parallel Old
Parallel Old 是老年代垃圾回收器,負責Full GC ,是一個并行垃圾回收器,整理老年代的時候,是基于“標記-整理”算法,
Parallel Old算法分為3各部分,
- Mark:將老年代的內存,劃分為大小固定的多個連續的Region,標記完存活對象之后,統計每個Region的存活對象數量。Mark階段采用串行標記所有從GC Roots可直達的對象,并行標記所有存活的對象。
- Summary:某個Region的密度 = 存活對象的內存大小/Region內存大小,Summary階段會從左向右計算各個Region的密度,然后找到一個平衡點,這個平衡點左側的Region都不會進入下一個回收階段,另外一側的Region則需要進入到下一個階段進行回收。相當于只回收部分Region,Summary階段是串行執行階段。
- Compaction:利用Summary階段的統計數據,針對需要整理的部分,采用“整理”算法進行操作
- -XX:+ScavengeBeforeFullGC ScavengBeforeFullGC 是 Parallel GC中的一個參數,默認開啟。其作用就是在一次FullGC之前先觸發一次Young GC 來清理新生代,以降低Full GC時 STW的耗時,
3.1.3 ParallelGC調優
Parallel GC會盡量去滿足如下目標:(優先級由高到低)
- 最大停頓時間目標
- 吞吐量目標
- 最小移動目標
對ParallelGC的調優,其目標應盡可能避免Full GC, 這就需要優化對象老年化的頻率,
使用ParallelGC時,垃圾收集的資源開銷應小于5%,如果已經減少到1%甚至更少,基本上已經達到極限了。
Survivor調優:ParallelGC可以自動調整Survivor空間,大部分的程序使用自動調整可以滿足要求,個別應用在需要的情況下可以關閉自動調整,進行手動調整。
-Xmn1024m //新生代大小 -XX:-UseAdaptiveSizePolicy //關閉自適應調整
-XX:SurvivorRatio 可以調整新生代中Survivor與Eden區的比例,例如-XX:SurvivorRatio=6表示S(From) : S(To) : Eden = 1: 1: 6 。其默認值為8
如果發現GC頻率過高,整體新生代又太小,可以增大新生代的大小,從而降低YoungGC的頻率和占用時間。
可以調小 SurvivorRatio的值,在整個新生代不變的情況下,會增大Survivor區的大小(From和To同時增大)。一般情況下Eden區的大小應該比Survivor大很多,如果大量對象都在一次YoungGC后就會回收清理,那么新生代Eden:From:To 為8:1:1就比較合適。如果說很大部分對象的年齡都超過1,即需要在Survivor的From,To中來回轉換幾次之后才能被回收,那么此時可以適當增大一下Survivor區的空間,并且可以將Survivor的空間使用率增大,避免對象年齡增長過快,從而被移動到老年代,造成FullGC。
-XX:-UseAdaptiveSizePolicy //需要關閉Survivor自適應
-XX:TargetSurvivorRatio=< n > //Suvivor空間的使用率,默認是50%
-XX:MaxTenuringThreshold=15 //存活對象年齡,默認15,
并行線程的優化
-XX:ParallelGCThreads= N >
此參數設置年輕代并行收集器的線程數,一般與CPU數量相等,過多的線程數量會影響垃圾回收以及整個程序的性能。
- 默認情況下,當CPU的數量小于8,其值等于CPU數量
- CPU數量大于8個,其值等于3+5*CPU數量 / 8
最大停頓時間
-XX:MaxGCPauseMills=< N > //最大停頓時間,值大于0的毫秒數
垃圾收集器為了將最大停頓時間控制在此參數內,收集器會調整堆的大小和其他的參數。
對于用戶體驗,停頓越短越好,在服務端,會比較注重高并發和高吞吐量。
控制吞吐量大小
-XX:GCTimeRatio=99 //吞吐量
其值為0-100的整數,表示吞吐量,默認值是99,表示允許1%的垃圾回收時間占比。暫停時間越長,那么垃圾回收占用的時間比越大,可能會超過前面的設定比例。
3.2 如果選擇G1
Garbage-First 垃圾回收器是服務器類型的垃圾回收器,主要針對大內存多處理器機器。其主要目標也是低暫停時間,高吞吐量,全局標記。
-
數據
+關注
關注
8文章
6890瀏覽量
88826 -
內存
+關注
關注
8文章
2999瀏覽量
73882 -
JAVA
+關注
關注
19文章
2958瀏覽量
104544 -
JVM
+關注
關注
0文章
157瀏覽量
12207 -
JDK
+關注
關注
0文章
81瀏覽量
16576
發布評論請先 登錄
相關推薦
評論