原文地址:http://apmblog.compuware.com/2011/05/11/how-garbage-collection-differs-in-the-three-big-jvms/
========================================================================================
Hotspot JVM使用和 IBM Websphere及 OracleWeblogic不同的垃圾回收機(jī)制,但是垃圾回收的概念和算法是相通的。
HotSpotJVM
1)HotSpotJVM使用內(nèi)存分區(qū)(如永久perm區(qū)和分代Generation Heap區(qū)),分代區(qū)(Generation Heap區(qū))又包括新生Yong區(qū)和老生Old/Tenured區(qū),Yong區(qū)中又分為Eden區(qū)和 Survior區(qū)(2塊);
2)Yong區(qū) GC:對(duì)象先在Yong區(qū)的Eden中得到分配,任何時(shí)候Eden區(qū)滿了就會(huì)觸發(fā)Yong區(qū)GC (Minor GC?),會(huì)把Yong區(qū)Eden中仍存活的Live對(duì)象拷貝到空的那個(gè)Survior區(qū),除此之外,另外一個(gè)Survior區(qū)中的對(duì)象也會(huì)被檢查和拷貝(在2個(gè)Survior區(qū)之間拷貝對(duì)象的頻率是可配置的),其結(jié)果就是對(duì)象僅存在于一個(gè)Survior區(qū)中,而Eden區(qū)和另一塊Survior區(qū)是空的。這種形式的GC叫“拷貝收集(Copy Collection)”。Yong區(qū)中多次GC后仍存活的對(duì)象會(huì)被提升/拷貝到Old區(qū)。
3) Old區(qū) GC:標(biāo)記和打掃(Mark & Sweep)算法是老生區(qū)(OldHeap)使用的GC算法,與新生代Yong區(qū)算法不同的地方在于它不拷貝對(duì)象。對(duì)象越多GC消耗時(shí)間越長(zhǎng),因此老生區(qū)GC代價(jià)很高并盡量避免,因此我們需要保證對(duì)象僅僅從Yong區(qū)拷貝到Old區(qū)并保證Old區(qū)不被填滿,因此,代區(qū)的大小是Hotspot JVM中單一的一個(gè)最重要的優(yōu)化參數(shù)。如果我們不能阻止對(duì)象從Yong區(qū)拷貝到Old區(qū),我們可以使用“并發(fā)標(biāo)記和打掃算法”(CMS -Concurrent Mark and Sweep),此算法可以并行的進(jìn)行收集操作。(停頓時(shí)間:串行(Serial) <平行(Parallel) <并發(fā)(Concurrent))。
Old區(qū)GC還有其他問題,比如“碎片問題”會(huì)導(dǎo)致“慢分配”,更長(zhǎng)的打掃時(shí)間并最終會(huì)導(dǎo)致OOM(當(dāng)分配大對(duì)象而遇到的全是小空間時(shí)).
碎片問題可通過被稱為“壓縮”的方法來解決。“串行和平行算法(Serialand Parallel)”會(huì)在每次Old區(qū)進(jìn)行GC時(shí)進(jìn)行壓縮,它不對(duì)整個(gè)Old區(qū)壓縮而只對(duì)Old區(qū)中碎片程度達(dá)到一定Level的區(qū)域區(qū)進(jìn)行。相比之下,“并發(fā)標(biāo)記和打掃算法CMS”根本就不會(huì)進(jìn)行壓縮。當(dāng)對(duì)象不能再被分配時(shí),一個(gè)串行的“主要MajorGC”會(huì)被觸發(fā)。
因此,HotSpot 的第二個(gè)調(diào)整參數(shù)是選擇正確的GC策略,GC策略的選擇會(huì)影響應(yīng)用的性能,HotSpot中的大部分GC策略調(diào)整選項(xiàng)參數(shù)是是關(guān)于分片和壓縮的, HotspotJVM沒有提供太多調(diào)整參數(shù),因此,唯一的方法是優(yōu)化代碼減少申請(qǐng)對(duì)象的次數(shù)。
4) Permanent Generation 永久區(qū):保存屬于類的(靜態(tài)的)屬性和字符串常量等,永久區(qū)的GC只會(huì)發(fā)生在“主要Major GC”時(shí)(Major GC很少發(fā)生),因此很多人認(rèn)為Hotspot JVM在永久區(qū)根本不會(huì)GC。
Major GC - “Stops the world” and“cost much time”, e.g. Full GC.
OracleJRockit
1) Oracle WebLogic使用的JVM,將來會(huì)和Hotspot合并
2) Heap策略 -也使用“分代Heap”,而且支持一個(gè)所謂的“連續(xù)Heap”。分代Heap分為:老生區(qū)(Old/Tenured)和苗圃/新生區(qū)(Nursery),當(dāng)對(duì)象被申請(qǐng)時(shí),他們被放在一個(gè)新生區(qū)中稱為Keep Area的地方,在GC時(shí),Keep Area不會(huì)被考慮而其它仍然存活的對(duì)象會(huì)被馬上移到老生區(qū)。因此,新生區(qū)的大小是JRockit很重要的參數(shù)。JRockit在第二次新生代GC時(shí)就會(huì)拷貝那些對(duì)象到Old區(qū)。
JRockit的“連續(xù)Heap”不區(qū)分“新”和“老”的對(duì)象,常常在特定的情況下比如以大吞吐量下的批量任務(wù)會(huì)產(chǎn)生很好的性能,它是JRockit Server JVM模式下的默認(rèn)設(shè)置,而且往往不是正確的選擇,因?yàn)榈湫偷?/span>Web應(yīng)用不是面向吞吐量而是面向響應(yīng)時(shí)間,因此人們往往會(huì)選擇低停頓時(shí)間模式和分代GC策略。
3) CMS -
大部分的CMS標(biāo)記階段可分為4個(gè)部分
1. 初始標(biāo)記 -標(biāo)記生成Live對(duì)象的Root集合 - Java Thread會(huì)被paused
2 并發(fā)標(biāo)記 -根據(jù)root集合中的對(duì)象查找并標(biāo)記其引用的Live對(duì)象 -- Java Thread正常運(yùn)行
3 預(yù)清理 -找出“并發(fā)標(biāo)記”發(fā)現(xiàn)的需要修改的地方并發(fā)現(xiàn)和標(biāo)記其它額外的Live對(duì)象-- Java Thread正常運(yùn)行
4 最終標(biāo)記-找出在預(yù)清理階段發(fā)現(xiàn)的需要改變的地方并發(fā)現(xiàn)和標(biāo)記其它額外的Live對(duì)象 -- Java Thread會(huì)被Paused
CMS 打掃階段也和 Application并發(fā)執(zhí)行, 但和Hotspot JVM的分2個(gè)階段相比,JRockit會(huì)先清掃Heap的第一半部分,在此階段,線程會(huì)被允許在Heap的第二半部分進(jìn)行對(duì)象申請(qǐng)。在一個(gè)短暫的同步停頓后,會(huì)打掃第二半部分然后會(huì)有一個(gè)短暫的最后的停頓期。
因此,JRockit的算法比HotSpot的算法停頓更多,但是標(biāo)記階段會(huì)短一些。而且它不像HotSpot JVM那樣可以通過調(diào)整未用內(nèi)存的百分比來觸發(fā)GC。
4) 壓縮
JRockit 在所有的Old老生區(qū)GC進(jìn)行壓縮,包括CMS。它通過一種按Heap中分區(qū)增量的模式進(jìn)行的,這些各類參數(shù)可以調(diào)整,比如按堆百分比壓縮,或最大多少對(duì)象會(huì)被壓縮,而且你可以完全把壓縮關(guān)掉或者在GC時(shí)進(jìn)行“完全壓縮”。因此可配置性比HotSpot更強(qiáng)。
5) 線程本地分配TLA(Thread Local Allocation)
JRockit默認(rèn)使用線程本地分配TLA,這允許線程不需要同步即可分配對(duì)象,這將有利于分配速度,TLA的大小而且可以配置,大的TLA可以優(yōu)化使用大量線程本地分配對(duì)象的應(yīng)用,另一方面,太大的TLA會(huì)導(dǎo)致更多的碎片,因?yàn)?/span>TLA是被線程以排斥的方式獨(dú)有的,因此受限于線程數(shù)并依賴于應(yīng)用的架構(gòu)。
6) 大對(duì)象和小對(duì)象
JRockit在分配大對(duì)象和小對(duì)象時(shí)區(qū)別對(duì)待,大小的定義在JVM的版本不同而不同,常常2-128Kb之間,大對(duì)象在線程本地意外的Old區(qū)分配,而新生Yong區(qū)使用“拷貝收集-Copy Collection (見Hotspot Yong區(qū)GC)”,在某些點(diǎn),拷貝一個(gè)對(duì)象變得比它被GC更消耗。
7) 沒有永久區(qū) -- JRockit JVM沒有永久區(qū), 所有類的屬性和字符串常量放在通常的Heap區(qū)域,因此如果它不再被使用,會(huì)被馬上回收。
IBM JVM
IBM JVM 被IBMWebsphere使用,它和JRockit有很多相同地方,它默認(rèn)的使用一個(gè)“連續(xù)的Heap”,特別是在Websphere安裝過程中,這往往是導(dǎo)致最初的低性能的原因。它和JRockit一樣區(qū)分大小對(duì)象,并默認(rèn)使用線程本地分配TLA,它也沒有“永久區(qū)”,但是IBM JVM也支持分代模型并且看起來更像HotSpot JVM,比如它的分代模型包括“新生區(qū)”和“老生區(qū)”,新生區(qū)又分為“分配區(qū)(Allocate)”和“Survior區(qū)”,新對(duì)象在Allocate區(qū)分配并在GC時(shí)拷貝到Survior區(qū),這意味著一個(gè)對(duì)象在被移動(dòng)到Old區(qū)時(shí)會(huì)被在2個(gè)區(qū)之間多次拷貝.和JRockit一樣,IBM JVM有多個(gè)選項(xiàng)可以配置“壓縮”階段,可以配置為“關(guān)閉”或“每次GC都進(jìn)行壓縮”,和JRockit相比,默認(rèn)的觸發(fā)條件是由于一系列的觸發(fā)而不是導(dǎo)致“完全”壓縮,而且這個(gè)可以被配置選項(xiàng)更改。
Java 7會(huì)宣稱“G1” - Production Ready,而且G1是不同的。