查看系统的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次数过多，则需根据压测业务结合代码分析定位。
