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)容中說過JVM是如何支持GC工作的，簡(jiǎn)單來說就是在create_vm的時(shí)候創(chuàng)建一個(gè)VMThread，VMThread有一個(gè)任務(wù)隊(duì)列，VMThread會(huì)等待任務(wù)隊(duì)列里面存儲(chǔ)任務(wù)然后拿出來執(zhí)行，當(dāng)任務(wù)隊(duì)列中已經(jīng)沒有可以執(zhí)行的任務(wù)的時(shí)候就wait，直到被其他的線程notify，然后接著處理任務(wù)；任務(wù)隊(duì)列里面存儲(chǔ)著VMOperationQueue類型的任務(wù)，有很多類型的VMOperationQueue，VM_GC_Operation代表的就是GC操作，所以主要來關(guān)注VM_GC_Operation，VM_GC_Operation也有很多子類，下面的圖片展示了VM_GC_Operation的子類情況：

<img width="665" alt="2018-11-12 10 30 50" src="https://user-images.githubusercontent.com/16225796/48353562-b63c7d80-e6ca-11e8-895d-56951e6eab18.png">

其中VM_CollectForAllocation表示內(nèi)存申請(qǐng)失敗，它有三個(gè)子類，分別是VM_GenCollectForAllocation、VM_ParallelGCFailedAllocation、VM_G1OperationWithAllocRequest；帶Full字符的Operation代表是一次FullGC，有VM_GenCollectFull、VM_G1CollectFull；VM_ParallelGCSystemGC雖然不帶Full，但是也是FullGC操作；下面來看看觸發(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)存空間，前面的文章也分析過這個(gè)函數(shù)，簡(jiǎn)單來說，這個(gè)函數(shù)將首先在YoungGen里面申請(qǐng)內(nèi)存，如果無法得到滿足，那么就去OldGen試試，如果OldGen也不可以滿足話，那么就去嘗試擴(kuò)展堆之后再試試，如果還是不行，那就只能觸發(fā)一個(gè)VM_GenCollectForAllocation了；

<img width="889" alt="2018-11-12 10 52 13" src="https://user-images.githubusercontent.com/16225796/48354879-bee28300-e6cd-11e8-8c4c-8947845e7a25.png">

VMThread::execute函數(shù)會(huì)將這個(gè)VM_GenCollectForAllocation放到VMThread的任務(wù)隊(duì)列里面去，VMThread就會(huì)執(zhí)行這個(gè)VM_GenCollectForAllocation的doit函數(shù)，下面來看看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)說過了，再總結(jié)一下這個(gè)函數(shù)的具體工作；

• （1）、首先判斷是有其他的線程觸發(fā)了GC，如果是的話，那么本次GC就不能繼續(xù)了，但是退出前試試能不能擴(kuò)展堆，如果可以的話說不定就可以在擴(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é)束之后還是無法申請(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，該類型的GC注重的是系統(tǒng)的吞吐量，和CMS注重"響應(yīng)時(shí)間"不同，"吞吐量"類型GC可以設(shè)定用于GC的時(shí)間，JVM會(huì)自動(dòng)調(diào)整堆來滿足要求；
可以在parallelScavengeHeap的mem_allocate函數(shù)里面看到觸發(fā)了VM_ParallelGCFailedAllocation操作；

<img width="722" alt="2018-11-12 11 22 23" src="https://user-images.githubusercontent.com/16225796/48356738-ea676c80-e6d1-11e8-8c1e-12c85888c3f2.png">

mem_allocate函數(shù)先從YounYoungGen申請(qǐng)內(nèi)存，如果無法得到滿足，那么就去OldGen去申請(qǐng)內(nèi)存；如果還是無法滿足要求，那么就觸發(fā)一個(gè)
VM_GenCollectForAllocation操作，來看看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ì)處理接下來的工作，下面來分析一下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è)步驟來處理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）、既然新生代無法申請(qǐng)到空間，那去老年代試試吧，如果在老年代成功申請(qǐng)到了空間，那么就結(jié)束，否則繼續(xù)第（4）步；
• （4）、在一次FullGC之后，從新生代和老年代均無法獲取到空間，那么就只能把soft reference清理一下了，也就是做一次清理soft reference的FullGC；之后再嘗試從新生代申請(qǐng)空間，如果還是無法滿足，那么執(zhí)行第（5）步；
• （5）、第（4）步還是無法申請(qǐng)成功的話，那么就嘗試去老年代試試，如果還不行，那就交給上層處理吧（oom）

來看看PSScavenge::invoke()的具體實(shí)現(xiàn)細(xì)節(jié)；

<img width="862" alt="2018-11-13 4 11 37" src="https://user-images.githubusercontent.com/16225796/48399751-78d5ff80-e75f-11e8-900f-00de9be35be6.png">

PSScavenge::invoke_no_policy()首先將被調(diào)用進(jìn)行一次MinorGC，在MinorGC的過程中可能有一些對(duì)象達(dá)到了晉升閾值，但是可能老年代因?yàn)榭臻g不夠的問題無法將所有晉升的對(duì)象都放到老年代，這個(gè)時(shí)候就發(fā)生了Promotion Fail；因?yàn)镾cavenge GC的一個(gè)特點(diǎn)是可以自動(dòng)調(diào)整各個(gè)分代的大小以滿足設(shè)定的參數(shù)，這個(gè)過程較為復(fù)雜，可以在PSScavenge::invoke_no_policy()里面找到這些代碼；Minor GC的過程大概和DefNew是一樣的，但是和DefNew不一樣的地方就是ParallelScavengeHeap使用了多線程來做GC，所以代碼要復(fù)雜很多，但是流程還是那樣，首先標(biāo)記GCRoot，然后根據(jù)GCRoot去遍歷存活對(duì)象，之后標(biāo)記-清除；
接著回到PSScavenge::invoke()，need_full_gc用于判斷是否需要進(jìn)行FullGC，剛才已經(jīng)試圖去做一些MinorGC了，但是MinorGC可能根本沒有執(zhí)行，如果當(dāng)前線程發(fā)現(xiàn)已經(jīng)有其他線程在做GC了，那么就會(huì)直接退出；need_full_gc的判斷由兩部分組成，首先是PSScavenge::invoke_no_policy()的結(jié)果，也就是PSScavenge::invoke_no_policy()是否真的執(zhí)行了MinorGC，如果沒有執(zhí)行，那么就有必要執(zhí)行一次FullGC；如果PSScavenge::invoke_no_policy()成功執(zhí)行了，那么就看policy->should_full_GC，這個(gè)policy是PSAdaptiveSizePolicy；下面來看看這個(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用于判斷老年代使用的堆類型，如果我們?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過程前面的文章已經(jīng)分析過就不繼續(xù)了。

現(xiàn)在回到ParallelScavengeHeap::failed_mem_allocate函數(shù)，看看剩下的部分；PSScavenge::invoke()執(zhí)行過后，可能進(jìn)行了一次MinorGC，或者是FullGC，可能將soft reference清理掉了，但是總得來說執(zhí)行了PSScavenge::invoke()之后已經(jīng)清理了一波垃圾了，young_gen()->allocate(size)試圖從新生代申請(qǐng)空間；如果申請(qǐng)失敗，那么就看剛才是否做了FullGC，如果做了，那么就只能oom了，否則通過do_full_collection(false)做一次FullGC，但是soft reference依然還在；接著分別從young 和 old去申請(qǐng)空間，如果還是無法滿足要求，那么就通過do_full_collection(true)來做一次清理FullGC，并且將soft reference清理掉，然后再從young 和 old中去試圖申請(qǐng)內(nèi)存，如果還是無法申請(qǐng)成功，那么就交給上層處理吧。（OOM）

VM_G1OperationWithAllocRequest

VM_G1OperationWithAllocRequest有兩個(gè)子類：VM_G1CollectForAllocation和VM_G1IncCollectionPause，屬于G1的內(nèi)容，暫時(shí)不做分析，后續(xù)專門分析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)類似于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)不同種類型的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類似的還有VM_G1IncCollectionPause（G1）、VM_ParallelGCSystemGC（ParallelGC）；這里就不分析這兩個(gè)Operation了。

結(jié)論

Minor GC發(fā)生的原因較為簡(jiǎn)單，就是"Allocation Fail"；發(fā)生"Allocation Fail"的原因就是沒有足夠的內(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ù)來判斷是否應(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ì)晉升到老年代中來，還有一部分對(duì)象因?yàn)闊o法移動(dòng)到To區(qū)域（To區(qū)滿了或者連續(xù)空間小于存活對(duì)象大小）也需要提前拷貝到老年代，這些對(duì)象轉(zhuǎn)移到老年代對(duì)老年代來說是一種負(fù)擔(dān)，并且也是有風(fēng)險(xiǎn)的，比如可能老年代根本沒有足夠的內(nèi)存容納這次Minor GC之后晉升的對(duì)象，這個(gè)時(shí)候MinorGC就要報(bào)"Promotion Fail"，這就需要開啟一次FullGC來回收掉一些不再使用的對(duì)象，也可能包括正在使用的soft reference；還有一些發(fā)生FullGC的條件（或者說是觸發(fā)FullGC）本文沒有分析到，主要原因是關(guān)于G1和CMS還不太了解，CMS和G1是相對(duì)復(fù)雜的GC，需要花費(fèi)大量的時(shí)間去研究分析以及描述出來。

發(fā)生GC有兩種原因，主動(dòng)進(jìn)行GC和被動(dòng)進(jìn)行GC，被動(dòng)GC就是類似于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的問題，這也是Java相比于類似于C/C++的主要優(yōu)勢(shì)之一。