在网上看到关于内存回收机制，同大家一起分析探讨。堆内存划分为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)中间件