part 5
本comment希望能系統(tǒng)的探索一下GC發(fā)生的時(shí)機(jī)攀芯，以及各個(gè)GC的具體工作內(nèi)容（流程）吨艇，GC包括Minor GC和Major GC榛丢，下面將分別看看Minor GC和Major GC會(huì)在什么時(shí)候執(zhí)行顾瞪、怎么執(zhí)行的，也就是希望能了解觸發(fā)GC的條件和GC原理白胀。
已經(jīng)在前面的內(nèi)容中說(shuō)過(guò)JVM是如何支持GC工作的，簡(jiǎn)單來(lái)說(shuō)就是在create_vm的時(shí)候創(chuàng)建一個(gè)VMThread抚岗，VMThread有一個(gè)任務(wù)隊(duì)列或杠，VMThread會(huì)等待任務(wù)隊(duì)列里面存儲(chǔ)任務(wù)然后拿出來(lái)執(zhí)行，當(dāng)任務(wù)隊(duì)列中已經(jīng)沒(méi)有可以執(zhí)行的任務(wù)的時(shí)候就wait宣蔚，直到被其他的線程notify向抢，然后接著處理任務(wù)；任務(wù)隊(duì)列里面存儲(chǔ)著VMOperationQueue類(lèi)型的任務(wù)胚委，有很多類(lèi)型的VMOperationQueue挟鸠，VM_GC_Operation代表的就是GC操作，所以主要來(lái)關(guān)注VM_GC_Operation篷扩，VM_GC_Operation也有很多子類(lèi)兄猩，下面的圖片展示了VM_GC_Operation的子類(lèi)情況：
其中VM_CollectForAllocation表示內(nèi)存申請(qǐng)失敗，它有三個(gè)子類(lèi)鉴未，分別是VM_GenCollectForAllocation枢冤、VM_ParallelGCFailedAllocation、VM_G1OperationWithAllocRequest铜秆；帶Full字符的Operation代表是一次FullGC淹真，有VM_GenCollectFull、VM_G1CollectFull连茧；VM_ParallelGCSystemGC雖然不帶Full核蘸，但是也是FullGC操作巍糯；下面來(lái)看看觸發(fā)這些VM_GC_Operation的時(shí)機(jī)到底是什么時(shí)候。
VM_GenCollectForAllocation
可以在collectorPolicy.cpp的mem_allocate_work函數(shù)里面發(fā)現(xiàn)除了了一個(gè)VM_GenCollectForAllocation客扎；mem_allocate_work函數(shù)用于申請(qǐng)內(nèi)存空間祟峦，前面的文章也分析過(guò)這個(gè)函數(shù)，簡(jiǎn)單來(lái)說(shuō)徙鱼，這個(gè)函數(shù)將首先在YoungGen里面申請(qǐng)內(nèi)存宅楞，如果無(wú)法得到滿足，那么就去OldGen試試袱吆，如果OldGen也不可以滿足話厌衙，那么就去嘗試擴(kuò)展堆之后再試試，如果還是不行绞绒，那就只能觸發(fā)一個(gè)VM_GenCollectForAllocation了婶希；
VMThread::execute函數(shù)會(huì)將這個(gè)VM_GenCollectForAllocation放到VMThread的任務(wù)隊(duì)列里面去，VMThread就會(huì)執(zhí)行這個(gè)VM_GenCollectForAllocation的doit函數(shù)蓬衡，下面來(lái)看看VM_GenCollectForAllocation的doit函數(shù)的具體實(shí)現(xiàn)：
void VM_GenCollectForAllocation::doit() {
SvcGCMarker sgcm(SvcGCMarker::MINOR);
GenCollectedHeap* gch = GenCollectedHeap::heap();
GCCauseSetter gccs(gch, _gc_cause);
_result = gch->satisfy_failed_allocation(_word_size, _tlab);
assert(gch->is_in_reserved_or_null(_result), "result not in heap");
if (_result == NULL && GCLocker::is_active_and_needs_gc()) {
set_gc_locked();
}
}
satisfy_failed_allocation函數(shù)前面的文章也已經(jīng)說(shuō)過(guò)了喻杈，再總結(jié)一下這個(gè)函數(shù)的具體工作；
- （1）撤蟆、首先判斷是有其他的線程觸發(fā)了GC奕塑，如果是的話，那么本次GC就不能繼續(xù)了家肯，但是退出前試試能不能擴(kuò)展堆龄砰，如果可以的話說(shuō)不定就可以在擴(kuò)展堆之后成功申請(qǐng)到需要的空間了，如果這個(gè)時(shí)候不能擴(kuò)展堆的話讨衣，那么就只能退出等其他的線程GC完成了换棚；
- （2）、判斷是否可以增量進(jìn)行GC反镇，如果可以的話固蚤，那么就執(zhí)行一次Minor GC，否則執(zhí)行一次不回收soft reference的Full GC歹茶；如果這次GC之后可以成功申請(qǐng)到內(nèi)存了
- （3）夕玩、如果（2）結(jié)束之后還是無(wú)法申請(qǐng)到足夠的內(nèi)存，那么就要進(jìn)行一次徹底的FullGC惊豺，這次GC將要把soft reference都清理掉燎孟；
總結(jié)一下，VM_GenCollectForAllocation會(huì)在內(nèi)存申請(qǐng)失敗的時(shí)候進(jìn)行工作尸昧，它可能觸發(fā)Minor GC和FullGC揩页，首先是Minor GC，如果Minor GC并不奏效烹俗，那么就要進(jìn)行FullGC爆侣；
VM_ParallelGCFailedAllocation
VM_GenCollectForAllocation工作在DefNew萍程，是SerialGC的年輕代；VM_ParallelGCFailedAllocation工作在ParallelScavengeHeap兔仰，ParallelScavengeHeap是UseParallelGC和UseParallelOldGC的年輕代茫负，屬于"吞吐量"GC，該類(lèi)型的GC注重的是系統(tǒng)的吞吐量乎赴，和CMS注重"響應(yīng)時(shí)間"不同朽褪，"吞吐量"類(lèi)型GC可以設(shè)定用于GC的時(shí)間，JVM會(huì)自動(dòng)調(diào)整堆來(lái)滿足要求无虚；
可以在parallelScavengeHeap的mem_allocate函數(shù)里面看到觸發(fā)了VM_ParallelGCFailedAllocation操作；
mem_allocate函數(shù)先從YounYoungGen申請(qǐng)內(nèi)存衍锚，如果無(wú)法得到滿足友题，那么就去OldGen去申請(qǐng)內(nèi)存；如果還是無(wú)法滿足要求戴质，那么就觸發(fā)一個(gè)
VM_GenCollectForAllocation操作度宦，來(lái)看看VM_GenCollectForAllocation的doit函數(shù)的實(shí)現(xiàn)；
void VM_ParallelGCFailedAllocation::doit() {
SvcGCMarker sgcm(SvcGCMarker::MINOR);
ParallelScavengeHeap* heap = ParallelScavengeHeap::heap();
GCCauseSetter gccs(heap, _gc_cause);
_result = heap->failed_mem_allocate(_word_size);
if (_result == NULL && GCLocker::is_active_and_needs_gc()) {
set_gc_locked();
}
}
ParallelScavengeHeap::failed_mem_allocate函數(shù)將會(huì)處理接下來(lái)的工作告匠，下面來(lái)分析一下ParallelScavengeHeap::failed_mem_allocate這個(gè)函數(shù)的具體實(shí)現(xiàn)細(xì)節(jié)戈抄；
// Failed allocation policy. Must be called from the VM thread, and
// only at a safepoint! Note that this method has policy for allocation
// flow, and NOT collection policy. So we do not check for gc collection
// time over limit here, that is the responsibility of the heap specific
// collection methods. This method decides where to attempt allocations,
// and when to attempt collections, but no collection specific policy.
HeapWord* ParallelScavengeHeap::failed_mem_allocate(size_t size) {
assert(SafepointSynchronize::is_at_safepoint(), "should be at safepoint");
assert(Thread::current() == (Thread*)VMThread::vm_thread(), "should be in vm thread");
assert(!is_gc_active(), "not reentrant");
assert(!Heap_lock->owned_by_self(), "this thread should not own the Heap_lock");
// We assume that allocation in eden will fail unless we collect.
// First level allocation failure, scavenge and allocate in young gen.
GCCauseSetter gccs(this, GCCause::_allocation_failure);
const bool invoked_full_gc = PSScavenge::invoke();
HeapWord* result = young_gen()->allocate(size);
// Second level allocation failure.
// Mark sweep and allocate in young generation.
if (result == NULL && !invoked_full_gc) {
do_full_collection(false);
result = young_gen()->allocate(size);
}
death_march_check(result, size);
// Third level allocation failure.
// After mark sweep and young generation allocation failure,
// allocate in old generation.
if (result == NULL) {
result = old_gen()->allocate(size);
}
// Fourth level allocation failure. We're running out of memory.
// More complete mark sweep and allocate in young generation.
if (result == NULL) {
do_full_collection(true);
result = young_gen()->allocate(size);
}
// Fifth level allocation failure.
// After more complete mark sweep, allocate in old generation.
if (result == NULL) {
result = old_gen()->allocate(size);
}
return result;
}
這個(gè)函數(shù)分下面幾個(gè)步驟來(lái)處理Allocation Fail；
- （1）后专、用PSScavenge::invoke()去做"scavenge"的工作划鸽，可能是一次Minor GC，也可能是FullGC戚哎，如果觸發(fā)了一次FullGC裸诽，那么該函數(shù)就會(huì)返回true，否則返回false型凳；完成之后丈冬，嘗試從新生代從新申請(qǐng)空間，如果不能成功甘畅，則進(jìn)行第（2）步埂蕊；
- （2）、如果PSScavenge::invoke()做的是一次Minor GC疏唾，那么此時(shí)就要做一次FullGC蓄氧，但是先不回收soft reference；結(jié)束之后重新嘗試去新生代申請(qǐng)空間荸实，如果不能滿足匀们，那么繼續(xù)第（3）步；
- （3）准给、既然新生代無(wú)法申請(qǐng)到空間泄朴，那去老年代試試吧重抖，如果在老年代成功申請(qǐng)到了空間，那么就結(jié)束祖灰，否則繼續(xù)第（4）步钟沛；
- （4）、在一次FullGC之后局扶，從新生代和老年代均無(wú)法獲取到空間恨统，那么就只能把soft reference清理一下了，也就是做一次清理soft reference的FullGC三妈；之后再?lài)L試從新生代申請(qǐng)空間畜埋，如果還是無(wú)法滿足，那么執(zhí)行第（5）步畴蒲；
- （5）悠鞍、第（4）步還是無(wú)法申請(qǐng)成功的話，那么就嘗試去老年代試試模燥，如果還不行咖祭，那就交給上層處理吧（oom）
來(lái)看看PSScavenge::invoke()的具體實(shí)現(xiàn)細(xì)節(jié)；
PSScavenge::invoke_no_policy()首先將被調(diào)用進(jìn)行一次MinorGC蔫骂，在MinorGC的過(guò)程中可能有一些對(duì)象達(dá)到了晉升閾值么翰，但是可能老年代因?yàn)榭臻g不夠的問(wèn)題無(wú)法將所有晉升的對(duì)象都放到老年代，這個(gè)時(shí)候就發(fā)生了Promotion Fail辽旋；因?yàn)镾cavenge GC的一個(gè)特點(diǎn)是可以自動(dòng)調(diào)整各個(gè)分代的大小以滿足設(shè)定的參數(shù)浩嫌，這個(gè)過(guò)程較為復(fù)雜，可以在PSScavenge::invoke_no_policy()里面找到這些代碼戴已；Minor GC的過(guò)程大概和DefNew是一樣的固该，但是和DefNew不一樣的地方就是ParallelScavengeHeap使用了多線程來(lái)做GC，所以代碼要復(fù)雜很多糖儡，但是流程還是那樣伐坏，首先標(biāo)記GCRoot，然后根據(jù)GCRoot去遍歷存活對(duì)象握联，之后標(biāo)記-清除桦沉；
接著回到PSScavenge::invoke()，need_full_gc用于判斷是否需要進(jìn)行FullGC金闽，剛才已經(jīng)試圖去做一些MinorGC了纯露，但是MinorGC可能根本沒(méi)有執(zhí)行，如果當(dāng)前線程發(fā)現(xiàn)已經(jīng)有其他線程在做GC了代芜，那么就會(huì)直接退出埠褪；need_full_gc的判斷由兩部分組成，首先是PSScavenge::invoke_no_policy()的結(jié)果，也就是PSScavenge::invoke_no_policy()是否真的執(zhí)行了MinorGC钞速，如果沒(méi)有執(zhí)行贷掖，那么就有必要執(zhí)行一次FullGC；如果PSScavenge::invoke_no_policy()成功執(zhí)行了渴语，那么就看policy->should_full_GC苹威，這個(gè)policy是PSAdaptiveSizePolicy；下面來(lái)看看這個(gè)函數(shù)的判斷：
// If the remaining free space in the old generation is less that
// that expected to be needed by the next collection, do a full
// collection now.
bool PSAdaptiveSizePolicy::should_full_GC(size_t old_free_in_bytes) {
// A similar test is done in the scavenge's should_attempt_scavenge(). If
// this is changed, decide if that test should also be changed.
bool result = padded_average_promoted_in_bytes() > (float) old_free_in_bytes;
log_trace(gc, ergo)("%s after scavenge average_promoted " SIZE_FORMAT " padded_average_promoted " SIZE_FORMAT " free in old gen " SIZE_FORMAT,
result ? "Full" : "No full",
(size_t) average_promoted_in_bytes(),
(size_t) padded_average_promoted_in_bytes(),
old_free_in_bytes);
return result;
}
判斷條件很簡(jiǎn)單驾凶，如果發(fā)現(xiàn)YoungGen里面等待晉升到OldGen的對(duì)象大小大于oldGen的空閑空間牙甫，那么就有必要執(zhí)行FullGC了；接著看進(jìn)行FullGC的代碼调违，UseParallelOldGC用于判斷老年代使用的堆類(lèi)型窟哺，如果我們?cè)贘VM啟動(dòng)的時(shí)候使用了-XX:+UseParallelOldGC，那么新生代和老年代的組合就是（Parallel Scavenge + Parallel Old）技肩，如果使用的是-XX:+UseParallelGC脏答，那么新生代和老年代的組合就是（Parallel Scavenge + Serial Old）；這里假設(shè)使用了-XX:+UseParallelGC亩鬼，那么就看PSMarkSweep::invoke_no_policy(clear_all_softrefs)；而Serial Old的GC過(guò)程前面的文章已經(jīng)分析過(guò)就不繼續(xù)了阿蝶。
現(xiàn)在回到ParallelScavengeHeap::failed_mem_allocate函數(shù)雳锋，看看剩下的部分；PSScavenge::invoke()執(zhí)行過(guò)后羡洁，可能進(jìn)行了一次MinorGC玷过，或者是FullGC，可能將soft reference清理掉了筑煮，但是總得來(lái)說(shuō)執(zhí)行了PSScavenge::invoke()之后已經(jīng)清理了一波垃圾了辛蚊，young_gen()->allocate(size)試圖從新生代申請(qǐng)空間；如果申請(qǐng)失敗真仲，那么就看剛才是否做了FullGC袋马，如果做了，那么就只能oom了秸应，否則通過(guò)do_full_collection(false)做一次FullGC虑凛，但是soft reference依然還在；接著分別從young 和 old去申請(qǐng)空間软啼，如果還是無(wú)法滿足要求桑谍，那么就通過(guò)do_full_collection(true)來(lái)做一次清理FullGC，并且將soft reference清理掉祸挪，然后再?gòu)膟oung 和 old中去試圖申請(qǐng)內(nèi)存锣披，如果還是無(wú)法申請(qǐng)成功，那么就交給上層處理吧。（OOM）
VM_G1OperationWithAllocRequest
VM_G1OperationWithAllocRequest有兩個(gè)子類(lèi)：VM_G1CollectForAllocation和VM_G1IncCollectionPause雹仿，屬于G1的內(nèi)容增热，暫時(shí)不做分析，后續(xù)專(zhuān)門(mén)分析G1的相關(guān)實(shí)現(xiàn)細(xì)節(jié)盅粪；
VM_GenCollectFull
VM_GenCollectFull用于支持一些外部的GC命令钓葫，比如System.gc()，可以在GenCollectedHeap::collect_locked函數(shù)里面發(fā)現(xiàn)VM_GenCollectFull操作：
void GenCollectedHeap::collect_locked(GCCause::Cause cause, GenerationType max_generation) {
// Read the GC count while holding the Heap_lock
unsigned int gc_count_before = total_collections();
unsigned int full_gc_count_before = total_full_collections();
{
MutexUnlocker mu(Heap_lock); // give up heap lock, execute gets it back
VM_GenCollectFull op(gc_count_before, full_gc_count_before,
cause, max_generation);
VMThread::execute(&op);
}
}
genCollectedHeap::collect函數(shù)是該操作發(fā)生的一個(gè)起點(diǎn)票顾，而genCollectedHeap::collect是為了響應(yīng)類(lèi)似于System.gc()調(diào)用础浮，比如：
JVM_ENTRY_NO_ENV(void, JVM_GC(void))
JVMWrapper("JVM_GC");
if (!DisableExplicitGC) {
Universe::heap()->collect(GCCause::_java_lang_system_gc);
}
JVM_END
這就是一個(gè)System.gc()的請(qǐng)求，而調(diào)用的就是Universe::heap()->collect函數(shù)奠骄，Universe::heap()返回的是JVM的一個(gè)高層堆管理器豆同，目前JVM里面有三個(gè)這樣的堆管理器，分別是GenCollectedHeap含鳞、ParallelScavengeHeap和G1CollectedHeap影锈，分別對(duì)應(yīng)不同種類(lèi)型的GC；GenCollectedHeap對(duì)應(yīng)-XX:+UseSerialGC和-XX:+UseConcMarkSweepGC蝉绷；ParallelScavengeHeap對(duì)應(yīng)-XX:+UseParallelGC和-XX:+UseParallelOldGC以及-XX:+UseParNewGC鸭廷；G1CollectedHeap對(duì)應(yīng)-XX:+UseG1GC；這些對(duì)應(yīng)關(guān)系是在create_vm的時(shí)候創(chuàng)建的熔吗，關(guān)于堆初始化這部分內(nèi)容將在后續(xù)的文章中分析辆床。
和VM_GenCollectFull類(lèi)似的還有VM_G1IncCollectionPause（G1）、VM_ParallelGCSystemGC（ParallelGC）桅狠；這里就不分析這兩個(gè)Operation了讼载。
結(jié)論
Minor GC發(fā)生的原因較為簡(jiǎn)單，就是"Allocation Fail"中跌；發(fā)生"Allocation Fail"的原因就是沒(méi)有足夠的內(nèi)存了咨堤，這個(gè)時(shí)候就要去做Minor GC，但是漩符，內(nèi)存不足之后不一定進(jìn)行Minor GC一喘，可能因?yàn)槟承┰蛑苯舆M(jìn)行了FullGC，在JVM里面有大量的用于判斷是否應(yīng)該在某個(gè)分代進(jìn)行垃圾收集的函數(shù)嗜暴，這些函數(shù)將根據(jù)一些統(tǒng)計(jì)數(shù)據(jù)來(lái)判斷是否應(yīng)該在該區(qū)域進(jìn)行垃圾收集津滞；比如在某次Eden區(qū)域分配失敗的時(shí)候，Old區(qū)域就需要判斷是否允許Young區(qū)進(jìn)行一次Minor GC灼伤，因?yàn)檫M(jìn)行MinorGC的時(shí)候一些符合晉升年齡的對(duì)象將會(huì)晉升到老年代中來(lái)触徐，還有一部分對(duì)象因?yàn)闊o(wú)法移動(dòng)到To區(qū)域（To區(qū)滿了或者連續(xù)空間小于存活對(duì)象大小）也需要提前拷貝到老年代狐赡，這些對(duì)象轉(zhuǎn)移到老年代對(duì)老年代來(lái)說(shuō)是一種負(fù)擔(dān)撞鹉，并且也是有風(fēng)險(xiǎn)的，比如可能老年代根本沒(méi)有足夠的內(nèi)存容納這次Minor GC之后晉升的對(duì)象，這個(gè)時(shí)候MinorGC就要報(bào)"Promotion Fail"鸟雏，這就需要開(kāi)啟一次FullGC來(lái)回收掉一些不再使用的對(duì)象享郊，也可能包括正在使用的soft reference；還有一些發(fā)生FullGC的條件（或者說(shuō)是觸發(fā)FullGC）本文沒(méi)有分析到孝鹊，主要原因是關(guān)于G1和CMS還不太了解炊琉，CMS和G1是相對(duì)復(fù)雜的GC，需要花費(fèi)大量的時(shí)間去研究分析以及描述出來(lái)又活。
發(fā)生GC有兩種原因苔咪，主動(dòng)進(jìn)行GC和被動(dòng)進(jìn)行GC，被動(dòng)GC就是類(lèi)似于System.gc()柳骄，主動(dòng)GC發(fā)生在allocate的時(shí)候团赏，如果可以，應(yīng)該盡量避免讓GC被動(dòng)GC耐薯，因?yàn)檫@會(huì)打亂JVM的GC計(jì)劃舔清，應(yīng)該相信JVM可以做得足夠好，讓我們不需要擔(dān)心GC的問(wèn)題曲初，這也是Java相比于類(lèi)似于C/C++的主要優(yōu)勢(shì)之一体谒。
