這篇文章主要講解了“ZGC的特性有哪些”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“ZGC的特性有哪些”吧！

成都創(chuàng)新互聯(lián)公司10余年專注成都高端網(wǎng)站建設(shè)按需網(wǎng)站制作服務(wù),為客戶提供專業(yè)的成都網(wǎng)站制作,成都網(wǎng)頁設(shè)計(jì),成都網(wǎng)站設(shè)計(jì)服務(wù);成都創(chuàng)新互聯(lián)公司服務(wù)內(nèi)容包含成都網(wǎng)站建設(shè),重慶小程序開發(fā)公司,軟件開發(fā),網(wǎng)絡(luò)營(yíng)銷推廣,網(wǎng)絡(luò)運(yùn)營(yíng)服務(wù)及企業(yè)形象設(shè)計(jì);成都創(chuàng)新互聯(lián)公司擁有眾多專業(yè)的高端網(wǎng)站制作開發(fā)團(tuán)隊(duì),資深的高端網(wǎng)頁設(shè)計(jì)團(tuán)隊(duì)及經(jīng)驗(yàn)豐富的架構(gòu)師高端網(wǎng)站策劃團(tuán)隊(duì);我們始終堅(jiān)持從客戶的角度出發(fā),為客戶量身訂造網(wǎng)絡(luò)營(yíng)銷方案，解決網(wǎng)絡(luò)營(yíng)銷疑問。

ZGC 的目標(biāo)

垃圾收集器設(shè)計(jì)出來都有目標(biāo)的，有些是為了更高的吞吐，有些是為了更低的延遲。

所以我們先看看 ZGC 的目標(biāo)：

可以看到它的目標(biāo)就是低延遲，保證最大停頓時(shí)間在幾毫秒之內(nèi)，不管你堆多大或者存活的對(duì)象有多少。

可以處理 8MB-16TB 的堆。

咱們就按 openjdk 的 wiki 來展開今天的內(nèi)容。

關(guān)鍵字：并發(fā)、基于Region、整理內(nèi)存、支持NUMA、用了染色指針、用了讀屏障，對(duì)了 ZGC 用的是 STAB。

Concurrent

這個(gè) Concurrent 的意思是和應(yīng)用線程并發(fā)執(zhí)行，ZGC 一共分了 10 個(gè)階段，只有 3 個(gè)很短暫的階段是 STW 的。

可以看到只有初始標(biāo)記、再標(biāo)記、初始轉(zhuǎn)移階段是 STW 的。

初始標(biāo)記就掃描 GC Roots 直接可達(dá)的，耗時(shí)很短，重新標(biāo)記一般而言也很短，如果超過 1ms 會(huì)再次進(jìn)入并發(fā)標(biāo)記階段再來一遍，所以影響不大。

初始轉(zhuǎn)移階段也是掃描 GC Roots 也很短，所以可以認(rèn)為 ZGC 幾乎是并發(fā)的。

而且之所以說停頓時(shí)間不會(huì)隨著堆的大小和存活對(duì)象的數(shù)量增加而增加，是因?yàn)?STW 幾乎只和 GC Roots 集合大小有關(guān)，和堆大小沒啥關(guān)系。

這其實(shí)就是 ZGC 超過 G1 很關(guān)鍵的一個(gè)地方， G1 的對(duì)象轉(zhuǎn)移需要 STW 所以堆大需要轉(zhuǎn)移對(duì)象多，停頓的時(shí)間就長(zhǎng)了，而 ZGC 有并發(fā)轉(zhuǎn)移。

不過并發(fā)回收有個(gè)情況就是回收的時(shí)候應(yīng)用線程還是在產(chǎn)生新的對(duì)象，所以需要預(yù)留一些空間給并發(fā)時(shí)候生成的新對(duì)象。

如果對(duì)象分配過快導(dǎo)致內(nèi)存不夠，在 CMS 中是發(fā)生 Full gc，而 ZGC 則是阻塞應(yīng)用線程。

所以要注意 ZGC 觸發(fā)的時(shí)間。

ZGC 有自適應(yīng)算法來觸發(fā)也有固定時(shí)間觸發(fā)，所以可以根據(jù)實(shí)際場(chǎng)景來修改 ZGC 觸發(fā)時(shí)間，防止過晚觸發(fā)而內(nèi)存分配過快導(dǎo)致線程阻塞。

還有設(shè)置 ParallelGCThreads 和 ConcGCThreads，分別是 STW 并行時(shí)候的線程數(shù)和并發(fā)階段的線程數(shù)來加快回收的速度。

不過 ConcGCThreads 數(shù)量需要注意，因?yàn)榇穗A段是和應(yīng)用線程并發(fā)，如果線程數(shù)過多會(huì)影響應(yīng)用線程。

其實(shí) ZGC 的每個(gè)階段都是串行的，所以理論上其實(shí)可以不需要分兩類線程，那為什么分了這兩類線程？

就是為了靈活設(shè)置。分成兩類就可以通過配置來調(diào)優(yōu)，達(dá)到性能最大值。

對(duì)了上面提到 ZGC 的 STW 和 GC Roots 集合大小有關(guān)系，所以如果在會(huì)生成很多線程、動(dòng)態(tài)加載很多 ClassLoader 等情況下會(huì)增加 ZGC 的停頓時(shí)間。

這點(diǎn)需要注意。

Region-based

為了能更細(xì)粒度的控制內(nèi)存的分配，和 G1 一樣 ZGC 也將堆劃分成很多分區(qū)。

分了三種：2MB、32MB 和 X*MB（受操作系統(tǒng)控制）。

下圖為源碼中的注釋：

對(duì)于回收的策略是優(yōu)先收集小區(qū)，中、大區(qū)盡量不回收。

Compacting

和 G1 一樣都分區(qū)了所以肯定從整體來看像是標(biāo)記-復(fù)制算法，所以也是會(huì)整理的。

因此 ZGC 也不會(huì)產(chǎn)生內(nèi)存碎片。

具體的流程下文再做分析。

NUMA-aware

以前的 G1 是不支持的，不過在 JDK14 G1 也支持了。

可能有的同學(xué)對(duì) NUMA 不太熟悉，沒事我先來解釋一波。

在早期處理器都是單核的，因?yàn)楦鶕?jù)摩爾定律，處理器的性能每隔一段時(shí)間就可以成指數(shù)型增長(zhǎng)。

而近年來這個(gè)增長(zhǎng)的速度逐漸變緩，于是很多廠商就推出了雙核多核的計(jì)算機(jī)。

早期 CPU 通過前端總線到北橋到內(nèi)存總線然后才訪問到內(nèi)存。

這個(gè)架構(gòu)被稱為 SMP （Symmetric Multi-Processor），因?yàn)槿我粋€(gè) CPU 對(duì)內(nèi)存的訪問速度是一致的，不用考慮不同內(nèi)存地址之間的差異，所以也稱一致內(nèi)存訪問（Uniform Memory Access， UMA ）。

這個(gè)核心越加越多，漸漸的總線和北橋就成為瓶頸，那不能夠啊，于是就想了個(gè)辦法。

把 CPU 和內(nèi)存集成到一個(gè)單元上，這個(gè)就是非一致內(nèi)存訪問 （Non-Uniform Memory Access，NUMA）。

簡(jiǎn)單的說就是把內(nèi)存分一分，每個(gè) CPU 訪問自己的本地的內(nèi)存比較快，訪問別人的遠(yuǎn)程內(nèi)存就比較慢。

當(dāng)然也可以多個(gè) CPU 享受一塊內(nèi)存或者多塊，如下圖所示：

但是因?yàn)閮?nèi)存被切分為本地內(nèi)存和遠(yuǎn)程內(nèi)存，當(dāng)某個(gè)模塊比較“熱”的時(shí)候，就可能產(chǎn)生本地內(nèi)存爆滿，而遠(yuǎn)程內(nèi)存都很空閑的情況。

比如 64G 內(nèi)存一分為二，模塊一的內(nèi)存用了31G，而另一個(gè)模塊的內(nèi)存用了5G，且模塊一只能用本地內(nèi)存，這就產(chǎn)生了內(nèi)存不平衡問題。

如果有些策略規(guī)定不能訪問遠(yuǎn)程內(nèi)存的時(shí)候，就會(huì)出現(xiàn)明明還有很多內(nèi)存卻產(chǎn)生 SWAP(將部分內(nèi)存置換到硬盤中) 的情況。

即使允許訪問遠(yuǎn)程內(nèi)存那也比本地內(nèi)存訪問速率相差較大，這是使用 NUMA 需要考慮的問題。

ZGC 對(duì) NUMA 的支持是小分區(qū)分配時(shí)會(huì)優(yōu)先從本地內(nèi)存分配，如果本地內(nèi)存不足則從遠(yuǎn)程內(nèi)存分配。

對(duì)于中、大分區(qū)的話就交由操作系統(tǒng)決定。

上述做法的原因是生成的絕大部分都是小分區(qū)對(duì)象，因此優(yōu)先本地分配速度較快，而且也不易造成內(nèi)存不平衡的情況。

而中、大分區(qū)對(duì)象較大，如果都從本地分配則可能會(huì)導(dǎo)致內(nèi)存不平衡的情況。

Using colored pointers

染色指針其實(shí)就是從 64 位的指針中，拿幾位來標(biāo)識(shí)對(duì)象此時(shí)的情況，分別表示 Marked0、Marked1、Remapped、Finalizable。

我們?cè)賮砜聪略创a中的注釋，非常的清晰直觀：

0-41 這 42 位就是正常的地址，所以說 ZGC 最大支持 4TB (理論上可以16TB)的內(nèi)存，因?yàn)榫?42 位用來表示地址。

也因此 ZGC 不支持 32 位指針，也不支持指針壓縮。

然后用 42-45 位來作為標(biāo)志位，其實(shí)不管這個(gè)標(biāo)志位是啥指向的都是同一個(gè)對(duì)象。

這是通過多重映射來做的，很簡(jiǎn)單就是多個(gè)虛擬地址指向同一個(gè)物理地址，不過對(duì)象地址是 0001.... 還是0010....還是0100..... 對(duì)應(yīng)的都是同一個(gè)物理地址即可。

具體這幾個(gè)標(biāo)記位怎么用的，待下文回收流程分析再解釋。

不過這里先提個(gè)問題，為什么就支持 4TB，不是還有很多位沒用嗎？

首先 X86_64 的地址總線只有 48 條 ，所以最多其實(shí)只能用 48 位，指令集是 64 位沒錯(cuò)，但是硬件層面就支持 48 位。

因?yàn)榛旧蠜]有多少系統(tǒng)支持這么大的內(nèi)存，那支持 64 位就沒必要了，所以就支持到 48 位。

那現(xiàn)在對(duì)象地址就用了 42 位，染色指針用了 4 位，不是還有 2 位可以用嗎？

是的，理論上可以支持 16 TB，不過暫時(shí)認(rèn)為 4TB 夠了，所以暫做保留，僅此而已沒啥特別的含義。

Using load barriers

在 CMS 和 G1 中都用到了寫屏障，而 ZGC 用到了讀屏障。

寫屏障是在對(duì)象引用賦值時(shí)候的 AOP，而讀屏障是在讀取引用時(shí)的 AOP。

比如 Object a = obj.foo;，這個(gè)過程就會(huì)觸發(fā)讀屏障。

也正是用了讀屏障，ZGC 可以并發(fā)轉(zhuǎn)移對(duì)象，而 G1 用的是寫屏障，所以轉(zhuǎn)移對(duì)象時(shí)候只能 STW。

簡(jiǎn)單的說就是 GC 線程轉(zhuǎn)移對(duì)象之后，應(yīng)用線程讀取對(duì)象時(shí)，可以利用讀屏障通過指針上的標(biāo)志來判斷對(duì)象是否被轉(zhuǎn)移。

如果是的話修正對(duì)象的引用，按照上面的例子，不僅 a 能得到最新的引用地址，obj.foo 也會(huì)被更新，這樣下次訪問的時(shí)候一切都是正常的，就沒有消耗了。

下圖展示了讀屏障的效果，其實(shí)就是轉(zhuǎn)移的時(shí)候找地方記一下即 forwardingTable，然后讀的時(shí)候觸發(fā)引用的修正。

這種也稱之為“自愈”，不僅賦值的引用時(shí)最新的，自身引用也修正了。

染色指針和讀屏障是 ZGC 能實(shí)現(xiàn)并發(fā)轉(zhuǎn)移的關(guān)鍵所在。

ZGC 回收流程解析

ZGC 的步驟大致可分為三大階段分別是標(biāo)記、轉(zhuǎn)移、重定位。

• 標(biāo)記：從根開始標(biāo)記所有存活對(duì)象

• 轉(zhuǎn)移：選擇部分活躍對(duì)象轉(zhuǎn)移到新的內(nèi)存空間上

• 重定位：因?yàn)閷?duì)象地址變了，所以之前指向老對(duì)象的指針都要換到新對(duì)象地址上。

并且這三個(gè)階段都是并發(fā)的。

這是意識(shí)上的階段，具體的實(shí)現(xiàn)上重定位其實(shí)是糅合在標(biāo)記階段的。

在標(biāo)記的時(shí)候如果發(fā)現(xiàn)引用的還是老的地址則會(huì)修正成新的地址，然后再進(jìn)行標(biāo)記。

簡(jiǎn)單的說就是從第一個(gè) GC 開始經(jīng)歷了標(biāo)記，然后轉(zhuǎn)移了對(duì)象，這個(gè)時(shí)候不會(huì)重定位，只會(huì)記錄對(duì)象都轉(zhuǎn)移到哪里了。

在第二個(gè) GC 開始標(biāo)記的時(shí)候發(fā)現(xiàn)這個(gè)對(duì)象是被轉(zhuǎn)移了，然后發(fā)現(xiàn)引用還是老的，則進(jìn)行重定位，即修改成新的引用。

所以說重定位是糅合在下一步的標(biāo)記階段中。

我再簡(jiǎn)單說一下十個(gè)步驟。

不過步驟里有些不影響整體回收流程的，我就不多加分析了。

這篇文章的目的不是深入 ZGC 實(shí)現(xiàn)的細(xì)節(jié)，而是了解 ZGC 大致的突出點(diǎn)和簡(jiǎn)單流程即可。

因此想知道細(xì)節(jié)的自行查閱，或者可以看看我文末推薦的書籍。

初始標(biāo)記

這個(gè)階段其實(shí)大家應(yīng)該很熟悉，CMS、G1 都有這個(gè)階段，這個(gè)階段是 STW 的，僅標(biāo)記根直接可達(dá)的對(duì)象，壓到標(biāo)記棧中。

當(dāng)然還有其他動(dòng)作，比如重置 TLAB、判斷是否要清除軟引用等等，不做具體分析。

并發(fā)標(biāo)記

就是根據(jù)初始標(biāo)記的對(duì)象開始并發(fā)遍歷對(duì)象圖，還會(huì)統(tǒng)計(jì)每個(gè) region 的存活對(duì)象的數(shù)量。

這個(gè)并發(fā)標(biāo)記其實(shí)有個(gè)細(xì)節(jié)，標(biāo)記棧其實(shí)只有一個(gè)，但是并發(fā)標(biāo)記的線程有多個(gè)。

為了減少之間的競(jìng)爭(zhēng)每個(gè)線程其實(shí)會(huì)分到不同的標(biāo)記帶來執(zhí)行。

你就理解為標(biāo)記棧被分割為好幾塊，每個(gè)線程負(fù)責(zé)其中的一塊進(jìn)行遍歷標(biāo)記對(duì)象，就和1.7 Hashmap 的segment 一樣。

那肯定有的線程標(biāo)記的快，有的標(biāo)記的慢，那么先空閑下來的線程會(huì)去竊取別人的任務(wù)來執(zhí)行，從而實(shí)現(xiàn)負(fù)載均衡。

看到這有沒有想到啥？沒錯(cuò)就是 ForkJoinPool 的工作竊取機(jī)制！

再標(biāo)記階段

這一階段是 STW 的，因?yàn)椴l(fā)階段應(yīng)用線程還是在運(yùn)行的，所以會(huì)修改對(duì)象的引用導(dǎo)致漏標(biāo)的情況。

因此需要個(gè)再標(biāo)記階段來標(biāo)記漏標(biāo)的那些對(duì)象。

如果這個(gè)階段執(zhí)行的時(shí)間過長(zhǎng)，就會(huì)再次進(jìn)入到并發(fā)標(biāo)記階段，因?yàn)?ZGC 的目標(biāo)就是低延遲，所以一有高延遲的苗頭就得扼制。

這個(gè)階段還會(huì)做非強(qiáng)根并行標(biāo)記，非強(qiáng)根指的是：系統(tǒng)字典、JVMTI、JFR、字符串表。

有些非強(qiáng)根可以并發(fā)，有些不行，具體不做分析。

非強(qiáng)引用并發(fā)標(biāo)記和引用并發(fā)處理

就是上一步非強(qiáng)根的遍歷，然后引用就軟引用、弱引用、虛引用的一些處理。

這個(gè)階段是并發(fā)的。

重置轉(zhuǎn)移集

還記得標(biāo)記時(shí)候的重定位么？在寫讀屏障時(shí)候提到的 forwardingTable 就是個(gè)映射集，你可以理解為 key 就是對(duì)象轉(zhuǎn)移前的地址，value 是對(duì)象轉(zhuǎn)移后的地址。

不過這個(gè)映射集在標(biāo)記階段已經(jīng)用了，也就是說標(biāo)記的時(shí)候已經(jīng)重定位完了，所以現(xiàn)在沒用了。

但新一輪的垃圾回收需要還是要用到這個(gè)映射集的。

因此在這個(gè)階段對(duì)那些轉(zhuǎn)移分區(qū)的地址映射集做一個(gè)復(fù)位的操作。

回收無效分區(qū)

回收那些物理內(nèi)存已經(jīng)被釋放的無效的虛擬內(nèi)存頁面。

就是在內(nèi)存緊張的時(shí)候會(huì)釋放物理內(nèi)存，如果同時(shí)釋放虛擬空間的話也不能釋放分區(qū)，因?yàn)?strong>分區(qū)需要在新一輪標(biāo)記完成之后才能釋放。

所以就會(huì)有無效的虛擬內(nèi)存頁面存在，在這個(gè)階段回收。

選擇待回收的分區(qū)

這和 G1 一樣，因?yàn)闀?huì)有很多可以回收的分區(qū)，會(huì)篩選垃圾較多的分區(qū)，來作為這次回收的分區(qū)集合。

初始化待轉(zhuǎn)移集合的轉(zhuǎn)移表

這一步就是初始化待回收的分區(qū)的 forwardingTable。

初始轉(zhuǎn)移

這個(gè)階段其實(shí)就是從根集合出發(fā)，如果對(duì)象在轉(zhuǎn)移的分區(qū)集合中，則在新的分區(qū)分配對(duì)象空間。

如果不在轉(zhuǎn)移分區(qū)集合中，則將對(duì)象標(biāo)記為 Remapped。

注意這個(gè)階段是 STW，只轉(zhuǎn)移根直接可達(dá)的對(duì)象。

并發(fā)轉(zhuǎn)移

這個(gè)階段和并發(fā)標(biāo)記階段就很類似了，從上一步轉(zhuǎn)移的對(duì)象開始遍歷，做并發(fā)轉(zhuǎn)移。

這一步很關(guān)鍵。

G1 的轉(zhuǎn)移對(duì)象整體都需要 STW，而 ZGC 做到了并發(fā)轉(zhuǎn)移，所以延遲會(huì)低很多。

至此十個(gè)步驟就完畢了，一次 GC 結(jié)束。

可以還能同學(xué)對(duì)染色指針的幾個(gè)標(biāo)記位有點(diǎn)懵，沒事看了下文就懂了。

染色指針的標(biāo)記位

來分析下幾個(gè)標(biāo)記位，M0、M1、Remapped。

先來介紹個(gè)名詞，地址視圖：指的就是此時(shí)地址指針的標(biāo)記位。

比如標(biāo)記位現(xiàn)在是 M0，那么此時(shí)的視圖就是 M0 視圖。

在垃圾回收開始前視圖是 Remapped 。

在進(jìn)入標(biāo)記標(biāo)記時(shí)。

標(biāo)記線程訪問發(fā)現(xiàn)對(duì)象地址視圖是 Remapped 這時(shí)候?qū)⒅羔槝?biāo)記為 M0，即將地址視圖置為 M0，表示活躍對(duì)象。

如果掃描到對(duì)象地址視圖是 M0 則說明這個(gè)對(duì)象是標(biāo)記開始之后新分配的或者已經(jīng)標(biāo)記過的對(duì)象，所以無需處理。

應(yīng)用線程如果創(chuàng)建新對(duì)象，則將其地址視圖置為 M0，如果訪問的對(duì)象地址視圖是 Remapped 則將其置為 M0，并且遞歸標(biāo)記其引用的對(duì)象。

如果訪問到的是 M0 ，則無需操作。

標(biāo)記階段結(jié)束后，ZGC 會(huì)使用一個(gè)對(duì)象活躍表來存儲(chǔ)這些對(duì)象地址，此時(shí)活躍的對(duì)象地址視圖是 M0。

并發(fā)轉(zhuǎn)移階段，地址視圖被置為 Remapped 。

也就是說 GC 線程如果訪問到對(duì)象，此時(shí)對(duì)象地址視圖是 M0，并且存在或活躍表中，則將其轉(zhuǎn)移，并將地址視圖置為 Remapped 。

如果在活躍表中，但是地址視圖已經(jīng)是 Remapped 說明已經(jīng)被轉(zhuǎn)移了，不做處理。

應(yīng)用線程此時(shí)創(chuàng)建新對(duì)象，地址視圖會(huì)設(shè)為 Remapped 。

此時(shí)訪問對(duì)象如果對(duì)象在活躍表中，且地址視圖為 Remapped 說明轉(zhuǎn)移過了，不做處理。

如果地址視圖為 M0，則說明還未轉(zhuǎn)移，則需要轉(zhuǎn)移，并將其地址視圖置為 Remapped 。

如果訪問到的對(duì)象不在活躍表中，則不做處理。

那 M1 什么用？

M1 是在下一次 GC 時(shí)候用的，下一次的 GC 就用 M1來標(biāo)記，不用 M0。

再下一次再換過來。

簡(jiǎn)單的說就是 M1 標(biāo)識(shí)本次垃圾回收中活躍的對(duì)象，而 M0 是上一次回收被標(biāo)記的對(duì)象，但是沒有被轉(zhuǎn)移，在本次回收中也沒有被標(biāo)記活躍的對(duì)象。

其實(shí)從上面的分析以及得知，如果沒有被轉(zhuǎn)移就會(huì)停留在 M0 這個(gè)地址視圖。

而下一次 GC 如果還是用 M0 來標(biāo)識(shí)那混淆了這兩種對(duì)象。

所以搞了個(gè) M1。

至此染色指針這幾個(gè)標(biāo)志位應(yīng)該就很清晰了，我在用圖來示意一下。

不清晰的同學(xué)建議再多看幾遍標(biāo)記位的變更，不復(fù)雜的。

感謝各位的閱讀，以上就是“ZGC的特性有哪些”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)ZGC的特性有哪些這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！

分享標(biāo)題：ZGC的特性有哪些
鏈接地址：http://chinadenli.net/article32/gogcpc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站制作、微信小程序、用戶體驗(yàn)、網(wǎng)站策劃、手機(jī)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(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í)需注明來源： 創(chuàng)新互聯(lián)