大家都知道，當我們使用以下命令時，會打印出導致GC的原因

jstat -gccause pid 1000

    

    
    可以看到最後2列分別列出了上次GC的原因和當前GC的原因。有一個”Heap Inspection Initiated GC”是因為我呼叫了jmap -histo:live pid。那麼，今天我們就來看看，gccause顯示的都會有哪些GC原因呢？
    https://github.com/dmlloyd/openjdk/blob/jdk8u/jdk8u/hotspot/src/share/vm/gc_interface/gcCause.hpp#L39 中有一個Cause的列舉類，列舉了都有哪些cause,用於在觸發GC的時候做原因的區分。總共有27條，刪掉原始碼中沒有找到呼叫的，還剩17條。
    

enum Cause {
    /* public */
    _java_lang_system_gc,
    _full_gc_alot,
    _scavenge_alot,
    _allocation_profiler,//無
    _jvmti_force_gc,
    _gc_locker,
    _heap_inspection,
    _heap_dump,
    _wb_young_gc,
    _update_allocation_context_stats_inc,//無
    _update_allocation_context_stats_full,//無
 


    /* implementation independent, but reserved for GC use */
    _no_gc,//無
    _no_cause_specified,//無
    _allocation_failure,

    /* implementation specific */

    _tenured_generation_full,//無
    _metadata_GC_threshold,

    _cms_generation_full,//無
    _cms_initial_mark,
    _cms_final_remark,
    _cms_concurrent_mark,//background式
 


    _old_generation_expanded_on_last_scavenge,//無
    _old_generation_too_full_to_scavenge,//無
    _adaptive_size_policy,

    _g1_inc_collection_pause,
    _g1_humongous_allocation,

    _last_ditch_collection,
    _last_gc_cause//無
  };

    
    在呼叫各種GC時，需要傳入具體的引數GCCause，來表示這是一次由什麼原因觸發的GC。上面程式碼後面的註釋“無”表示沒有在具體的呼叫GC的程式碼中找到有傳入這樣的一個cause，可能在jdk8中已經去掉了。
    下面來具體寫一下每個有呼叫的cause都是什麼原因引起的。

_java_lang_system_gc

    該cause大家應該都知道，是通過程式碼顯示呼叫System.gc()觸發的。還有一種情況是，在visualvm等軟體上通過JMX監控時有點選觸發SystemGC的按鈕。

_jvmti_force_gc

    JVMTI（JVM Tool Interface）是 Java 虛擬機器所提供的 native 程式設計介面。正是由於 JVMTI 的強大功能，它是實現 Java 偵錯程式，以及其它 Java 執行態測試與分析工具的基礎。
    可以參考這篇文章https://www.ibm.com/developerworks/cn/java/j-lo-jpda2/
所以_jvmti_force_gc就是通過jvmti方式觸發的GC

_gc_locker

    當通過jni方式運算元組或者是字串的時候，為了避免GC過程移動陣列或字串的記憶體地址，jvm實現了一個GC_locker這樣的東西，用於表示有執行緒在jni臨界區內，阻止其他執行緒進行GC操作。當最後一個位於jni臨界區內的執行緒退出臨界區時，發起一次CGCause為_gc_locker的GC.

//退出臨界區後釋放該鎖，併發起一次由gclocker觸發的gc
void GC_locker::jni_unlock(JavaThread* thread) {
  assert(thread->in_last_critical(), "should be exiting critical region");
  MutexLocker mu(JNICritical_lock);
  _jni_lock_count--;
  decrement_debug_jni_lock_count();
  thread->exit_critical();
  /*
  減少計數器之後如果=0，則表示這個是最後一個退出jni的執行緒，
  則需要觸發一次有gclocker的GC
  */
  if (needs_gc() && !is_active_internal()) {

    _doing_gc = true;
    {
      // Must give up the lock while at a safepoint
      MutexUnlocker munlock(JNICritical_lock);
      if (PrintJNIGCStalls && PrintGCDetails) {
        ResourceMark rm; // JavaThread::name() allocates to convert to UTF8
        gclog_or_tty->print_cr("%.3f: Thread \"%s\" is performing GC after exiting critical section, %d locked",
            gclog_or_tty->time_stamp().seconds(), Thread::current()->name(), _jni_lock_count);
      }
      Universe::heap()->collect(GCCause::_gc_locker);
    }
    _doing_gc = false;
    _needs_gc = false;
    JNICritical_lock->notify_all();
  }
}

_heap_inspection

    這個型別主要是jamp -hisot:live命令時會觸發。或者若設定了PrintClassHistogramBeforeFullGC
或者PrintClassHistogramAfterFullGC時，則在fullgc之前或者之後也會觸發一次GCCause=_heap_inspection的GC。

_heap_dump

    看名字就知道，它用於dump堆時，比如：

jmap -dump:format=b,file=a.hprof pid

    或者設定了引數HeapDumpBeforeFullGC，HeapDumpAfterFullGC。這2個引數用於在fullgc前/後自動dump堆，便於分析fullgc前後的差異。

_wb_young_gc

_allocation_failure

    這個就是常見的記憶體分配失敗觸發的GC。比如在new 物件時。

_metadata_GC_threshold

    這個用於在metaspace區域分配時分配不下，從而觸發的GC

_cms_initial_mark，_cms_final_remark

    這2個就是對於設定的CMS回收器時，有一個background式的回收時的初始標記和最終標記階段

_cms_concurrent_mark

    表示觸發GC的是一次cms的background式GC。可以參考原始碼筆記1:如何觸發一次CMS回收中都有哪些原因會觸發background式的GC

_adaptive_size_policy

    這個在ps中動態調整堆以及各個區大小時用到。

_g1_inc_collection_pause

    這個是設定的G1回收器時，若分配不下觸發的GC的cause

_g1_humongous_allocation

    這個和上面的區別是，這個用於分配超大物件失敗時觸發GC。
    對於分配普通大小的物件和超大物件，是呼叫的不同的方法，所以也有不同的GCCause的區分。

if (!isHumongous(word_size)) {
      result = attempt_allocation(word_size, &gc_count_before, &gclocker_retry_count);
    } else {
      result = attempt_allocation_humongous(word_size, &gc_count_before, &gclocker_retry_count);
    }
    if (result != NULL) {
      return result;
    }

_last_ditch_collection

    這個也是用於在metaspace區域分配不下時，最後的一次回收。若GCCause=_metadata_GC_threshold的GC後，仍分配不下，則會最後觸發一次cause=_last_ditch_collection的回收。此次回收會清除軟引用。若GC完再分配不下，就OOM了。這也正符合了軟引用的定義：在OOM發生之前會進行回收。
    相關原始碼：

if (!MetadataAllocationFailALot) {
    _result = _loader_data->metaspace_non_null()->allocate(_size, _mdtype);
    if (_result != NULL) {
      return;
    }
  }

  if (initiate_concurrent_GC()) {
    // For CMS and G1 expand since the collection is going to be concurrent.
    _result = _loader_data->metaspace_non_null()->expand_and_allocate(_size, _mdtype);
    if (_result != NULL) {
      return;
    }

    log_metaspace_alloc_failure_for_concurrent_GC();
  }

  /
  先不清除軟引用
  */
  heap->collect_as_vm_thread(GCCause::_metadata_GC_threshold);

  _result = _loader_data->metaspace_non_null()->allocate(_size, _mdtype);
  if (_result != NULL) {
    return;
  }


  _result = _loader_data->metaspace_non_null()->expand_and_allocate(_size, _mdtype);
  if (_result != NULL) {
    return;
  }

  /* 
   如果擴容失敗，做最後一次回收，且會回收軟引用。
  */
   heap->collect_as_vm_thread(GCCause::_last_ditch_collection);
  _result = _loader_data->metaspace_non_null()->allocate(_size, _mdtype);
  if (_result != NULL) {
    return;
  }

  if (Verbose && PrintGCDetails) {
    gclog_or_tty->print_cr("\nAfter Metaspace GC failed to allocate size "
                           SIZE_FORMAT, _size);
  }

  if (GC_locker::is_active_and_needs_gc()) {
    set_gc_locked();
  }

    能找到的有觸發的也就這些了。知道這些各種原因，對於使用jstat -gccause 排查FGC問題時也是幫助很大。