java垃圾回收之實現(xiàn)并行GC算法
Parallel GC(并行GC)
并行垃圾收集器這一類組合, 在年輕代使用 標(biāo)記-復(fù)制(mark-copy)算法, 在老年代使用 標(biāo)記-清除-整理(mark-sweep-compact)算法。年輕代和老年代的垃圾回收都會觸發(fā)STW事件,暫停所有的應(yīng)用線程來執(zhí)行垃圾收集。兩者在執(zhí)行 標(biāo)記和 復(fù)制/整理階段時都使用多個線程, 因此得名“(Parallel)”。通過并行執(zhí)行, 使得GC時間大幅減少。
通過命令行參數(shù) -XX:ParallelGCThreads=NNN
來指定 GC 線程數(shù)。 其默認(rèn)值為CPU內(nèi)核數(shù)。
可以通過下面的任意一組命令行參數(shù)來指定并行GC:
java -XX:+UseParallelGC com.mypackages.MyExecutableClass java -XX:+UseParallelOldGC com.mypackages.MyExecutableClass java -XX:+UseParallelGC -XX:+UseParallelOldGC com.mypackages.MyExecutableClass
并行垃圾收集器適用于多核服務(wù)器,主要目標(biāo)是增加吞吐量。因為對系統(tǒng)資源的有效使用,能達(dá)到更高的吞吐量:
- 在GC期間, 所有 CPU 內(nèi)核都在并行清理垃圾, 所以暫停時間更短
- 在兩次GC周期的間隔期, 沒有GC線程在運(yùn)行,不會消耗任何系統(tǒng)資源
另一方面, 因為此GC的所有階段都不能中斷, 所以并行GC很容易出現(xiàn)長時間的卡頓. 如果延遲是系統(tǒng)的主要目標(biāo), 那么就應(yīng)該選擇其他垃圾收集器組合。
注: 長時間卡頓的意思是,此GC啟動之后,屬于一次性完成所有操作, 于是單次 pause 的時間會較長。
讓我們看看并行垃圾收集器的GC日志長什么樣, 從中我們可以得到哪些有用信息。下面的GC日志中顯示了一次 minor GC 暫停 和一次 major GC 暫停:
1 ****-05-26T14:27:40.915-0200: 116.115: [GC (Allocation Failure) 2 [PSYoungGen: 2694440K->1305132K(2796544K)] 3 9556775K->8438926K(11185152K) 4 , 0.2406675 secs] 5 [Times: user=1.77 sys=0.01, real=0.24 secs] 6 ****-05-26T14:27:41.155-0200: 116.356: [Full GC (Ergonomics) 7 [PSYoungGen: 1305132K->0K(2796544K)] 8 [ParOldGen: 7133794K->6597672K(8388608K)] 8438926K->6597672K(11185152K), 9 [Metaspace: 6745K->6745K(1056768K)] 10 , 0.9158801 secs] 11 [Times: user=4.49 sys=0.64, real=0.92 secs]
Minor GC(小型GC)
第一次GC事件表示發(fā)生在年輕代的垃圾收集:
****-05-26T14:27:40.915-0200
1: 116.115
2: [ GC
3 (Allocation Failure
4)
[PSYoungGen
5: 2694440K->1305132K
6 (2796544K)
7] 9556775K->8438926K
8(11185152K)
9, 0.2406675 secs
10][Times: user=1.77 sys=0.01, real=0.24 secs]
11
****-05-26T14:27:40.915-0200
– GC事件開始的時間. 其中-0200
表示西二時區(qū),而中國所在的東8區(qū)為 +0800
。
116.115
– GC事件開始時,相對于JVM啟動時的間隔時間,單位是秒。
GC
– 用來區(qū)分 Minor GC 還是 Full GC 的標(biāo)志。GC
表明這是一次小型GC(Minor GC)
Allocation Failure
– 觸發(fā)垃圾收集的原因。本次GC事件, 是由于年輕代中沒有適當(dāng)?shù)目臻g存放新的數(shù)據(jù)結(jié)構(gòu)引起的。
PSYoungGen
– 垃圾收集器的名稱。這個名字表示的是在年輕代中使用的: 并行的 標(biāo)記-復(fù)制(mark-copy), 全線暫停(STW) 垃圾收集器。
2694440K->1305132K
– 在垃圾收集之前和之后的年輕代使用量。
(2796544K)
– 年輕代的總大小。
9556775K->8438926K
– 在垃圾收集之前和之后整個堆內(nèi)存的使用量。
(11185152K)
– 可用堆的總大小。
0.2406675 secs
– GC事件持續(xù)的時間,以秒為單位。
[Times: user=1.77 sys=0.01, real=0.24 secs]
– GC事件的持續(xù)時間, 通過三個部分來衡量:
- user – 在此次垃圾回收過程中, 由GC線程所消耗的總的CPU時間。
- sys – GC過程中中操作系統(tǒng)調(diào)用和系統(tǒng)等待事件所消耗的時間。
- real – 應(yīng)用程序暫停的時間。在 Parallel GC 中, 這個數(shù)字約等于: (user time + system time)/GC線程數(shù)。 這里使用了8個線程。 請注意,總有一定比例的處理過程是不能并行進(jìn)行的。
所以,可以簡單地算出, 在垃圾收集之前, 堆內(nèi)存總使用量為 9,556,775K。 其中年輕代為 2,694,440K。同時算出老年代使用量為 6,862,335K. 在垃圾收集之后, 年輕代使用量減少為 1,389,308K, 但總的堆內(nèi)存使用量只減少了 1,117,849K
。這表示有大小為 271,459K 的對象從年輕代提升到老年代。
Full GC(完全GC)
學(xué)習(xí)了并行GC如何清理年輕代之后, 下面介紹清理整個堆內(nèi)存的GC日志以及如何進(jìn)行分析:
****-05-26T14:27:41.155-0200 : 116.356 : [Full GC (Ergonomics) [PSYoungGen: 1305132K->0K(2796544K)] [ParOldGen :7133794K->6597672K (8388608K)] 8438926K->6597672K (11185152K), [Metaspace: 6745K->6745K(1056768K)], 0.9158801 secs, [Times: user=4.49 sys=0.64, real=0.92 secs]
****-05-26T14:27:41.155-0200
– GC事件開始的時間. 其中-0200
表示西二時區(qū),而中國所在的東8區(qū)為 +0800
。
116.356
– GC事件開始時,相對于JVM啟動時的間隔時間,單位是秒。 我們可以看到, 此次事件在前一次 MinorGC完成之后立刻就開始了。
Full GC
– 用來表示此次是 Full GC 的標(biāo)志。Full GC
表明本次清理的是年輕代和老年代。
Ergonomics
– 觸發(fā)垃圾收集的原因。Ergonomics
表示JVM內(nèi)部環(huán)境認(rèn)為此時可以進(jìn)行一次垃圾收集。
[PSYoungGen: 1305132K->0K(2796544K)]
– 和上面的示例一樣, 清理年輕代的垃圾收集器是名為 “PSYoungGen” 的STW收集器, 采用標(biāo)記-復(fù)制(mark-copy)算法。 年輕代使用量從 1305132K 變?yōu)?nbsp;0
, 一般 Full GC 的結(jié)果都是這樣。
ParOldGen
– 用于清理老年代空間的垃圾收集器類型。在這里使用的是名為 ParOldGen 的垃圾收集器, 這是一款并行 STW垃圾收集器, 算法為 標(biāo)記-清除-整理(mark-sweep-compact)。
7133794K->6597672K
– 在垃圾收集之前和之后老年代內(nèi)存的使用情況。
(8388608K)
– 老年代的總空間大小。
8438926K->6597672K
– 在垃圾收集之前和之后堆內(nèi)存的使用情況。
(11185152K)
– 可用堆內(nèi)存的總?cè)萘俊?/p>
[Metaspace: 6745K->6745K(1056768K)]
– 類似的信息,關(guān)于 Metaspace 空間的??梢钥闯? 在GC事件中 Metaspace 里面沒有回收任何對象。
0.9158801 secs
– GC事件持續(xù)的時間,以秒為單位。
[Times: user=4.49 sys=0.64, real=0.92 secs]
– GC事件的持續(xù)時間, 通過三個部分來衡量:
- user – 在此次垃圾回收過程中, 由GC線程所消耗的總的CPU時間。
- sys – GC過程中中操作系統(tǒng)調(diào)用和系統(tǒng)等待事件所消耗的時間。
- real – 應(yīng)用程序暫停的時間。在 Parallel GC 中, 這個數(shù)字約等于: (user time + system time)/GC線程數(shù)。 這里使用了8個線程。 請注意,總有一定比例的處理過程是不能并行進(jìn)行的。
同樣,和 Minor GC 的區(qū)別是很明顯的 —— 在此次GC事件中, 除了年輕代, 還清理了老年代和 Metaspace. 在GC事件前后的內(nèi)存布局如下圖所示:
以上就是java垃圾回收之實現(xiàn)并行GC算法的詳細(xì)內(nèi)容,更多關(guān)于java垃圾回收并行GC算法的資料請關(guān)注腳本之家其它相關(guān)文章!
原文鏈接:https://plumbr.io/handbook/garbage-collection-algorithms-implementations#parallel-gc
相關(guān)文章
JVM堆內(nèi)存溢出后,其他線程是否可繼續(xù)工作的問題解析
這篇文章主要介紹了JVM 堆內(nèi)存溢出后,其他線程是否可繼續(xù)工作?,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友可以參考下2019-08-08Java實現(xiàn)Fibonacci(斐波那契)取余的示例代碼
這篇文章主要介紹了Java實現(xiàn)Fibonacci取余的示例代碼,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2020-03-03SpringBoot 如何整合 ES 實現(xiàn) CRUD 操作
這篇文章主要介紹了SpringBoot 如何整合 ES 實現(xiàn) CRUD 操作,幫助大家更好的理解和使用springboot框架,感興趣的朋友可以了解下2020-10-10Java中策略設(shè)計模式的實現(xiàn)及應(yīng)用場景
策略設(shè)計模式是Java中一種常用的設(shè)計模式,它通過定義一系列算法并將其封裝成獨(dú)立的策略類,從而使得算法可以在不影響客戶端的情況下隨時切換。策略設(shè)計模式主要應(yīng)用于系統(tǒng)中存在多種相似的算法、需要靈活調(diào)整算法邏輯或者需要擴(kuò)展新的算法等場景2023-04-04