对于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 GetXXXCriticalOperation)}
(2).检查是否需要回收所有的软引用。
constbooldo_clear_all_soft_refs = clear_all_soft_refs ||collector_policy()->should_clear_all_soft_refs();
(3).记录永久代已经使用的内存空间大小。
constsize_t perm_PRev_used = perm_gen()->used();
(4).确定回收类型是否是FullGC以及gc触发类型(GC/Full GC(system)/Full GC，用作Log输出)。
boolcomplete = full && (max_level == (n_gens()-1));constchar* 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的垃圾回收则是对老年代和更低的内存代都进行回收。
intstarting_level =0;if(full) {//Search for the oldest generation which will collect all younger//generations, and start collection loop there.for(inti = 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计数值。
intmax_level_collected =starting_level;for(inti = 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 happenif(!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 verificationif(!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 <classT>boolenqueue_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();returnold_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，表示该列表为空。
voidReferenceProcessor::enqueue_discovered_reflists(HeapWord*pending_list_addr,
AbstractRefProcTaskExecutor*task_executor) {if(_processing_is_mt && task_executor !=NULL) {//Parallel codeRefProcEnqueueTask tsk(*this, _discoveredSoftRefs,
pending_list_addr, sentinel_ref(), _max_num_q);
task_executor->execute(tsk);
}else{//Serial code: call the parent class's implementationfor(inti =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" collectionpost_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(intj = 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 collectionsperm()->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的内存代实现无关的流程图如下：