排查一次groovy引起的fullGC问题

1.问题背景2.分析过程2.1参数配置2.2定位过程2.3JVM分析2.4问题分析3.解决方案1.问题背景8-12点之间会出现fullGC告警；排除故障并解决问题；2.分析过程2.1参数配置JVM参数配置如下：-Xms3g-Xmx3g-Xmn1g-XX:MetaspaceSize=128m-XX:ParallelGCThreads=5-XX:+UseConcMarkSweepGC-XX:+UseParNewGC-XX:+UseCMSCompactAtFullCollection-XX:CMSInitiatingOccupancyFraction=80-XX:+PrintGCDetails-XX:+PrintGCDateStamps-XX:+HeapDumpOnOutOfMemoryError新生代大小：1G；新一代垃圾收集器：ParNewGC；老年代大小：2G；老年代垃圾收集器：ConcMarkSweepGC；CMS触发条件：老年代内存使用率达到80%及以上；2.2位置问题由某个定时任务引起；2.定位到具体的定时任务，两个定时任务的时间设置基本满足；任务一：更新客户信息CustomerScheduleJobService.updateCustomerDataDaily00/308,9,10,11,12**?任务二：创建客户任务CustomerStaffScheduleJobService.jobCreateTask010,407,8,9,10,11**?3。具体任务的确认方式有两种：1、通过日志确认定时任务的执行时间；2、将两个定时任务指定给不同的机器进行观察；查看任务的执行时间：任务1：非常快，几乎不处理业务逻辑；[03-0908:00:00062信息][][][][customerDataStat-pool-0]bll.customer.CustomerUpdateInfoDailyBll-(123)logid=6907112718471909376[BizCustomerBll.updateCustomerDataDaily]线程开始...Ip:10.151.49.157[03-0908:01:25476INFO][][][][customerDataStat-pool-0]bll.customer.CustomerUpdateInfoDaily-(125Bll)logid=6907112718471909376[BizCustomerBll.updateCustomerDataDaily]endtotal=0Ip:10.151.49.157任务2：执行约35分钟；8:10开始，8:45结束；[03-0908:45:08458INFO][][][][pool-4-thread-20]bll.task.CreateCustomerTaskBll-(109)logid=6907115234995589120method=jobCreateTaskmsg=endqueryRuleNum=7queryCustomerNum=15962createTaskCustomerNum=238createTaskCount=271Ip:10.151.49.157基本确定2.3JVM分析2.3.1单日监控图内存趋势GC趋势2.3.2告警期监控图内存趋势GC趋势2.3.3图表分析2.3.3.1老年代变化现象1.Task执行过程中：老年代明显增加，FullGC后没有特别明显的下降，只是略有下降；2、任务执行完毕：下一个任务开始执行，经过FullGC后，会下降到和其他机器一样的水平，甚至更低的内存占用；注意从新生代到老年代的几种情况1：大对象；2：age足够长，不设置cms，默认6，经jinfo确认也是6；3：survivor区不足以存放YGC最后存活的对象，使用保证策略直接提升到老年代；在分析任务执行过程中，YGC平均每分钟执行5次，很多对象会达到最大提升年龄6，提升到老年代；并且因为任务还没有结束，对象还是有引用的，所以FullGC之后没有明显的下降；上次任务结束后老年代不像suvivor区也有一段时间内存占用低，主要是下一个任务启动后才会触发新的FullGC。触发后，老年代中的对象会因为任务结束后没有被引用而正常回收；2.3.3.2survivor区的变化Survivor区总内存为100M。任务执行期间，平均占用80M；高的时候会飙到90多，所以YGC在这个过程中也变得非常频繁，平均每分钟5次；2.3.3.3非堆内存/方法区/压缩类缓存变化使用jstat分别统计两台机器的gc统计。两者最大的区别在于，执行过定时任务的机器的MC（方法区大小）和CCSC（压缩类空间大小）明显比没有执行过定时任务的机器高很多；任务执行过程中方法区的内存占用会和老年代的曲线保持一致，这些区域的回收也依赖于老年代，从grafana平台的监控图中也可以看出；2.3.3.4dump文件分析groovy相关类占57.57%；2.4参数配置java和groovy版本java版本"1.8.0_191"org.codehaus.groovygroovy-all2.4.15其中代码中使用了groovy：同一个定时任务，在任务下发时，表达式检查是否满足下发条件，表达式使用Groovy进行处理；公共类GroovyShellUtils{私有静态LoggerHelper记录器=LoggerHelper.getLoggerHelper(GroovyShellUtils.class);publicstaticbooleanexplain(StringscriptText){try{GroovyShellgroovyShell=newGroovyShell();对象评估=groovyShell.evaluate(scriptText);返回（布尔值）评估；}catch(Exceptione){logger.error("",e);}returnfalse;}}//use:for(Stringrule:rules){booleanres=GroovyShellUtils.explain(rule);}基本上，问题可以定位到groovy脚本加载的地方。不合理的使用groovy会导致动态生成很多新的类，使得元空间不断被占用；class对象在1.8及以后是存放在metaspace中的，也就是groovy每次执行堆外内存的时候，都会动态加载传入的文本到一个脚本类中。动态生成一个新类，1user7tasksrulevalidation*15962users=111734protectedsynchronizedStringgenerateScriptName(){return"Script"+(++counter)+".groovy";}GroovyShellinternally,Itusesgroovy.lang.GroovyClassLoader，它是运行时编译加载类的核心。GroovyClassLoader保留对其创建的所有类的引用，类对象只有在被加载的类加载器被回收时才会被回收，因此很容易造成内存泄漏；综上所述，groovy的错误使用导致永久类对象的堆外内存随着调用频率的增加而增长。三、解决方案1、每个脚本共享一个GroovyShell对象，不能以for方式创建和使用；2、每次执行后释放对象shell.getClassLoader().clearCache()；