文章出處
文章列表
HotSpot JVM收集器

上面有7中收集器,分為兩塊,上面為新生代收集器,下面是老年代收集器。如果兩個收集器之間存在連線,就說明它們可以搭配使用。
Serial(串行GC)收集器
Serial收集器是一個新生代收集器,單線程執行,使用復制算法。它在進行垃圾收集時,必須暫停其他所有的工作線程(用戶線程)。是Jvm client模式下默認的新生代收集器。對于限定單個 CPU的環境來說,Serial收集器由于沒有線程交互的開銷,專心做垃圾收集自然可以獲得最高的單線程收集效率。ParNew(并行GC)收集器
ParNew收集器其實就是serial收集器的多線程版本,除了使用多條線程進行垃圾收集之外,其余行為與Serial收集器一樣。Parallel Scavenge(并行回收GC)收集器
Parallel Scavenge收集器也是一個新生代收集器,它也是使用復制算法的收集器,又是并行多線程收集器。parallel Scavenge收集器的特點是它的關注點與其他收集器不同,CMS等收集 器的關注點是盡可能地縮短垃圾收集時用戶線程的停頓時間,而parallel Scavenge收集器的目標則是達到一個可控制的吞吐量。吞吐量= 程序運行時間/(程序運行時間 + 垃圾收集時間),虛擬機 總共運行了100分鐘。其中垃圾收集花掉1分鐘,那吞吐量就是99%。 Serial Old是Serial收集器的老年代版本,它同樣使用一個單線程執行收集,使用“標記-整理”算法。主要使用在Client模式下的虛擬機。 Parallel Old是Parallel Scavenge收集器的老年代版本,使用多線程和“標記-整理”算法。 CMS(Concurrent Mark Sweep)收集器是一種以獲取最短回收停頓時間為目標的收集器。CMS收集器是基于“標記-清除”算法實現的,
整個收集過程大致分為4個步驟:
①.初始標記(CMS initial mark)
②.并發標記(CMS concurrenr mark)
③.重新標記(CMS remark)
④.并發清除(CMS concurrent sweep)
其中初始標記、重新標記這兩個步驟任然需要停頓其他用戶線程。初始標記僅僅只是標記出GC ROOTS能直接關聯到的對象,速度很快,并發標記階段是進行GC ROOTS 根搜索算法階段,會判定對象是否存活。而重新標記階段則是為了修正并發標記期間,因用戶程序繼續運行而導致標記產生變動的那一部分對象的標記記錄,這個階段的停頓時間會被初始標記階段稍長,但比并發標記 階段要短。
由于整個過程中耗時最長的并發標記和并發清除過程中,收集器線程都可以與用戶線程一起工作,所以整體來說,CMS收集器的內存回收過程是與用戶線程一起并發執行的。
CMS收集器的優點:并發收集、低停頓,但是CMS還遠遠達不到完美,器主要有三個顯著缺點:
CMS收集器對CPU資源非常敏感。在并發階段,雖然不會導致用戶線程停頓,但是會占用CPU資源而導致引用程序變慢,總吞吐量下降。CMS默認啟動的回收線程數是:(CPU數量+3) / 4。
CMS收集器無法處理浮動垃圾,可能出現“Concurrent Mode Failure“,失敗后而導致另一次Full GC的產生。由于CMS并發清理階段用戶線程還在運行,伴隨程序的運行自熱會有新的垃圾不斷產生,這一部分垃圾出現在標記過程之后,CMS無法在本次收集中處理它們,只好留待下一次GC時將其清理掉。這一部分垃圾稱為“浮動垃圾”。也是由于在垃圾收集階段用戶線程還需要運行,
即需要預留足夠的內存空間給用戶線程使用,因此CMS收集器不能像其他收集器那樣等到老年代幾乎完全被填滿了再進行收集,需要預留一部分內存空間提供并發收集時的程序運作使用。在默認設置下,CMS收集器在老年代使用了68%的空間時就會被激活,也可以通過參數-XX:CMSInitiatingOccupancyFraction的值來提供觸發百分比,以降低內存回收次數提高性能。要是CMS運行期間預留的內存無法滿足程序其他線程需要,就會出現“Concurrent Mode Failure”失敗,這時候虛擬機將啟動后備預案:臨時啟用Serial Old收集器來重新進行老年代的垃圾收集,這樣停頓時間就很長了。所以說參數-XX:CMSInitiatingOccupancyFraction設置的過高將會很容易導致“Concurrent Mode Failure”失敗,性能反而降低。
即需要預留足夠的內存空間給用戶線程使用,因此CMS收集器不能像其他收集器那樣等到老年代幾乎完全被填滿了再進行收集,需要預留一部分內存空間提供并發收集時的程序運作使用。在默認設置下,CMS收集器在老年代使用了68%的空間時就會被激活,也可以通過參數-XX:CMSInitiatingOccupancyFraction的值來提供觸發百分比,以降低內存回收次數提高性能。要是CMS運行期間預留的內存無法滿足程序其他線程需要,就會出現“Concurrent Mode Failure”失敗,這時候虛擬機將啟動后備預案:臨時啟用Serial Old收集器來重新進行老年代的垃圾收集,這樣停頓時間就很長了。所以說參數-XX:CMSInitiatingOccupancyFraction設置的過高將會很容易導致“Concurrent Mode Failure”失敗,性能反而降低。
最后一個缺點,CMS是基于“標記-清除”算法實現的收集器,使用“標記-清除”算法收集后,會產生大量碎片。空間碎片太多時,將會給對象分配帶來很多麻煩,比如說大對象,內存空間找不到連續的空間來分配不得不提前觸發一次Full GC。為了解決這個問題,CMS收集器提供了一個-XX:UseCMSCompactAtFullCollection開關參數,用于在Full GC之后增加一個碎片整理過程,還可通過-XX:CMSFullGCBeforeCompaction參數設置執行多少次不壓縮的Full GC之后,跟著來一次碎片整理過程。
G1(Garbage First)收集器是JDK1.7提供的一個新收集器,G1收集器基于“標記-整理”算法實現,也就是說不會產生內存碎片。還有一個特點之前的收集器進行收集的范圍都是整個新生代或老年代,而G1將整個Java堆(包括新生代,老年代)。
垃圾收集器參數總結
-XX:+<option> 啟用選項
-XX:-<option> 不啟用選項
-XX:<option>=<number>
-XX:<option>=<string>
參數 | 描述 |
---|---|
-XX:+UseSerialGC |
Jvm運行在Client模式下的默認值,打開此開關后,使用Serial + Serial Old的收集器組合進行內存回收 |
-XX:+UseParNewGC | 打開此開關后,使用ParNew + Serial Old的收集器進行垃圾回收 |
-XX:+UseConcMarkSweepGC | 使用ParNew + CMS + Serial Old的收集器組合進行內存回收,Serial Old作為CMS出現“Concurrent Mode Failure”失敗后的后備收集器使用。 |
-XX:+UseParallelGC | Jvm運行在Server模式下的默認值,打開此開關后,使用Parallel Scavenge + Serial Old的收集器組合進行回收 |
-XX:+UseParallelOldGC | 使用Parallel Scavenge + Parallel Old的收集器組合進行回收 |
-XX:SurvivorRatio | 新生代中Eden區域與Survivor區域的容量比值,默認為8,代表Eden:Subrvivor = 8:1 |
-XX:PretenureSizeThreshold | 直接晉升到老年代對象的大小,設置這個參數后,大于這個參數的對象將直接在老年代分配 |
-XX:MaxTenuringThreshold | 晉升到老年代的對象年齡,每次Minor GC之后,年齡就加1,當超過這個參數的值時進入老年代 |
-XX:UseAdaptiveSizePolicy | 動態調整java堆中各個區域的大小以及進入老年代的年齡 |
-XX:+HandlePromotionFailure | 是否允許新生代收集擔保,進行一次minor gc后, 另一塊Survivor空間不足時,將直接會在老年代中保留 |
-XX:ParallelGCThreads | 設置并行GC進行內存回收的線程數 |
-XX:GCTimeRatio | GC時間占總時間的比列,默認值為99,即允許1%的GC時間,僅在使用Parallel Scavenge 收集器時有效 |
-XX:MaxGCPauseMillis | 設置GC的最大停頓時間,在Parallel Scavenge 收集器下有效 |
-XX:CMSInitiatingOccupancyFraction | 設置CMS收集器在老年代空間被使用多少后出發垃圾收集,默認值為68%,僅在CMS收集器時有效,-XX:CMSInitiatingOccupancyFraction=70 |
-XX:+UseCMSCompactAtFullCollection | 由于CMS收集器會產生碎片,此參數設置在垃圾收集器后是否需要一次內存碎片整理過程,僅在CMS收集器時有效 |
-XX:+CMSFullGCBeforeCompaction | 設置CMS收集器在進行若干次垃圾收集后再進行一次內存碎片整理過程,通常與UseCMSCompactAtFullCollection參數一起使用 |
-XX:+UseFastAccessorMethods | 原始類型優化 |
-XX:+DisableExplicitGC | 是否關閉手動System.gc |
-XX:+CMSParallelRemarkEnabled | 降低標記停頓 |
-XX:LargePageSizeInBytes | 內存頁的大小不可設置過大,會影響Perm的大小,-XX:LargePageSizeInBytes=128m |
Client、Server模式默認GC
新生代GC方式 | 老年代和持久代GC方式 | |
---|---|---|
Client |
Serial 串行GC | Serial Old 串行GC |
Server | Parallel Scavenge 并行回收GC | Parallel Old 并行GC |
Sun/Oracle JDK GC組合方式
新生代GC方式 | 老年代和持久代GC方式 | |
---|---|---|
-XX:+UseSerialGC |
Serial 串行GC | Serial Old 串行GC |
-XX:+UseParallelGC | Parallel Scavenge 并行回收GC | Serial Old 并行GC |
-XX:+UseConcMarkSweepGC | ParNew 并行GC | CMS 并發GC 當出現“Concurrent Mode Failure”時 采用Serial Old 串行GC |
-XX:+UseParNewGC | ParNew 并行GC | Serial Old 串行GC |
-XX:+UseParallelOldGC | Parallel Scavenge 并行回收GC | Parallel Old 并行GC |
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC |
Serial 串行GC | CMS 并發GC 當出現“Concurrent Mode Failure”時 采用Serial Old 串行GC |
轉自 http://blog.csdn.net/java2000_wl/article/details/8030172
文章列表
全站熱搜