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