查看系统的full gc频率，可以使用jstack命令

一、采用top命令定位进程

登录服务器，执行top命令，查看CPU占用情况，找到进程的pid

二、使用jstack命令统计垃圾回收

jstat -gc pid 5000

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

以上显示程序运行以来共：

发生YoungGC 765次，总耗时48.174秒

发生FGC 11次，总耗时9.062秒

所有GC总耗时57.236秒

其对应的指标含义如下：

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

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

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

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

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

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

• OC Old代的容量 (字节)

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

• MC 方法区大小

• MU 方法区目前已使用空间 (字节)

• CCSC 压缩类空间大小

• CCSU 压缩类空间已使用大小

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

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

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

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

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

三、查看full gc频率

ps -eo pid,tty,user,comm,lstart,etime | grep pid

四、JVM垃圾回收理解

a: YoungGC过程理解

新生代内存按照8:1:1的比例分为一个eden区和两个survivor(survivor0,survivor1)区。一个Eden区，两个 Survivor区。新new出来的对象会存储在 Eden(伊甸园)中，当这区域满了之后JVM会进行一次垃圾回收，在回收时把有用的对象存储在S1区，没用的就销毁此对象的内存空间，这过程即第一次YoungGC，如果S1区空间也满了后，同理会将有用的对象会放到S2区中，并释放S1空间，以上反复的回收即为YoungGC。

b: FullGC过程理解

年轻代空间满了之后，会将满足一定活跃度的对象放到Old区中(对象活跃度：每个对象满足JVM默认count=15之后就判断是活跃对象，每次YoungGC后会将存活对象生命中+1，直到=15就转到Old区，这个次数可以通过：-XX:MaxTenuringThreshold来配置)， 由于Full GC需要对整个堆进行回收，导致应用访问变慢，因此应该尽可能减少Full GC的次数。

c.JVM内存回收如何判定回收不彻底？可能导致内存泄漏或溢出

如果 S0 、S1、 伊甸园区 这三个空间都有值的时候说明可能存在问题。

因为正常情况下是每次GC后，S0区、S1区中的空间总有一个是会被完全清空（根据GC垃圾回收算法），因此S0 S1一直存在被占用时则回收不彻底，导致内存泄漏现象，随之时间拉长，甚至出现内存溢出（OOM）现象。

五、总结

• 年轻代：复制算法

所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象

• 年老代：标记-清除或标记-整理算法

在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象

在压力测试过程中发现Eden区内存增加过快，根据压测VU和业务判断是否合理，从而判断YoungGC频率是否正常。

FullGC频率一般在半小时一次较为正常，具体根据真实业务判断，那么在压力测试过程中，监控到FullGC次数过多，则需根据压测业务结合代码分析定位。