柚子快報(bào)激活碼778899分享：java 5、JVM-G1詳解

http://yzkb.51969.com/

G1收集器

-XX:+UseG1GC

????????G1 (Garbage-First)是一款面向服務(wù)器的垃圾收集器,主要針對配備多顆處理器及大容量內(nèi)存的機(jī)器. 以極高概率滿足GC停頓時(shí)間要求的同時(shí),還具備高吞吐量性能特征.

????????G1將Java堆劃分為多個(gè)大小相等的獨(dú)立區(qū)域（Region），JVM目標(biāo)是不超過2048個(gè)Region(JVM源碼里TARGET_REGION_NUMBER 定義)，實(shí)際可以超過該值，但是不推薦。

一般Region大小等于堆大小除以2048，比如堆大小為4096M，則Region大小為2M，當(dāng)然也可以用參數(shù)"-XX:G1HeapRegionSize"手動指定Region大小，但是推薦默認(rèn)的計(jì)算方式。

G1保留了年輕代和老年代的概念，但不再是物理隔閡了，它們都是（可以不連續(xù)）Region的集合。

????????默認(rèn)年輕代對堆內(nèi)存的占比是5%，如果堆大小為4096M，那么年輕代占據(jù)200MB左右的內(nèi)存，對應(yīng)大概是100個(gè)Region，可以通過“-XX:G1NewSizePercent”設(shè)置新生代初始占比，在系統(tǒng)運(yùn)行中，JVM會不停的給年輕代增加更多的Region，但是最多新生代的占比不會超過60%，可以通過“-XX:G1MaxNewSizePercent”調(diào)整。年輕代中的Eden和Survivor對應(yīng)的region也跟之前一樣，默認(rèn)8:1:1，假設(shè)年輕代現(xiàn)在有1000個(gè)region，eden區(qū)對應(yīng)800個(gè)，s0對應(yīng)100個(gè)，s1對應(yīng)100個(gè)。

????????一個(gè)Region可能之前是年輕代，如果Region進(jìn)行了垃圾回收，之后可能又會變成老年代，也就是說Region的區(qū)域功能可能會動態(tài)變化。

????????G1垃圾收集器對于對象什么時(shí)候會轉(zhuǎn)移到老年代跟之前講過的原則一樣，唯一不同的是對大對象的處理，G1有專門分配大對象的Region叫Humongous區(qū)，而不是讓大對象直接進(jìn)入老年代的Region中。在G1中，大對象的判定規(guī)則就是一個(gè)大對象超過了一個(gè)Region大小的50%，比如按照上面算的，每個(gè)Region是2M，只要一個(gè)大對象超過了1M，就會被放入Humongous中，而且一個(gè)大對象如果太大，可能會橫跨多個(gè)Region來存放。

????????Humongous區(qū)專門存放短期巨型對象，不用直接進(jìn)老年代，可以節(jié)約老年代的空間，避免因?yàn)槔夏甏臻g不夠的GC開銷。

????????Full GC的時(shí)候除了收集年輕代和老年代之外，也會將Humongous區(qū)一并回收。

????????默認(rèn)年輕代對堆內(nèi)存的占比是5%，如果堆大小為4096M，那么年輕代占據(jù)200MB左右的內(nèi)存，對應(yīng)大概是100個(gè)Region，可以通過“-XX:G1NewSizePercent”設(shè)置新生代初始占比，在系統(tǒng)運(yùn)行中，JVM會不停的給年輕代增加更多的Region，但是最多新生代的占比不會超過60%，可以通過“-XX:G1MaxNewSizePercent”調(diào)整。年輕代中的Eden和Survivor對應(yīng)的region也跟之前一樣，默認(rèn)8:1:1，假設(shè)年輕代現(xiàn)在有1000個(gè)region，eden區(qū)對應(yīng)800個(gè)，s0對應(yīng)100個(gè)，s1對應(yīng)100個(gè)。

????????一個(gè)Region可能之前是年輕代，如果Region進(jìn)行了垃圾回收，之后可能又會變成老年代，也就是說Region的區(qū)域功能可能會動態(tài)變化。

????????G1垃圾收集器對于對象什么時(shí)候會轉(zhuǎn)移到老年代跟之前講過的原則一樣，唯一不同的是對大對象的處理，G1有專門分配大對象的Region叫Humongous區(qū)，而不是讓大對象直接進(jìn)入老年代的Region中。在G1中，大對象的判定規(guī)則就是一個(gè)大對象超過了一個(gè)Region大小的50%，比如按照上面算的，每個(gè)Region是2M，只要一個(gè)大對象超過了1M，就會被放入Humongous中，而且一個(gè)大對象如果太大，可能會橫跨多個(gè)Region來存放。

????????Humongous區(qū)專門存放短期巨型對象，不用直接進(jìn)老年代，可以節(jié)約老年代的空間，避免因?yàn)槔夏甏臻g不夠的GC開銷。

Full GC的時(shí)候除了收集年輕代和老年代之外，也會將Humongous區(qū)一并回收。

G1收集器一次GC(主要值Mixed GC)的運(yùn)作過程大致分為以下幾個(gè)步驟：

初始標(biāo)記（initial mark，STW）：暫停所有的其他線程，并記錄下gc roots直接能引用的對象，速度很快 ；

并發(fā)標(biāo)記（Concurrent Marking）：同CMS的并發(fā)標(biāo)記最終標(biāo)記（Remark，STW）：同CMS的重新標(biāo)記篩選回收（Cleanup，STW）：篩選回收階段首先對各個(gè)Region的回收價(jià)值和成本進(jìn)行排序，根據(jù)用戶所期望的GC停頓STW時(shí)間(可以用JVM參數(shù) -XX:MaxGCPauseMillis指定)來制定回收計(jì)劃，比如說老年代此時(shí)有1000個(gè)Region都滿了，但是因?yàn)楦鶕?jù)預(yù)期停頓時(shí)間，本次垃圾回收可能只能停頓200毫秒，那么通過之前回收成本計(jì)算得知，可能回收其中800個(gè)Region剛好需要200ms，那么就只會回收800個(gè)Region(Collection Set，要回收的集合)，盡量把GC導(dǎo)致的停頓時(shí)間控制在我們指定的范圍內(nèi)。這個(gè)階段其實(shí)也可以做到與用戶程序一起并發(fā)執(zhí)行，但是因?yàn)橹换厥找徊糠諶egion，時(shí)間是用戶可控制的，而且停頓用戶線程將大幅提高收集效率。不管是年輕代或是老年代，回收算法主要用的是復(fù)制算法，將一個(gè)region中的存活對象復(fù)制到另一個(gè)region中，這種不會像CMS那樣回收完因?yàn)橛泻芏鄡?nèi)存碎片還需要整理一次，G1采用復(fù)制算法回收幾乎不會有太多內(nèi)存碎片。(注意：CMS回收階段是跟用戶線程一起并發(fā)執(zhí)行的，G1因?yàn)閮?nèi)部實(shí)現(xiàn)太復(fù)雜暫時(shí)沒實(shí)現(xiàn)并發(fā)回收，不過到了ZGC，Shenandoah就實(shí)現(xiàn)了并發(fā)收集，Shenandoah可以看成是G1的升級版本)

G1收集器在后臺維護(hù)了一個(gè)優(yōu)先列表，每次根據(jù)允許的收集時(shí)間，優(yōu)先選擇回收價(jià)值最大的Region(這也就是它的名字Garbage-First的由來)，比如一個(gè)Region花200ms能回收10M垃圾，另外一個(gè)Region花50ms能回收20M垃圾，在回收時(shí)間有限情況下，G1當(dāng)然會優(yōu)先選擇后面這個(gè)Region回收。這種使用Region劃分內(nèi)存空間以及有優(yōu)先級的區(qū)域回收方式，保證了G1收集器在有限時(shí)間內(nèi)可以盡可能高的收集效率。

被視為JDK1.7以上版本Java虛擬機(jī)的一個(gè)重要進(jìn)化特征。它具備以下特點(diǎn)：

并行與并發(fā)：G1能充分利用CPU、多核環(huán)境下的硬件優(yōu)勢，使用多個(gè)CPU（CPU或者CPU核心）來縮短Stop-The-World停頓時(shí)間。部分其他收集器原本需要停頓Java線程來執(zhí)行GC動作，G1收集器仍然可以通過并發(fā)的方式讓java程序繼續(xù)執(zhí)行。分代收集：雖然G1可以不需要其他收集器配合就能獨(dú)立管理整個(gè)GC堆，但是還是保留了分代的概念?？臻g整合：與CMS的“標(biāo)記--清理”算法不同，G1從整體來看是基于“標(biāo)記整理”算法實(shí)現(xiàn)的收集器；從局部上來看是基于“復(fù)制”算法實(shí)現(xiàn)的?？深A(yù)測的停頓：這是G1相對于CMS的另一個(gè)大優(yōu)勢，降低停頓時(shí)間是G1 和 CMS 共同的關(guān)注點(diǎn)，但G1 除了追求低停頓外，還能建立可預(yù)測的停頓時(shí)間模型，能讓使用者明確指定在一個(gè)長度為M毫秒的時(shí)間片段(通過參數(shù)"-XX:MaxGCPauseMillis"指定)內(nèi)完成垃圾收集。

毫無疑問， 可以由用戶指定期望的停頓時(shí)間是G1收集器很強(qiáng)大的一個(gè)功能， 設(shè)置不同的期望停頓時(shí)間， 可使得G1在不同應(yīng)用場景中取得關(guān)注吞吐量和關(guān)注延遲之間的最佳平衡。 不過， 這里設(shè)置的“期望值”必須是符合實(shí)際的， 不能異想天開， 畢竟G1是要凍結(jié)用戶線程來復(fù)制對象的， 這個(gè)停頓時(shí)

間再怎么低也得有個(gè)限度。 它默認(rèn)的停頓目標(biāo)為兩百毫秒， 一般來說， 回收階段占到幾十到一百甚至接近兩百毫秒都很正常， 但如果我們把停頓時(shí)間調(diào)得非常低， 譬如設(shè)置為二十毫秒， 很可能出現(xiàn)的結(jié)果就是由于停頓目標(biāo)時(shí)間太短， 導(dǎo)致每次選出來的回收集只占堆內(nèi)存很小的一部分， 收集器收集的速度逐漸跟不上分配器分配的速度， 導(dǎo)致垃圾慢慢堆積。 很可能一開始收集器還能從空閑的堆內(nèi)存中獲得一些喘息的時(shí)間， 但應(yīng)用運(yùn)行時(shí)間一長就不行了， 最終占滿堆引發(fā)Full GC反而降低性能， 所以通常把期望停頓時(shí)間設(shè)置為一兩百毫秒或者兩三百毫秒會是比較合理的。

G1垃圾收集分類

YoungGC

YoungGC并不是說現(xiàn)有的Eden區(qū)放滿了就會馬上觸發(fā)，G1會計(jì)算下現(xiàn)在Eden區(qū)回收大概要多久時(shí)間，如果回收時(shí)間遠(yuǎn)遠(yuǎn)小于參數(shù) -XX:MaxGCPauseMillis 設(shè)定的值，那么增加年輕代的region，繼續(xù)給新對象存放，不會馬上做Young GC，直到下一次Eden區(qū)放滿，G1計(jì)算回收時(shí)間接近參數(shù) -XX:MaxGCPauseMillis 設(shè)定的值，那么就會觸發(fā)Young GC

MixedGC

不是FullGC，老年代的堆占有率達(dá)到參數(shù)(-XX:InitiatingHeapOccupancyPercent)設(shè)定的值則觸發(fā)，回收所有的Young和部分Old(根據(jù)期望的GC停頓時(shí)間確定old區(qū)垃圾收集的優(yōu)先順序)以及大對象區(qū)，正常情況G1的垃圾收集是先做MixedGC，主要使用復(fù)制算法，需要把各個(gè)region中存活的對象拷貝到別的region里去，拷貝過程中如果發(fā)現(xiàn)沒有足夠的空region能夠承載拷貝對象就會觸發(fā)一次Full GC

Full GC

停止系統(tǒng)程序，然后采用單線程進(jìn)行標(biāo)記、清理和壓縮整理，好空閑出來一批Region來供下一次MixedGC使用，這個(gè)過程是非常耗時(shí)的。(Shenandoah優(yōu)化成多線程收集了)

G1收集器參數(shù)設(shè)置

-XX:+UseG1GC:使用G1收集器

-XX:ParallelGCThreads:指定GC工作的線程數(shù)量

-XX:G1HeapRegionSize:指定分區(qū)大小(1MB~32MB，且必須是2的N次冪)，默認(rèn)將整堆劃分為2048個(gè)分區(qū)

-XX:MaxGCPauseMillis:目標(biāo)暫停時(shí)間(默認(rèn)200ms)

-XX:G1NewSizePercent:新生代內(nèi)存初始空間(默認(rèn)整堆5%，值配置整數(shù)，默認(rèn)就是百分比)

-XX:G1MaxNewSizePercent:新生代內(nèi)存最大空間

-XX:TargetSurvivorRatio:Survivor區(qū)的填充容量(默認(rèn)50%)，Survivor區(qū)域里的一批對象(年齡1+年齡2+年齡n的多個(gè)年齡對象)總和超過了Survivor區(qū)域的50%，此時(shí)就會把年齡n(含)以上的對象都放入老年代

-XX:MaxTenuringThreshold:最大年齡閾值(默認(rèn)15)

-XX:InitiatingHeapOccupancyPercent:老年代占用空間達(dá)到整堆內(nèi)存閾值(默認(rèn)45%)，則執(zhí)行新生代和老年代的混合收集(MixedGC)，比如我們之前說的堆默認(rèn)有2048個(gè)region，如果有接近1000個(gè)region都是老年代的region，則可能就要觸發(fā)MixedGC了

-XX:G1MixedGCLiveThresholdPercent(默認(rèn)85%) region中的存活對象低于這個(gè)值時(shí)才會回收該region，如果超過這個(gè)值，存活對象過多，回收的的意義不大。

-XX:G1MixedGCCountTarget:在一次回收過程中指定做幾次篩選回收(默認(rèn)8次)，在最后一個(gè)篩選回收階段可以回收一會，然后暫?；厥?，恢復(fù)系統(tǒng)運(yùn)行，一會再開始回收，這樣可以讓系統(tǒng)不至于單次停頓時(shí)間過長。

-XX:G1HeapWastePercent(默認(rèn)5%): gc過程中空出來的region是否充足閾值，在混合回收的時(shí)候，對Region回收都是基于復(fù)制算法進(jìn)行的，都是把要回收的Region里的存活對象放入其他Region，然后這個(gè)Region中的垃圾對象全部清理掉，這樣的話在回收過程就會不斷空出來新的Region，一旦空閑出來的Region數(shù)量達(dá)到了堆內(nèi)存的5%，此時(shí)就會立即停止混合回收，意味著本次混合回收就結(jié)束了。

G1垃圾收集器優(yōu)化建議

假設(shè)參數(shù) -XX:MaxGCPauseMills 設(shè)置的值很大，導(dǎo)致系統(tǒng)運(yùn)行很久才會做年輕代gc，年輕代可能都占用了堆內(nèi)存的60%了，此時(shí)才觸發(fā)年輕代gc。那么存活下來的對象可能就會很多，此時(shí)就會導(dǎo)致Survivor區(qū)域放不下那么多的對象，就會進(jìn)入老年代中。

或者是你年輕代gc過后，存活下來的對象過多，導(dǎo)致進(jìn)入Survivor區(qū)域后觸發(fā)了動態(tài)年齡判定規(guī)則，達(dá)到了Survivor區(qū)域的50%，也會快速導(dǎo)致一些對象進(jìn)入老年代中。

所以這里核心還是在于調(diào)節(jié) -XX:MaxGCPauseMills 這個(gè)參數(shù)的值，在保證他的年輕代gc別太頻繁的同時(shí)，還得考慮每次gc過后的存活對象有多少，避免存活對象太多快速進(jìn)入老年代，頻繁觸發(fā)mixed gc.

什么場景適合使用G1

50%以上的堆被存活對象占用對象分配和晉升的速度變化非常大垃圾回收時(shí)間特別長，超過1秒8GB以上的堆內(nèi)存(建議值)停頓時(shí)間是500ms以內(nèi)

每秒幾十萬并發(fā)的系統(tǒng)如何優(yōu)化JVM

Kafka類似的支撐高并發(fā)消息系統(tǒng)大家肯定不陌生，對于kafka來說，每秒處理幾萬甚至幾十萬消息時(shí)很正常的，一般來說部署kafka需要用大內(nèi)存機(jī)器(比如64G)，也就是說可以給年輕代分配個(gè)三四十G的內(nèi)存用來支撐高并發(fā)處理，這里就涉及到一個(gè)問題了，我們以前常說的對于eden區(qū)的young gc是很快的，這種情況下它的執(zhí)行還會很快嗎？很顯然，不可能，因?yàn)閮?nèi)存太大，處理還是要花不少時(shí)間的，假設(shè)三四十G內(nèi)存回收可能最快也要幾秒鐘，按kafka這個(gè)并發(fā)量放滿三四十G的eden區(qū)可能也就一兩分鐘吧，那么意味著整個(gè)系統(tǒng)每運(yùn)行一兩分鐘就會因?yàn)閥oung gc卡頓幾秒鐘沒法處理新消息，顯然是不行的。那么對于這種情況如何優(yōu)化了，我們可以使用G1收集器，設(shè)置 -XX:MaxGCPauseMills 為50ms，假設(shè)50ms能夠回收三到四個(gè)G內(nèi)存，然后50ms的卡頓其實(shí)完全能夠接受，用戶幾乎無感知，那么整個(gè)系統(tǒng)就可以在卡頓幾乎無感知的情況下一邊處理業(yè)務(wù)一邊收集垃圾。

G1天生就適合這種大內(nèi)存機(jī)器的JVM運(yùn)行，可以比較完美的解決大內(nèi)存垃圾回收時(shí)間過長的問題。

柚子快報(bào)激活碼778899分享：java 5、JVM-G1詳解

http://yzkb.51969.com/

相關(guān)文章