对于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的内存代实现无关的流程图如下：
新闻热点
疑难解答
