线上服务器fullGc频繁记录

现状： -Xms：8G -Xmx:8G -Xmn:2G
下面是gc日志输出的配置：
CommandLine flags: -XX:CMSInitiatingOccupancyFraction=75 -XX:+ExplicitGCInvokesConcurrent -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/logs/HeapDump_Gc/order-service-64-1297813794-trdwn.hprof -XX:InitialHeapSize=8589934592 -XX:InitialTenuringThreshold=6 -XX:+ManagementServer -XX:MaxHeapSize=8589934592 -XX:MaxMetaspaceSize=536870912 -XX:MaxNewSize=2097152000 -XX:MaxTenuringThreshold=6 -XX:MetaspaceSize=134217728 -XX:NewSize=2097152000 -XX:OldPLABSize=16 -XX:+ParallelRefProcEnabled -XX:+PrintGC -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -PretenureSizeThreshold=512 -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
一、youngGC :
分析gc日志后，发现相邻两次youngGC 年轻代对象每秒增加30M左右，并不是很多，进入老年代的也就几百K，按理说fullGC很久才会触发，但是现在一天有多次fullGC，而且很规律一小时一次，初步判断是有定时任务去执行 system.gc()
时间段
间隔
年轻代回收对象
堆内存总体回收对象大小
进入老年代对象大小
2019-09-27 12:00:06.488 ~ 2019-09-27 12:00:57.045
50s
1735473K-92024K = 1643449K
1961480K-318420K = 1643060K
1643449K-1643060K=389K
2019-09-27 09:54:10.055 ~ 2019-09-27 09:54:59.363
49s
1738840K-92973K=1645867K
1959247K-313680K=1645567K
1645867K-1645567K=300K
2019-09-27 15:06:07.382 ~ 2019-09-27 15:06:36.447
29s
1729523K-92947K=1636576K
1964056K-327631K=1636425K
1636576K-1636425K = 151K
2019-09-27 21:17:05.841 ~ 2019-09-27 21:17:38.573
33s
1727324K-74058K=1653266K
1964866K-313197K=1651669K
1653266K-1651669K=1597K
2019-10-09 03:43:06.098 ~ 2019-10-09 03:43:29.517
23s
1706624K-67038K=1639586K
1963381K->323926K=1639455K
1639586K-1639455K=131K
2019-10-08 14:59:38.440 ~ 2019-10-08 15:00:16.484
38s
1703895K->66871K=1637024K
1969326K->332344K=1636982K
1637024-1636982K=42K

2、通过全局搜索system.gc(),发现代码没有直接去调用的地方，怀疑是三方jar引起，之后通过设置jvm参数 -XX:+HeapDumpBeforeFullGC -XX:+HeapDumpAfterFullGC ，准备拿到dump文件，分析堆栈信息，但是发生fullGC时，没有导出dump文件，原因未知，换用另一个方案，本地断点调试，最后在堆中看到activemq调用rmi，通过
sun.rmi.dgc.server.gcInterval

sun.rmi.dgc.client.gcInterval

这两个参数默认值设置了gc间隔时间一小时，healthCheck首次发现没有守护进程，会生成一个守护进程，并执行进程，进程内会判断gc间隔，如果够一小时，就会调用 system.gc()。下次执行healthCheck时，会进程内会判断gc间隔，不够一小时直接跳过，所以最终呈现的是一小时一次fullGC。
3、一种解决方式就是把两个参数时间设置长点，但是我们项目没有依赖activeMq，故我采用去除依赖的方式
去掉activemq依赖后，cmsGC次数没有了

2c项目Gc分析
现状： -Xms：2G -Xmx:8G -Xmn:1G (Eden：819.2M s0区：102.4M s1区：102.4M)
1、youngGC : 高峰期不到 10s一次 低峰期 120s一次
2、cmsGC:30分钟左右一次
2、fullGC：1天一次
按2c一天36w的体量，即使流量全打到sj02的6个实例，每个实例也就6w订单，高峰期四个小时，80%的单例，一个单子算20请求操作，一个实例均下来每秒不到100单，我们1s最起码创建70M左右的对象，一个请求产生700K的对象
s区太小，根据动态年龄规则，每次存活对象超过s区一半的概率很高，本不该转移老年代的对象增多,缩短了触发fullGC的时间
设置jvm启动参数跟order-service-64 一样的话，youngGC频率下降一倍，cmsGC和fullGc频率保守估计下降 6倍
（目前老年代是1G，调整后会到7G，因为存活对象符合动态年龄规则的概率减少，进入老年代对象也会减少，所以是保守估计，有可能会更久）