對于HotSpot虛擬機垃圾回收過程，這里將分析介紹默認配置下MarkSweepPolicy的DefNewGeneration和TenuredGeneration的垃圾回收內容以及介紹其他GC策略和代實現的GC思想。GC的過程姑且簡單地分為內存代實現無關的GC過程和內存代GC過程。
本文將先進行內存代實現無關的GC過程分析，內存代GC過程將在后面進行分析。
從GenCollectedHeap的do_collection()說起：
1.在GC之前有許多必要的檢查和統計任務，比如對回收內存代的統計、堆內存大小的統計等，注意本節內容將不再去分析一些性能統計的內容，有興趣的可自行分析。
(1).檢查是否已經GC鎖是否已經激活，并設置需要進行GC的標志為true，這時，通過is_active_and_needs_gc()就可以判斷是否已經有線程觸發了GC。
if (GC_locker::check_active_before_gc()) { return; // GC is disabled (e.g. JNI GetXXXCritical Operation) }
(2).檢查是否需要回收所有的軟引用。
const bool do_clear_all_soft_refs = clear_all_soft_refs || collector_policy()->should_clear_all_soft_refs();
(3).記錄永久代已經使用的內存空間大小。
const size_t perm_PRev_used = perm_gen()->used();
(4).確定回收類型是否是FullGC以及gc觸發類型(GC/Full GC(system)/Full GC，用作Log輸出)。
bool complete = full && (max_level == (n_gens()-1)); const char* gc_cause_str = "GC "; if (complete) { GCCause::Cause cause = gc_cause(); if (cause == GCCause::_java_lang_system_gc) { gc_cause_str = "Full GC (System) "; } else { gc_cause_str = "Full GC "; } }
(5).gc計數加1操作(包括總GC計數和FullGC計數)。
increment_total_collections(complete);
(6).統計堆已被使用的空間大小。
size_t gch_prev_used = used();
(7).如果是FullGC，那么從最高的內存代到最低的內存代，若某個內存代不希望對比其更低的內存代進行單獨回收，那么就以該內存代作為GC的起始內存代。這里說明下什么是單獨回收。新生代比如DefNewGeneration的實現將對新生代使用復制算法進行垃圾回收，而老年代TenuredGeneration的垃圾回收則會使用其標記-壓縮-清理算法對新生代也進行處理。所以可以說DefNewGeneration的垃圾回收是對新生代進行單獨回收，而TenuredGeneration的垃圾回收則是對老年代和更低的內存代都進行回收。
int starting_level = 0; if (full) { // Search for the oldest generation which will collect all younger // generations, and start collection loop there. for (int i = max_level; i >= 0; i--) { if (_gens[i]->full_collects_younger_generations()) { starting_level = i; break; } } }
2.接下來從GC的起始內存代開始，向最老的內存代進行回收 。
(1).其中should_collect()將根據該內存代GC條件返回是否應該對該內存代進行GC。若當前回收的內存代是最老的內存代，如果本次gc不是FullGC，將調用increment_total_full_collections()修正之前的FulllGC計數值。
int max_level_collected = starting_level; for (int i = starting_level; i <= max_level; i++) { if (_gens[i]->should_collect(full, size, is_tlab)) { if (i == n_gens() - 1) { // a major collection is to happen if (!complete) { // The full_collections increment was missed above. increment_total_full_collections(); }
(2).統計GC前該內存代使用空間大小以及其他記錄工作 。
(3).驗證工作 。
先調用prepare_for_verify()使各內存代進行驗證的準備工作(正常情況下什么都不需要做)，隨后調用Universe的verify()進行GC前驗證
if (VerifyBeforeGC && i >= VerifyGCLevel && total_collections() >= VerifyGCStartAt) { HandleMark hm; // Discard invalid handles created during verification if (!prepared_for_verification) { prepare_for_verify(); prepared_for_verification = true; } gclog_or_tty->print(" VerifyBeforeGC:"); Universe::verify(true); }
線程、堆(各內存代)、符號表、字符串表、代碼緩沖、系統字典等，如對堆的驗證將對堆內的每個oop對象的類型Klass進行驗證，驗證對象是否是oop，類型klass是否在永久代，oop的klass域是否是klass 。那么為什么在這里進行GC驗證？GC前驗證和GC后驗證又分別有什么作用？ VerifyBeforeGC和VerifyAfterGC都需要和UnlockDiagnosticVMOptions配合使用以用來診斷JVM問題，但是驗證過程非常耗時，所以在正常的編譯版本中并沒有將驗證內容進行輸出。
(4).保存內存代各區域的碰撞指針到該區域的_save_mark_Word變量。
save_marks();
(5).初始化引用處理器。
ReferenceProcessor* rp = _gens[i]->ref_processor();if (rp->discovery_is_atomic()) { rp->verify_no_references_recorded(); rp->enable_discovery(); rp->setup_policy(do_clear_all_soft_refs); } else { // collect() below will enable discovery as appropriate }
(6).由各內存代完成gc
_gens[i]->collect(full, do_clear_all_soft_refs, size, is_tlab);
(7).將不可觸及的引用對象加入到Reference的pending鏈表
if (!rp->enqueuing_is_done()) { rp->enqueue_discovered_references(); } else { rp->set_enqueuing_is_done(false); } rp->verify_no_references_recorded(); }
其中enqueue_discovered_references根據是否使用壓縮指針選擇不同的enqueue_discovered_ref_helper()模板函數 ，enqueue_discovered_ref_helper()實現如下：
template <class T>bool enqueue_discovered_ref_helper(ReferenceProcessor* ref, AbstractRefProcTaskExecutor* task_executor) { T* pending_list_addr = (T*)java_lang_ref_Reference::pending_list_addr(); T old_pending_list_value = *pending_list_addr; ref->enqueue_discovered_reflists((HeapWord*)pending_list_addr, task_executor); oop_store(pending_list_addr, oopDesc::load_decode_heap_oop(pending_list_addr)); ref->disable_discovery(); return old_pending_list_value != *pending_list_addr;}
pending_list_addr是Reference的私有靜態(類)成員pending鏈表的首元素的地址，gc階段當引用對象的可達狀態變化時，會將引用加入到pending鏈表中，而Reference的私有靜態(類)成員ReferenceHandler將不斷地從pending鏈表中取出引用加入ReferenceQueue。
enqueue_discovered_reflists()根據是否使用多線程有著不同的處理方式，若采用多線程則會創建一個RefProcEnqueueTask交由AbstractRefProcTaskExecutor進行處理，這里我們分析單線程的串行處理情況：
這里，DiscoveredList數組_discoveredSoftRefs保存了最多_max_num_q*subclasses_of_ref個軟引用的鏈表。在將引用鏈表處理后會將引用鏈表的起始引用置為哨兵引用，并設置引用鏈長度為0，表示該列表為空。
void ReferenceProcessor::enqueue_discovered_reflists(HeapWord* pending_list_addr, AbstractRefProcTaskExecutor* task_executor) { if (_processing_is_mt && task_executor != NULL) { // Parallel code RefProcEnqueueTask tsk(*this, _discoveredSoftRefs, pending_list_addr, sentinel_ref(), _max_num_q); task_executor->execute(tsk); } else { // Serial code: call the parent class's implementation for (int i = 0; i < _max_num_q * subclasses_of_ref; i++) { enqueue_discovered_reflist(_discoveredSoftRefs[i], pending_list_addr); _discoveredSoftRefs[i].set_head(sentinel_ref()); _discoveredSoftRefs[i].set_length(0); } }}
enqueue_discovered_reflist()如下：
取出refs_list鏈上的首元素，next為discovered域所成鏈表上的下一個元素
oop obj = refs_list.head(); while (obj != sentinel_ref()) { assert(obj->is_instanceRef(), "should be reference object"); oop next = java_lang_ref_Reference::discovered(obj);
如果next是最后的哨兵引用，那么，原子交換discovered域所成鏈表上的表尾元素與pending_list_addr的值，即將其加入到pending鏈表的表頭，接下來根據插入到表頭的鏈表的處理方式，當pending鏈表為空時，作為表尾元素其next域指向自身，否則，將其next域指向鏈表的原表頭元素，這樣就將該元素插入到pending鏈表的原表頭位置，即：
if (next == sentinel_ref()) { // obj is last // Swap refs_list into pendling_list_addr and // set obj's next to what we read from pending_list_addr. oop old = oopDesc::atomic_exchange_oop(refs_list.head(), pending_list_addr); // Need oop_check on pending_list_addr above; // see special oop-check code at the end of // enqueue_discovered_reflists() further below. if (old == NULL) { // obj should be made to point to itself, since // pending list was empty. java_lang_ref_Reference::set_next(obj, obj); } else { java_lang_ref_Reference::set_next(obj, old); }
否則若next不是最后的哨兵引用，設置引用對象的next域為next，即將從引用鏈表的表頭元素開始，將虛擬機所使用的discovered域所成鏈表轉化為Java層可使用的next域所成pending列表。
} else { java_lang_ref_Reference::set_next(obj, next); }
最后設置引用對象的discovered域為NULL，即切斷當前引用在discovered域所成鏈表中的引用關系，并繼續遍歷引用鏈
java_lang_ref_Reference::set_discovered(obj, (oop) NULL); obj = next; }
綜上所述，入隊的操作就是通過原來的discovered域進行遍歷，將引用鏈表用next域重新連接后切斷discovered域的關系并將新鏈表附在pending鏈表的表頭。
(9).回到GC完成后的處理：更新統計信息和進行GC后驗證
3.輸出一些GC的日志信息
complete = complete || (max_level_collected == n_gens() - 1); if (complete) { // We did a "major" collection post_full_gc_dump(); // do any post full gc dumps } if (PrintGCDetails) { print_heap_change(gch_prev_used); // Print perm gen info for full GC with PrintGCDetails flag. if (complete) { print_perm_heap_change(perm_prev_used); } }
4.更新各內存代的大小
for (int j = max_level_collected; j >= 0; j -= 1) { // Adjust generation sizes. _gens[j]->compute_new_size(); }
5.FullGC后更新和調整永久代內存大小
if (complete) { // Ask the permanent generation to adjust size for full collections perm()->compute_new_size(); update_full_collections_completed(); }
6.若配置了ExitAfterGCNum，則當gc次數達到用戶配置的最大GC計數時退出VM
if (ExitAfterGCNum > 0 && total_collections() == ExitAfterGCNum) { tty->print_cr("Stopping after GC #%d", ExitAfterGCNum); vm_exit(-1); }
GC的內存代實現無關的流程圖如下：
新聞熱點
疑難解答
