在網上看到關於記憶體回收機制，同大家一起分析探討。堆記憶體劃分為Eden、Survivor 和 Tenured/Old 空間，如下圖所示：

Minor GC 會清理年輕代的記憶體，Major GC 是清理老年代(包括 Eden 和 Survivor 區域)，Full GC 是清理整個堆空間—包括年輕代和老年代，是指全域性執行垃圾回收。

1、老年代代空間不足老年代空間只有在新生代物件轉入及建立為大物件、大陣列時才會出現不足的現象，當執行Full GC後空間仍然不足，則丟擲如下錯誤：

java.lang.OutOfMemoryError: Java heap space

為避免以上兩種狀況引起的Full GC，調優時應儘量做到讓物件在Minor GC階段被回收、讓物件在新生代多存活一段時間及不要建立過大的物件及陣列。

2、永生區空間不足

JVM規範中執行時資料區域中的方法區，在HotSpot虛擬機器中又被習慣稱為永生代或者永生區，Permanet Generation中存放的為一些class的資訊、常量、靜態變數等資料，當系統中要載入的類、反射的類和呼叫的方法較多時，Permanet Generation可能會被佔滿，在未配置為採用CMS GC的情況下也會執行Full GC。如果經過Full GC仍然回收不了，那麼JVM會丟擲如下錯誤資訊：

java.lang.OutOfMemoryError: PermGen space

為避免Perm Gen佔滿造成Full GC現象，可採用的方法為增大Perm Gen空間或轉為使用CMS GC。

3、CMS GC時出現promotion failed和concurrent mode failure

對於採用CMS進行老年代GC的程式而言，尤其要注意GC日誌中是否有promotion failed和concurrent mode failure兩種狀況，當這兩種狀況出現時可能會觸發Full GC。

promotion failed是在進行Minor GC時，survivor space放不下、物件只能放入老年代，而此時老年代也放不下造成的；concurrent mode failure是在執行CMS GC的過程中同時有物件要放入老年代，而此時老年代空間不足造成的（有時候“空間不足”是CMS GC時當前的浮動垃圾過多導致暫時性的空間不足觸發Full GC）。

措施為：增大survivor space、老年代空間或調低觸發併發GC的比率，但在JDK 5.0+、6.0+的版本中有可能會由於JDK的bug29導致CMS在remark完畢後很久才觸發sweeping動作。對於這種狀況，可通過設定-XX: CMSMaxAbortablePrecleanTime=5（單位為ms）來避免。

4、統計得到的Minor GC晉升到舊生代的平均大小大於老年代的剩餘空間

這是一個較為複雜的觸發情況，Hotspot為了避免由於新生代物件晉升到舊生代導致舊生代空間不足的現象，在進行Minor GC時，做了一個判斷，如果之前統計所得到的Minor GC晉升到舊生代的平均大小大於舊生代的剩餘空間，那麼就直接觸發Full GC。

5、堆中分配很大的物件

所謂大物件，是指需要大量連續記憶體空間的java物件，例如很長的陣列，此種物件會直接進入老年代，而老年代雖然有很大的剩餘空間，但是無法找到足夠大的連續空間來分配給當前物件，此種情況就會觸發JVM進行Full GC。

為了解決這個問題，CMS垃圾收集器提供了一個可配置的引數，即-XX:+UseCMSCompactAtFullCollection開關引數，用於在“享受”完Full GC服務之後額外免費贈送一個碎片整理的過程，記憶體整理的過程無法併發的，空間碎片問題沒有了，但提頓時間不得不變長了，JVM設計者們還提供了另外一個引數 -XX:CMSFullGCsBeforeCompaction,這個引數用於設定在執行多少次不壓縮的Full GC後,跟著來一次帶壓縮的。上述幾條說明，以上源於CodeKing2017的簡書。

1、WEBLOGIC Full GC執行時間佔比

Full GC執行佔比=（測試結束FGCT總時間-測試開始FGCT總時間）/（測試結束時間-測試開始時間）

1）在場景執行開始時使用jstat_JZ_test_ -gcutil 取樣頻率(毫秒)  取樣次數 >> 結果檔名 命令監控gc狀態，監控持續時間與場景執行時間保持一致；
2）監控結果中FGCT列的值為對應時點的Full GC執行總時間；
3）Full GC執行佔比=（測試結束Full GC總時間-測試開始Full GC總時間）/（測試結束時間-測試開始時間）

 2、WEBLOGIC Full GC執行間隔

Full GC執行間隔=（測試結束時間-測試開始時間）/（測試結束FGC次數-測試開始FGC次數）

備註：*測試結束時間—測試開始時間：場景執行的時間

1）命令如上監控gc狀態，監控持續時間與場景執行時間保持一致；
2）監控結果中FGCT列的值為對應時點的Full GC執行總時間，FGC列的值為對應時點的Full GC次數；
3）Full GC間隔=（測試結束時間-測試開始時間）/（測試結束Full GC次數-測試開始Full GC次數）。

二、WAS Full GC監控

1、首先我們需要開啟gc的日誌記錄

　　進入was控制檯 選擇伺服器WebSphere Application Server -> serverName -> 伺服器基礎結構 -> java程序管理-> 程序定義-> java虛擬機器； 在配置和執行時上勾選詳細垃圾回收選項，應用儲存來列印更詳細的GC日誌，重啟該服務，預設日誌記錄檔案是native_stderr.log檔案。

 2、分析GC日誌

　　2.1在步驟一中，返回上層到 程序定義 中，點選程序日誌，可檢視日誌記錄檔案native_stderr.log預設路徑。

　　2.2下載該檔案，雙擊執行ga456.jar，即可開啟IBM分析工具進行分析，可檢視GC及Full GC執行次數，間隔時間等資訊。

 　　2.3 ga456.jar該檔案下載：https://pan.baidu.com/s/1TW_P0UnwhG8DnNS2uKwB2g

具體GC說明可連結：Full GC回收詳解