如何理解JVM全部垃圾回收器,針對(duì)這個(gè)問(wèn)題,這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答,希望可以幫助更多想解決這個(gè)問(wèn)題的小伙伴找到更簡(jiǎn)單易行的方法。
創(chuàng)新互聯(lián)建站2013年開(kāi)創(chuàng)至今,是專(zhuān)業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司,擁有項(xiàng)目成都網(wǎng)站制作、網(wǎng)站設(shè)計(jì)網(wǎng)站策劃,項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢(mèng)想脫穎而出為使命,1280元樂(lè)陵做網(wǎng)站,已為上家服務(wù),為樂(lè)陵各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:028-86922220
常用的7種收集器,其適用的范圍如圖所示
Serial、ParNew、Parallel Scavenge用于新生代;
CMS、Serial Old、Paralled Old用于老年代。 并且他們相互之間以相對(duì)固定的組合使用(具體組合關(guān)系如上圖)。G1是一個(gè)獨(dú)立的收集器不依賴其他6種收集器。ZGC是目前JDK 11的實(shí)驗(yàn)收集器。
下面來(lái)看看各個(gè)收集器的特性
Serial,是單線程執(zhí)行垃圾回收的。當(dāng)需要執(zhí)行垃圾回收時(shí),程序會(huì)暫停一切手上的工作,然后單線程執(zhí)行垃圾回收。
因?yàn)樾律奶攸c(diǎn)是對(duì)象存活率低,所以收集算法用的是復(fù)制算法,把新生代存活對(duì)象復(fù)制到老年代,復(fù)制的內(nèi)容不多,性能較好。
單線程地好處就是減少上下文切換,減少系統(tǒng)資源的開(kāi)銷(xiāo)。但這種方式的缺點(diǎn)也很明顯,在GC的過(guò)程中,會(huì)暫停程序的執(zhí)行。若GC不是頻繁發(fā)生,這或許是一個(gè)不錯(cuò)的選擇,否則將會(huì)影響程序的執(zhí)行性能。 對(duì)于新生代來(lái)說(shuō),區(qū)域比較小,停頓時(shí)間短,所以比較使用。
ParNew同樣用于新生代,是Serial的多線程版本,并且在參數(shù)、算法(同樣是復(fù)制算法)上也完全和Serial相同。
Par是Parallel的縮寫(xiě),但它的并行僅僅指的是收集多線程并行,并不是收集和原程序可以并行進(jìn)行。ParNew也是需要暫停程序一切的工作,然后多線程執(zhí)行垃圾回收。
因?yàn)槭嵌嗑€程執(zhí)行,所以在多CPU下,ParNew效果通常會(huì)比Serial好。但如果是單CPU則會(huì)因?yàn)榫€程的切換,性能反而更差。
新生代的收集器,同樣用的是復(fù)制算法,也是并行多線程收集。與ParNew最大的不同,它關(guān)注的是垃圾回收的吞吐量。
這里的吞吐量指的是 總時(shí)間與垃圾回收時(shí)間的比例。這個(gè)比例越高,證明垃圾回收占整個(gè)程序運(yùn)行的比例越小。
Parallel Scavenge收集器提供兩個(gè)參數(shù)控制垃圾回收的執(zhí)行:
-XX:MaxGCPauseMillis,最大垃圾回收停頓時(shí)間。這個(gè)參數(shù)的原理是空間換時(shí)間,收集器會(huì)控制新生代的區(qū)域大小,從而盡可能保證回收少于這個(gè)最大停頓時(shí)間。簡(jiǎn)單的說(shuō)就是回收的區(qū)域越小,那么耗費(fèi)的時(shí)間也越小。
所以這個(gè)參數(shù)并不是設(shè)置得越小越好。設(shè)太小的話,新生代空間會(huì)太小,從而更頻繁的觸發(fā)GC。
-XX:GCTimeRatio,垃圾回收時(shí)間與總時(shí)間占比。這個(gè)是吞吐量的倒數(shù),原理和MaxGCPauseMillis相同。
因?yàn)镻arallel Scavenge收集器關(guān)注的是吞吐量,所以當(dāng)設(shè)置好以上參數(shù)的時(shí)候,同時(shí)不想設(shè)置各個(gè)區(qū)域大小(新生代,老年代等)??梢蚤_(kāi)啟**-XX:UseAdaptiveSizePolicy**參數(shù),讓JVM監(jiān)控收集的性能,動(dòng)態(tài)調(diào)整這些區(qū)域大小參數(shù)。
老年代的收集器,與Serial一樣是單線程,不同的是算法用的是標(biāo)記-整理(Mark-Compact)。
因?yàn)槔夏甏锩鎸?duì)象的存活率高,如果依舊是用復(fù)制算法,需要復(fù)制的內(nèi)容較多,性能較差。并且在極端情況下,當(dāng)存活為100%時(shí),沒(méi)有辦法用復(fù)制算法。所以需要用Mark-Compact,以有效地避免這些問(wèn)題。
老年代的收集器,是Parallel Scavenge老年代的版本。其中的算法替換成Mark-Compact。
CMS,Concurrent Mark Sweep,同樣是老年代的收集器。它關(guān)注的是垃圾回收最短的停頓時(shí)間(低停頓),在老年代并不頻繁GC的場(chǎng)景下,是比較適用的。
命名中用的是concurrent,而不是parallel,說(shuō)明這個(gè)收集器是有與工作執(zhí)行并發(fā)的能力的。MS則說(shuō)明算法用的是Mark Sweep算法。
來(lái)看看具體地工作原理。CMS整個(gè)過(guò)程比之前的收集器要復(fù)雜,整個(gè)過(guò)程分為四步:
初始標(biāo)記(initial mark),單線程執(zhí)行,需要“Stop The World”,但僅僅把GC Roots的直接關(guān)聯(lián)可達(dá)的對(duì)象給標(biāo)記一下,由于直接關(guān)聯(lián)對(duì)象比較小,所以這里的速度非???。
并發(fā)標(biāo)記(concurrent mark),對(duì)于初始標(biāo)記過(guò)程所標(biāo)記的初始標(biāo)記對(duì)象,進(jìn)行并發(fā)追蹤標(biāo)記,此時(shí)其他線程仍可以繼續(xù)工作。此處時(shí)間較長(zhǎng),但不停頓。
重新標(biāo)記(remark),在并發(fā)標(biāo)記的過(guò)程中,由于可能還會(huì)產(chǎn)生新的垃圾,所以此時(shí)需要重新標(biāo)記新產(chǎn)生的垃圾。此處執(zhí)行并行標(biāo)記,與用戶線程不并發(fā),所以依然是“Stop The World”,時(shí)間比初始時(shí)間要長(zhǎng)一點(diǎn)。
并發(fā)清除(concurrent sweep),并發(fā)清除之前所標(biāo)記的垃圾。其他用戶線程仍可以工作,不需要停頓。
由于最耗費(fèi)時(shí)間的并發(fā)標(biāo)記與并發(fā)清除階段都不需要暫停工作,所以整體的回收是低停頓的。
由于CMS以上特性,缺點(diǎn)也是比較明顯的,
Mark Sweep算法會(huì)導(dǎo)致內(nèi)存碎片比較多
CMS的并發(fā)能力依賴于CPU資源,所以在CPU數(shù)少和CPU資源緊張的情況下,性能較差
并發(fā)清除階段,用戶線程依然在運(yùn)行,所以依然會(huì)產(chǎn)生新的垃圾,此階段的垃圾并不會(huì)再本次GC中回收,而放到下次。所以GC不能等待內(nèi)存耗盡的時(shí)候才進(jìn)行GC,這樣的話會(huì)導(dǎo)致并發(fā)清除的時(shí)候,用戶線程可以了利用的空間不足。所以這里會(huì)浪費(fèi)一些內(nèi)存空間給用戶線程預(yù)留。
有人會(huì)覺(jué)得既然Mark Sweep會(huì)造成內(nèi)存碎片,那么為什么不把算法換成Mark Compact呢?
答案其實(shí)很簡(jiǎn)答,因?yàn)楫?dāng)并發(fā)清除的時(shí)候,用Compact整理內(nèi)存的話,原來(lái)的用戶線程使用的內(nèi)存還怎么用呢?要保證用戶線程能繼續(xù)執(zhí)行,前提的它運(yùn)行的資源不受影響嘛。Mark Compact更適合“Stop the World”這種場(chǎng)景下使用。
G1,Garbage First,在JDK 1.7版本正式啟用,是當(dāng)時(shí)最前沿的垃圾收集器。G1可以說(shuō)是CMS的終極改進(jìn)版,解決了CMS內(nèi)存碎片、更多的內(nèi)存空間登問(wèn)題。雖然流程與CMS比較相似,但底層的原理已是完全不同。
高效益優(yōu)先。G1會(huì)預(yù)測(cè)垃圾回收的停頓時(shí)間,原理是計(jì)算老年代對(duì)象的效益率,優(yōu)先回收最大效益的對(duì)象。
堆內(nèi)存結(jié)構(gòu)的不同。以前的收集器分代是劃分新生代、老年代、持久代等。
G1則是把內(nèi)存分為多個(gè)大小相同的區(qū)域Region,每個(gè)Region擁有各自的分代屬性,但這些分代不需要連續(xù)。
這樣的分區(qū)可以有效避免內(nèi)存碎片化問(wèn)題。
但是這樣同樣會(huì)引申一個(gè)新的問(wèn)題,就是分代的內(nèi)存不連續(xù),導(dǎo)致在GC搜索垃圾對(duì)象的時(shí)候需要全盤(pán)掃描找出引用內(nèi)存所在。
為了解決這個(gè)問(wèn)題,G1對(duì)于每個(gè)Region都維護(hù)一個(gè)Remembered Set,用于記錄對(duì)象引用的情況。當(dāng)GC發(fā)生的時(shí)候根據(jù)Remembered Set的引用情況去搜索。
兩種GC模式:
Young GC,關(guān)注于所有年輕代的Region,通過(guò)控制收集年輕代的Region個(gè)數(shù),從而控制GC的回收時(shí)間。
Mixed GC,關(guān)注于所有年輕代的Region,并且加上通過(guò)預(yù)測(cè)計(jì)算最大收益的若干個(gè)老年代Region。
整體的執(zhí)行流程:
初始標(biāo)記(initial mark),標(biāo)記了從GC Root開(kāi)始直接關(guān)聯(lián)可達(dá)的對(duì)象。STW(Stop the World)執(zhí)行。
并發(fā)標(biāo)記(concurrent marking),并發(fā)標(biāo)記初始標(biāo)記的對(duì)象,此時(shí)用戶線程依然可以執(zhí)行。
最終標(biāo)記(Remark),STW,標(biāo)記再并發(fā)標(biāo)記過(guò)程中產(chǎn)生的垃圾。
篩選回收(Live Data Counting And Evacuation),評(píng)估標(biāo)記垃圾,根據(jù)GC模式回收垃圾。STW執(zhí)行。
在Region層面上,整體的算法偏向于Mark-Compact。因?yàn)槭荂ompact,會(huì)影響用戶線程執(zhí)行,所以回收階段需要STW執(zhí)行。
在JDK 11當(dāng)中,加入了實(shí)驗(yàn)性質(zhì)的ZGC。它的回收耗時(shí)平均不到2毫秒。它是一款低停頓高并發(fā)的收集器。
ZGC幾乎在所有地方并發(fā)執(zhí)行的,除了初始標(biāo)記的是STW的。所以停頓時(shí)間幾乎就耗費(fèi)在初始標(biāo)記上,這部分的實(shí)際是非常少的。那么其他階段是怎么做到可以并發(fā)執(zhí)行的呢?
ZGC主要新增了兩項(xiàng)技術(shù),一個(gè)是著色指針Colored Pointer,另一個(gè)是讀屏障Load Barrier。
著色指針Colored Pointer
ZGC利用指針的64位中的幾位表示Finalizable、Remapped、Marked1、Marked0(ZGC僅支持64位平臺(tái)),以標(biāo)記該指向內(nèi)存的存儲(chǔ)狀態(tài)。相當(dāng)于在對(duì)象的指針上標(biāo)注了對(duì)象的信息。注意,這里的指針相當(dāng)于Java術(shù)語(yǔ)當(dāng)中的引用。
在這個(gè)被指向的內(nèi)存發(fā)生變化的時(shí)候(內(nèi)存在Compact被移動(dòng)時(shí)),顏色就會(huì)發(fā)生變化。
在G1的時(shí)候就說(shuō)到過(guò),Compact階段是需要STW,否則會(huì)影響用戶線程執(zhí)行。那么怎么解決這個(gè)問(wèn)題呢?
讀屏障Load Barrier由于著色指針的存在,在程序運(yùn)行時(shí)訪問(wèn)對(duì)象的時(shí)候,可以輕易知道對(duì)象在內(nèi)存的存儲(chǔ)狀態(tài)(通過(guò)指針訪問(wèn)對(duì)象),若請(qǐng)求讀的內(nèi)存在被著色了。那么則會(huì)觸發(fā)讀屏障。讀屏障會(huì)更新指針再返回結(jié)果,此過(guò)程有一定的耗費(fèi),從而達(dá)到與用戶線程并發(fā)的效果。
把這兩項(xiàng)技術(shù)聯(lián)合下理解,引用R大(RednaxelaFX)的話
與標(biāo)記對(duì)象的傳統(tǒng)算法相比,ZGC在指針上做標(biāo)記,在訪問(wèn)指針時(shí)加入Load Barrier(讀屏障),比如當(dāng)對(duì)象正被GC移動(dòng),指針上的顏色就會(huì)不對(duì),這個(gè)屏障就會(huì)先把指針更新為有效地址再返回,也就是,永遠(yuǎn)只有單個(gè)對(duì)象讀取時(shí)有概率被減速,而不存在為了保持應(yīng)用與GC一致而粗暴整體的Stop The World。
ZGC雖然目前還在JDK 11還在實(shí)驗(yàn)階段,但由于算法與思想是一個(gè)非常大的提升,相信在未來(lái)不久會(huì)成為主流的GC收集器使用。
關(guān)于如何理解JVM全部垃圾回收器問(wèn)題的解答就分享到這里了,希望以上內(nèi)容可以對(duì)大家有一定的幫助,如果你還有很多疑惑沒(méi)有解開(kāi),可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識(shí)。
網(wǎng)站名稱:如何理解JVM全部垃圾回收器
標(biāo)題URL:http://sd-ha.com/article18/jisddp.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供微信公眾號(hào)、響應(yīng)式網(wǎng)站、關(guān)鍵詞優(yōu)化、企業(yè)建站、網(wǎng)站改版、虛擬主機(jī)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源: 創(chuàng)新互聯(lián)
營(yíng)銷(xiāo)型網(wǎng)站建設(shè)知識(shí)