<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          HotSpot JVM 垃圾收集器

          共 3887字,需瀏覽 8分鐘

           ·

          2020-10-11 02:37

          點擊上方「藍字」關注我們

          7種垃圾收集器作用于不同的分代,如果兩個收集器之間存在連續(xù),就說明他們可以搭配使用。

          從JDK1.3到現(xiàn)在,從Serial收集器-》Parallel收集器-》CMS-》G1,用戶線程停頓時間不斷縮短,但仍然無法完全消除。

          ?

          1、Serial收集器(串行收集器)

            Serial收集器是最基本、發(fā)展歷史最悠久的收集器,曾是(JDK1.3.1之前)虛擬機新生代收集的唯一選擇。

            Serial收集器是一個單線程的收集器。“單線程”的意義不僅僅是它只會使用一個CPU或一條收集器線程去完成垃圾收集工作,更重要的是它在垃圾收集的時候,必須暫停其他所有工作的線程,直到它收集結束。

            Serial收集器是HotSpot虛擬機運行在Client模式下的默認新生代收集器。

            Serial收集器具有簡單而高效,由于沒有線程交互的開銷,可以獲得最高的單線程收集效率(在單個CPU環(huán)境中)。

            "-XX:+UseSerialGC":添加該參數(shù)來顯式的使用Serial垃圾收集器。

          ?

          2、ParNew收集器

            ParNew收集器是Serial收集器的多線程版本,除了使用多條線程進行垃圾收集之外,其余行為包括Serial收集器可用的所有控制參數(shù)、收集算法、Stop The Word、對象分配規(guī)則、回收策略等都與Serial收集器一樣。

            ParNew收集器是許多運行在Server模式下的虛擬機首選的新生代收集器,其中一個原因是,除了Serial收集器之外,目前只有ParNew收集器能與CMS收集器配合工作。 

            "-XX:+UseConcMarkSweepGC":指定使用CMS后,會默認使用ParNew作為新生代收集器。

          ? ? ? ?"-XX:+UseParNewGC":強制指定使用ParNew。???

          ? ? ? ?"-XX:ParallelGCThreads":指定垃圾收集的線程數(shù)量,ParNew默認開啟的收集線程與CPU的數(shù)量相同。

            并行(Parallel):指多條垃圾收集線程并行工作,但此時用戶線程仍然處于等待狀態(tài)。

            并發(fā)(Concurrent):指用戶線程與垃圾收集線程同時執(zhí)行(但不一定是并行,可能是交替執(zhí)行),用戶線程繼續(xù)工作,而垃圾收集程序運行在另一個CPU上。

          ?

          3、Parallel Scavenge收集器

            Parallel Scavenge收集器是一個新生代收集器,使用復制算法,且是并行的多線程收集器。

            Parallel Scavenge收集器關注點是達到一個可控制的吞吐量(吞吐量 = 運行用戶代碼時間 / (運行用戶代碼時間 + 垃圾收集時間)),而其他收集器關注點在盡可能的縮短垃圾收集時用戶線程的停頓時間。

            Parallel Scavenge收集器提供了兩個參數(shù)來用于精確控制吞吐量,一是控制最大垃圾收集停頓時間的?-XX:MaxGCPauseMillis參數(shù),二是控制吞吐量大小的 -XX:GCTimeRatio參數(shù);

            “?-XX:MaxGCPauseMillis” 參數(shù)允許的值是一個大于0的毫秒數(shù),收集器將盡可能的保證內存垃圾回收花費的時間不超過設定的值(但是,并不是越小越好,GC停頓時間縮短是以犧牲吞吐量和新生代空間來換取的,如果設置的值太小,將會導致頻繁GC,這樣雖然GC停頓時間下來了,但是吞吐量也下來了)。

            “?-XX:GCTimeRatio”參數(shù)的值是一個大于0且小于100的整數(shù),也就是垃圾收集時間占總時間的比率,默認值是99,就是允許最大1%(即1/(1+99))的垃圾收集時間。

            “-XX:UseAdaptiveSizePolicy”參數(shù)是一個開發(fā),如果這個參數(shù)打開之后,虛擬機會根據(jù)當前系統(tǒng)運行情況收集監(jiān)控信息,動態(tài)調整新生代的比例、老年大小等細節(jié)參數(shù),以提供最合適的停頓時間或最大的吞吐量,這種調節(jié)方式稱為GC自適應的調節(jié)策略。

          ?

          4、Serial Old收集器

            Serial Old收集器是Seria收集器的老年代版本,他同樣是一個單線程收集器,使用" 標記-整理" 算法。

            Serial Old收集器主要用于Client模式下的虛擬機使用。

            Server模式下的兩大用途:一、在JDK1.5及之前的版本與Parallel Scavenge收集器搭配使用;二、作為CMS收集器的后備方案,在并發(fā)收集發(fā)生Conturrent Mode Failure時使用。

          ?

          5、Paraller Old收集器

            Parallel Old收集器是Parallel Scavenge收集器的老年代版本,使用多線程和“標記-整理”算法。

            在JDK1.6中才出現(xiàn)。

          ?

          6、CMS(Conturrent Mark Sweep)收集器

            CMS收集器是一種以獲取最短回收停頓時間為目標的收集器。

            目前很大一部分的Java應用集中在互聯(lián)網(wǎng)或者B/S系統(tǒng)的服務端上。

            CMS收集器是基于“標記-清除”算法實現(xiàn),它的整個運行過程可以分為:初始登記(標記一下GC Roots能直接關聯(lián)到的對象,這個過程速度很快)、并發(fā)標記(進行GCRoots Tracing的過程)、重新標記(修正并發(fā)標記期間因用戶線程繼續(xù)運作而導致標記產(chǎn)生變動的那一部分對象的標記記錄,速度稍慢)、并發(fā)清除(清除死亡的對象)4個步驟;其中,初始標記和重新標記仍然需要“Stop The World”。

            CMS收集器運行的整個過程中,最耗費時間的并發(fā)標記和并發(fā)清楚過程收集器線程和用戶線程是一起工作的,所以總體來說,CMS收集器的內存回收過程是與用戶線程一起并發(fā)執(zhí)行的。

          優(yōu)點:并發(fā)收集、低停頓。

          缺點:

          一:CMS收集器對CPU資源非常敏感。雖然在兩個并發(fā)階段不會導致用戶線程停頓,但是會因為占用了一部分線程而導致應用程序變慢,總吞吐量下降。CMS默認啟動的回收線程數(shù)是(CPU數(shù)量+3)/4。

          二:CMS收集器無法處理浮動垃圾,可能出現(xiàn)“Conturrent Mode Failure”失敗而導致另一次Full GC產(chǎn)生。由于CMS并發(fā)清除階段用戶線程還在運行,伴隨著程序還在產(chǎn)生新的垃圾,這一部分垃圾出現(xiàn)在標記之后,CMS無法在當次收集中處理掉它們,只能留到下次再清理,這一部分垃圾稱為“浮動垃圾”。也正是由于在垃圾收集階段用戶線程還在運行,那么也就需要預留有足夠的內存空間給用戶線程使用,因此CMS收集器不能像其他收集器那樣等待老年代填滿之后再進行收集,需要預留一部分空間給并發(fā)收集時用戶程序使用。可以通過“-XX:CMSInitiatingOccupancyFraction”參數(shù)設置老年代內存使用達到多少時啟動收集。

          三:由于CMS收集器是一個基于“標記-清除”算法的收集器,那么意味著收集結束會產(chǎn)生大量碎片,有時候往往還有很多內存未使用,可是沒有一塊連續(xù)的空間來分配一個對象,導致不得不提前觸發(fā)一次Full GC。CMS收集器提供了一個“-XX:UseCMSCompactAtFullCollection”參數(shù)(默認是開啟的)用于在CMS收集器頂不住要FullGC時開啟內存碎片整理(內存碎片整理意味著無法并發(fā)執(zhí)行不得不停頓用戶線程)。參數(shù)“-XX:CMSFullGCsBeforeCompaction”來設置執(zhí)行多少次不壓縮的Full GC后,跟著來一次帶壓縮的(默認值是0,意味著每次進入Full GC時都進行碎片整理)。

            

          7、G1(Garbage-First)收集器

          G1收集器是當今收集器技術發(fā)展的最前沿成果之一;

          相比其它收集器,具有如下特點:

          1、并行與并發(fā):G1能夠重發(fā)利用多CPU、多核環(huán)境下的優(yōu)勢,使用多個CPU來縮短Stop-The-World停頓時間。

          2、分代收集:與其他收集器一樣,分代概念在G1中依然存在。

          3、空間整合:與CMS的“標記-清理”算法不同,G1從整體來看是基于“標記-整理”來實現(xiàn)的收集器,從局部(兩個Region之間)上來看是基于“復制”算法實現(xiàn)的,這兩種算法都意味著G1運作期間不會產(chǎn)生內存空間碎片,收集后能夠提供整體的可用內存。

          4、可預測停頓:G1除了追求低停頓之外,還能建立可預測的停頓時間模型,能讓使用者明確指定在一個長度為M毫秒的時間片段內,消耗在垃圾收集上的時間不得超過N毫秒。

            使用G1收集器時,Java堆的內存布局與其他收集器有很大的區(qū)別,它將整個Java堆劃分為多個大小相等的獨立區(qū)域(Region),雖然還保留著新生代和老年代的概念,但新生代和老年代不再是物理隔離的了,他們都是一部分Region(不需要連續(xù))的集合。

            G1收集器之所以能夠建立可預測的停頓時間模型,是因為它可以有計劃地避免在整個Java對中進行全區(qū)域的垃圾收集。G1跟蹤各個Region里面垃圾堆積的價值大小(回收所獲得的空間大小以及回收所需要時間的經(jīng)驗值),在后臺維護一個優(yōu)先列表,每次根據(jù)允許的收集時間,優(yōu)先回收價值最大的Region(這也是Garbage-First名稱的由來)。

          G1收集器的運作大致可分為:

          1、初始標記:需要停頓,耗時短;

          2、并發(fā)標記

          3、最終標記:需要停頓,可并發(fā)執(zhí)行;

          4、篩選標記

          掃碼二維碼

          獲取更多精彩

          Java樂園

          有用!分享+在看?
          瀏覽 32
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  在线综合视频 | 99热在线观看免费 | 91九九九 | 99久久夜色精品国产亚洲 | 香蕉网视频|