在網上看到關於內存回收機制，同大家一起分析探討。堆內存划分為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執行總次數（Number of Global/Full Garbage Collections），每次執行間隔時間（Average Full Garbage Collection interval）等信息。
2.3 ga456.jar該文件下載：https://pan.baidu.com/s/1TW_P0UnwhG8DnNS2uKwB2g
具體GC說明可鏈接：Full GC回收詳解
后續：Jconsole/jvisualvm遠程監控weblogic中間件配置 jvisualvm/Jconsole監控WAS(WebSphere)中間件