如何 排查 full gc 原因

1、用gcLogViewer分析gc.log，记录下FullGC的几个点，再到gc.log中具体去看那段时间的gc情况，一般就可以分析出FullGC的原因。

2、如果FullGC很频繁的话，也可以直接在服务器上通过jstat观察，对于反射调用特别多这种情况，建议注意看看PermGen的增长是不是FullGC的原因，如果是的话，开大PermGen，或者使用CMS方式对PermGen进行回收。

Linux 使用jstat命令查看jvm的GC情况

命令格式

jstat命令命令格式：

jstat [Options] vmid[interval] [count]

参数说明：

Options，选项，我们一般使用 -gcutil 查看gc情况

vmid

，VM的进程号，即当前运行的java进程号

interval

，间隔时间，单位为秒或者毫秒

count

，打印次数，如果缺省则打印无数次

示例说明

示例

通常运行命令如下：

jstat -gc 12538 5000

即会每5秒一次显示进程号为12538的java进成的GC情况，

显示内容如下图：

结果说明

   S0C：年轻代中第一个survivor（幸存区）的容量 (字节)

S1C

：年轻代中第二个survivor（幸存区）的容量 (字节)

S0U

：年轻代中第一个survivor（幸存区）目前已使用空间 (字节)

S1U

：年轻代中第二个survivor（幸存区）目前已使用空间 (字节)

EC

：年轻代中Eden（伊甸园）的容量 (字节)

EU

：年轻代中Eden（伊甸园）目前已使用空间 (字节)

OC

：Old代的容量 (字节)

OU

：Old代目前已使用空间 (字节)

PC

：Perm(持久代)的容量 (字节)

PU

：Perm(持久代)目前已使用空间 (字节)

YGC

：从应用程序启动到采样时年轻代中gc次数

YGCT

：从应用程序启动到采样时年轻代中gc所用时间(s)

FGC

：从应用程序启动到采样时old代(全gc)gc次数

FGCT

：从应用程序启动到采样时old代(全gc)gc所用时间(s)

GCT

：从应用程序启动到采样时gc用的总时间(s)

NGCMN

：年轻代(young)中初始化(最小)的大小 (字节)

NGCMX

：年轻代(young)的最大容量 (字节)

NGC

：年轻代(young)中当前的容量 (字节)

OGCMN

：old代中初始化(最小)的大小 (字节)

OGCMX

：old代的最大容量 (字节)

OGC

：old代当前新生成的容量 (字节)

PGCMN

：perm代中初始化(最小)的大小 (字节)

PGCMX

：perm代的最大容量 (字节)

PGC

：perm代当前新生成的容量 (字节)

S0

：年轻代中第一个survivor（幸存区）已使用的占当前容量百分比

S1

：年轻代中第二个survivor（幸存区）已使用的占当前容量百分比

E

：年轻代中Eden（伊甸园）已使用的占当前容量百分比

O

：old代已使用的占当前容量百分比

P

：perm代已使用的占当前容量百分比

S0CMX

：年轻代中第一个survivor（幸存区）的最大容量 (字节)

S1CMX

：年轻代中第二个survivor（幸存区）的最大容量 (字节)

ECMX

：年轻代中Eden（伊甸园）的最大容量 (字节)

DSS

：当前需要survivor（幸存区）的容量 (字节)（Eden区已满）

TT

： 持有次数限制

MTT

： 最大持有次数限制

除直接调用System.gc外，触发Full GC执行的情况有如下四种。

1. 旧生代空间不足

旧生代空间只有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象，当执行Full GC后空间仍然不足，则抛出如下错误:

java.lang.OutOfMemoryError: Java heap space

为避免以上两种状况引起的Full GC，调优时应尽量做到让对象在Minor GC阶段被回收、让对象在新生代多存活一段时间及不要创建过大的对象及数组。

2. Permanet Generation空间满

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的过程中同时有对象要放入旧生代，而此时旧生代空间不足造成的。

应对措施为:增大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。

例如程序第一次触发Minor GC后，有6MB的对象晋升到旧生代，那么当下一次Minor GC发生时，首先检查旧生代的剩余空间是否大于6MB，如果小于6MB，则执行Full GC。

当新生代采用PS GC时，方式稍有不同，PS GC是在Minor GC后也会检查，例如上面的例子中第一次Minor GC后，PS GC会检查此时旧生代的剩余空间是否大于6MB，如小于，则触发对旧生代的回收。

除了以上4种状况外，对于使用RMI来进行RPC或管理的Sun JDK应用而言，默认情况下会一小时执行一次Full GC。可通过在启动时通过- java -Dsun.rmi.dgc.client.gcInterval=3600000来设置Full GC执行的间隔时间或通过-XX:+ DisableExplicitGC来禁止RMI调用System.gc。

---