這篇文章主要講解了“Java的垃圾回收器有哪些”，文中的講解內(nèi)容簡單清晰，易于學(xué)習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習“Java的垃圾回收器有哪些”吧！

在朝陽等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都網(wǎng)站設(shè)計、網(wǎng)站制作 網(wǎng)站設(shè)計制作按需規(guī)劃網(wǎng)站,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站制作,全網(wǎng)整合營銷推廣,外貿(mào)網(wǎng)站制作,朝陽網(wǎng)站建設(shè)費用合理。

我們先回顧一下主流Java的垃圾回收器(HotSpot JVM)。本文是針對堆的垃圾回收展開討論的。 堆被分解為較小的三個部分。具體分為：新生代、老年代、持久代。

1. 絕大部分新生成的對象都放在Eden區(qū)，當Eden區(qū)將滿，JVM會因申請不到內(nèi)存，而觸發(fā)Young GC ,進行Eden區(qū)+有對象的Survivor區(qū)(設(shè)為S0區(qū))垃圾回收，把存活的對象用復(fù)制算法拷貝到一個空的Survivor(S1)中，此時Eden區(qū)被清空，另外一個Survivor S0也為空。下次觸發(fā)Young GC回收Eden+S0，將存活對象拷貝到S1中。新生代垃圾回收簡單、粗暴、高效。

2. 若發(fā)現(xiàn)Survivor區(qū)滿了，則將這些對象拷貝到old區(qū)或者Survivor沒滿但某些對象足夠Old,也拷貝到Old區(qū)(每次Young GC都會使Survivor區(qū)存活對象值+1，直到閾值)。 Old區(qū)也會進行垃圾收集(Young GC),發(fā)生一次 Major GC 至少伴隨一次Young GC，一般比Young GC慢十倍以上。

3. JVM在Old區(qū)申請不到內(nèi)存，會進行Full GC。Old區(qū)使用一般采用Concurrent-Mark–Sweep策略回收內(nèi)存。 總結(jié)：Java垃圾回收器是一種“自適應(yīng)的、分代的、停止—復(fù)制、標記-清掃”式的垃圾回收器 缺點：

4. GC過程中會出現(xiàn)STW(Stop-The-World)，若Old區(qū)對象太多，STW耗費大量時間。

5. CMS收集器對CPU資源很敏感。

6. CMS收集器無法處理浮動垃圾，可能出現(xiàn)“Concurrent Mode Failure”失敗而導(dǎo)致另一次Full GC的產(chǎn)生。

7. CMS導(dǎo)致內(nèi)存碎片問題

#比較

1. Serial收集器
   Serial收集器是JAVA虛擬機中最基本、歷史最悠久的收集器，在JDK 1.3.1之前是JAVA虛擬機新生代收集的唯一選擇。Serial收集器是一個單線程的收集器，但它的“單線程”的意義并不僅僅是說明它只會使用一個CPU或一條收集線程去完成垃圾收集工作，更重要的是在它進行垃圾收集時，必須暫停其他所有的工作線程，直到它收集結(jié)束。 Serial收集器到JDK1.7為止，它依然是JAVA虛擬機運行在Client模式下的默認新生代收集器。它也有著優(yōu)于其他收集器的地方：簡單而高效（與其他收集器的單線程比），對于限定單個CPU的環(huán)境來說，Serial收集器由于沒有線程交互的開銷，專心做垃圾收集自然可以獲得最高的單線程收集效率。在用戶的桌面應(yīng)用場景中，分配給虛擬機管理的內(nèi)存一般來說不會很大，收集幾十兆甚至一兩百兆的新生代（僅僅是新生代使用的內(nèi)存，桌面應(yīng)用基本上不會再大了），停頓時間完全可以控制在幾十毫秒最多一百多毫秒以內(nèi)，只要不是頻繁發(fā)生，這點停頓是可以接受的。所以，Serial收集器對于運行在Client模式下的虛擬機來說是一個很好的選擇。
   PS：開啟Serial收集器的方式 -XX:+UseSerialGC 如：Xms30m -Xmx30m -Xmn10m -XX:+UseSerialGC -XX:+PrintGCDetails -XX:+UseSerialGC的是Serial收集器，Xms30m -Xmx30m 指定了JAVA虛擬機的固定大小為30M，-Xmn10m 指JAVA新生代的空間為10M。

2. Parallel（并行）收集器
   這是 JVM 的缺省收集器。就像它的名字，其最大的優(yōu)點是使用多個線程來通過掃描并壓縮堆。串行收集器在GC時會停止其他所有工作線程（stop-the-world），CPU利用率是最高的，所以適用于要求高吞吐量（throughput）的應(yīng)用，但停頓時間（pause time）會比較長，所以對web應(yīng)用來說就不適合，因為這意味著用戶等待時間會加長。而并行收集器可以理解是多線程串行收集，在串行收集基礎(chǔ)上采用多線程方式進行GC，很好的彌補了串行收集的不足，可以大幅縮短停頓時間（如下圖表示的停頓時長高度，并發(fā)比并行要短），因此對于空間不大的區(qū)域（如young generation），采用并行收集器停頓時間很短，回收效率高，適合高頻率執(zhí)行。 圖1.Serial收集器與Parallel/ Throughput（并行）收集器的比較

3. CMS收集器
   CMS（Concurrent Mark Sweep）收集器是基于“標記-清除”算法實現(xiàn)的，它使用多線程的算法去掃描堆（標記）并對發(fā)現(xiàn)的未使用的對象進行回收（清除）。整個過程分為6個步驟，包括： 初始標記（CMS initial mark）

   并發(fā)標記（CMS concurrent mark）

   并發(fā)預(yù)清理（CMS-concurrent-preclean）

   重新標記（CMS remark）

   并發(fā)清除（CMS concurrent sweep）

   并發(fā)重置（CMS-concurrent-reset）

   其中初始標記、重新標記這兩個步驟仍然需要“Stop The World”。
   初始標記僅僅只是標記一下GC Roots能直接關(guān)聯(lián)到的對象，速度很快
   并發(fā)標記階段就是進行GC Roots Tracing的過程
   重新標記階段則是為了修正并發(fā)標記期間，因用戶程序繼續(xù)運作而導(dǎo)致標記產(chǎn)生變動的那一部分對象的標記記錄，這個階段的停頓時間一般會比初始標記階段稍長一些，但遠比并發(fā)標記的時間短。其他動作都是并發(fā)的。

   需要注意的是，CMS收集器無法處理浮動垃圾（Floating Garbage），可能出現(xiàn)“Concurrent Mode Failure”失敗而導(dǎo)致另一次Full GC的產(chǎn)生。由于CMS并發(fā)清理階段用戶線程還在運行著，伴隨程序的運行自然還會有新的垃圾不斷產(chǎn)生，這一部分垃圾出現(xiàn)在標記過程之后，CMS無法在本次收集中處理掉它們，只好留待下一次GC時再將其清理掉。這一部分垃圾就稱為“浮動垃圾”。也是由于在垃圾收集階段用戶線程還需要運行，即還需要預(yù)留足夠的內(nèi)存空間給用戶線程使用，因此CMS收集器不能像其他收集器那樣等到老年代幾乎完全被填滿了再進行收集，需要預(yù)留一部分空間提供并發(fā)收集時的程序運作使用。在默認設(shè)置下，CMS收集器在老年代使用了68%的空間后就會被激活，這是一個偏保守的設(shè)置，如果在應(yīng)用中老年代增長不是太快，可以適當調(diào)高參數(shù)-XX:CMSInitiatingOccupancyFraction的值來提高觸發(fā)百分比，以便降低內(nèi)存回收次數(shù)以獲取更好的性能。要是CMS運行期間預(yù)留的內(nèi)存無法滿足程序需要，就會出現(xiàn)一次“Concurrent Mode Failure”失敗，這時候虛擬機將啟動后備預(yù)案：臨時啟用Serial Old收集器來重新進行老年代的垃圾收集，這樣停頓時間就很長了。所以說參數(shù)-XX:CMSInitiatingOccupancyFraction設(shè)置得太高將會很容易導(dǎo)致大量“Concurrent Mode Failure”失敗，性能反而降低。
   還有一個缺點，CMS是一款基于“標記-清除”算法實現(xiàn)的收集器，這意味著收集結(jié)束時會產(chǎn)生大量空間碎片?？臻g碎片過多時，將會給大對象分配帶來很大的麻煩，往往會出現(xiàn)老年代還有很大的空間剩余，但是無法找到足夠大的連續(xù)空間來分配當前對象，不得不提前觸發(fā)一次Full GC。為了解決這個問題，CMS收集器提供了一個-XX:+UseCMSCompactAtFullCollection開關(guān)參數(shù)，用于在“享受”完Full GC服務(wù)之后額外免費附送一個碎片整理過程，內(nèi)存整理的過程是無法并發(fā)的。空間碎片問題沒有了，但停頓時間不得不變長了。虛擬機設(shè)計者們還提供了另外一個參數(shù)-XX: CMSFullGCsBeforeCompaction，這個參數(shù)用于設(shè)置在執(zhí)行多少次不壓縮的Full GC后，跟著來一次帶壓縮的。
   該算法與并行收集器的另一個缺點是吞吐量的它使用更多的 CPU，為了使應(yīng)用程序提供更好的體驗，通過使用多個線程來執(zhí)行掃描和收集。這種情況長時間的運行會使應(yīng)用程序停頓下來，可以使用提高空間來換取高效的運行。但是，這種算法的使用不是默認的。您必須指定 XX： + USeParNewGC來使用它。如果你可以提供更多的CPU資源的話以避免應(yīng)用程序暫停，那么你可以使用CMS收集器。假設(shè)你的堆的大小小于 4 Gb你必須分配大于 4 GB的資源。

4. G1收集器
   G1垃圾收集器在JDK7 update 4之后對大于4G的堆有了更好的支持，G1是一個針對多處理器大容量內(nèi)存的服務(wù)器端的垃圾收集器，其目標是在實現(xiàn)高吞吐量的同時，盡可能的滿足垃圾收集暫停時間的要求。G1在執(zhí)行一些Java堆空間中的全區(qū)域操作（如：全局標記）時是和應(yīng)用程序線程并發(fā)進行的，因此減少了Java堆空間的中斷比例。（譯者注：可簡單理解為減少了Stop-the-World的時間比例）。
   它與前面的CMS收集器相比有兩個顯著的改進：一是G1收集器是基于“標記-整理”算法實現(xiàn)的收集器，也就是說它不會產(chǎn)生空間碎片，這對于長時間運行的應(yīng)用系統(tǒng)來說非常重要。二是它可以非常精確地控制停頓，既能讓使用者明確指定在一個長度為M毫秒的時間片段內(nèi)，消耗在垃圾收集上的時間不得超過N毫秒，具備了一些實時Java（RTSJ）的垃圾收集器的特征。
   首先將Java堆空間劃分為一些大小相等的區(qū)域（region），每個區(qū)域都是虛擬機中的一段連續(xù)內(nèi)存空間。G1通過執(zhí)行并發(fā)的全局標記來確定整個Java堆空間中存活的對象。標記階段完成后，G1就知道哪些區(qū)域基本上是空閑的。在回收內(nèi)存時優(yōu)先回收這些區(qū)域，這樣通常都會回收相當數(shù)量的內(nèi)存。這就是為什么它叫做Garbage-First的原因。顧名思義G1關(guān)注某些區(qū)域的回收和整理，這些區(qū)域中的對象很有可能被完全回收。而且G1使用了一個暫停時間預(yù)測模型使得暫停時間控制在用戶指定的暫停時間內(nèi)，并根據(jù)用戶指定的暫停時間來選擇合適的區(qū)域回收內(nèi)存。
   G1確定了可回收的區(qū)域后就是篩選回收（evacuation）階段了。在此階段將對象從一個或多個區(qū)域復(fù)制到單一區(qū)域，同時整理和釋放內(nèi)存。該階段是在多個處理器上多個線程并行進行的，因此減少了暫停時間并提高了吞吐量。G1在每一次的垃圾收集過程中都不斷地減少碎片，并能夠?qū)和r間控制在一定范圍內(nèi)。這些已經(jīng)是以前的垃圾收集器無法完成的了。比如：CMS收集器并不做內(nèi)存整理。ParallelOld收集器只是對整個Java堆空間做整理，這樣導(dǎo)致相當長的暫停時間。

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

網(wǎng)頁名稱：Java的垃圾回收器有哪些
網(wǎng)頁路徑：http://jinyejixie.com/article42/ppshec.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供營銷型網(wǎng)站建設(shè)、網(wǎng)站建設(shè)、網(wǎng)站策劃、網(wǎng)站導(dǎo)航、自適應(yīng)網(wǎng)站、

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)