你的位置:首页 > Java教程

[Java教程]源码分析HotSpot GC过程(一)


  对于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的内存代实现无关的流程图如下: