一次线上JVM调优实践，FullGC40次/天到10天一次的优化过程

问题

前一段时间，线上服务器的 FullGC 非常频繁，平均一天40多次，而且隔几天就有服务器自动重启了，这表明服务器的状态已经非常不正常了，得到这么好的机会，当然要主动请求进行调优了。
首先服务器的配置非常一般（2核4G），总共4台服务器集群。每台服务器的 FullGC 次数和时间基本差不多。其中 JVM 几个核心的启动参数为：

-Xms1000M 
-Xmx1800M 
-Xmn350M 
-Xss300K 
-XX:+DisableExplicitGC 
-XX:SurvivorRatio=4 
-XX:+UseParNewGC 
-XX:+UseConcMarkSweepGC 
-XX:CMSInitiatingOccupancyFraction=70 
-XX:+CMSParallelRemarkEnabled 
-XX:LargePageSizeInBytes=128M 
-XX:+UseFastAccessorMethods 
-XX:+UseCMSInitiatingOccupancyOnly 
-XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps 
-XX:+PrintHeapAtGC

• -Xmx1800M：设置 JVM 最大可用内存为1800M。
• -Xms1000m：设置 JVM 初始化内存为 1000m。此值可以设置与 -Xmx 相同，以避免每次垃圾回收完成后JVM重新分配内存。
• -Xmn350M：设置年轻代大小为350M。整个JVM内存大小 = 年轻代大小 + 年老代大小。增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的 3/8。
• -Xss300K：设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。根据应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在 3000~5000 左右。

第一次优化

一看参数，马上觉得新生代为什么这么小，这么小的话怎么提高吞吐量，而且会导致 YoungGC 的频繁触发，如上图的新生代收集就耗时 830s。

初始化堆内存没有和最大堆内存一致，查阅了各种资料都是推荐这两个值设置一样的，可以防止在每次GC后进行内存重新分配。

基于前面的知识，于是进行了第一次的线上调优：提升新生代大小，将初始化堆内存设置为最大内存。

-Xmn350M -> -Xmn800M
-XX:SurvivorRatio=4 -> -XX:SurvivorRatio=8
-Xms1000m ->-Xms1800m
将 SurvivorRatio 修改为8的本意是想让垃圾在新生代时尽可能的多被回收掉。

就这样将配置部署到线上两台服务器（prod，prod2 另外两台不变方便对比）上后，运行了5天后，观察GC结果，YoungGC 减少了一半以上的次数，时间减少了400s，但是 FullGC 的平均次数增加了41次。YoungGC 基本符合预期设想，但是这个 FullGC 就完全不行了。就这样第一次优化宣告失败。

第二次优化

在优化的过程中，我们的主管发现了有个对象T在内存中有一万多个实例，而且这些实例占据了将近 20M 的内存。于是根据这个 bean 对象的使用，在项目中找到了原因：匿名内部类引用导致的，伪代码如下：

public void doSmthing(T t){
 redis.addListener(new Listener(){
  public void onTimeout(){
   if(t.success()){
    //执行操作
   }
  }
 });
}

由于 listener 在回调后不会进行释放，而且回调是个超时的操作，当某个事件超过了设定的时间（1分钟）后才会进行回调，这样就导致了T这个对象始终无法回收，所以内存中会存在这么多对象实例。

通过上述的例子发现了存在内存泄漏后，首先对程序中的 error log 文件进行排查，首先先解决掉所有的 error 事件。然后再次发布后，GC操作还是基本不变，虽然解决了一点内存泄漏问题，但是可以说明没有解决根本原因，服务器还是继续莫名的重启。

内存泄漏调查

经过了第一次的调优后发现内存泄漏的问题，于是大家都开始将进行内存泄漏的调查，首先排查代码，不过这种效率是蛮低的，基本没发现问题。于是在线上不是很繁忙的时候继续进行 dump 内存，终于抓到了一个大对象。
这个对象竟然有4W多个，而且都是清一色的 ByteArrowRow 对象，可以确认这些数据是数据库查询或者插入时产生的了。
于是又进行一轮代码分析，在代码分析的过程中，通过运维的同事发现了在一天的某个时候入口流量翻了好几倍，竟然高达 83MB/s ，经过一番确认，目前完全没有这么大的业务量，而且也不存在文件上传的功能。
原因就是在某个条件下，会查询表中所有未处理的指定数据，但是由于查询的时候 where 条件中少加了模块这个条件，导致查询出的数量达 40 多万条，而且通过 log 查看当时的请求和数据，可以判断这个逻辑确实是已经执行了的，dump 出的内存中只有4W多个对象，这个是因为 dump 时候刚好查询出了这么多个，剩下的还在传输中导致的。而且这也能非常好的解释了为什么服务器会自动重启的原因。
解决了这个问题后，线上服务器运行完全正常了，使用未调优前的参数，运行了3天左右 FullGC 只有5次。

第二次调优

内存泄漏的问题已经解决了，剩下的就可以继续调优了，经过查看GC log，发现前三次 FullGC 时，老年代占据的内存还不足30%，却发生了 FullGC。

于是进行各种资料的调查，在 https://blog.csdn.net/zjwstz/article/details/77478054博客中非常清晰明了的说明 metaspace 导致 FullGC 的情况，服务器默认的 metaspace 是21M，在GC log中看到了最大的时候 metaspace 占据了200M 左右，于是进行如下调优，以下分别为 prod1 和 prod2 的修改参数，prod3，prod4保持不变。

-Xmn350M -> -Xmn800M
-Xms1000M ->1800M
-XX:MetaspaceSize=200M
-XX:CMSInitiatingOccupancyFraction=75

和

-Xmn350M -> -Xmn600M
-Xms1000M ->1800M
-XX:MetaspaceSize=200M
-XX:CMSInitiatingOccupancyFraction=75

总结

• FullGC 一天超过一次肯定就不正常了。
• 发现 FullGC 频繁的时候优先调查内存泄漏问题。
• 内存泄漏解决后，jvm可以调优的空间就比较少了，作为学习还可以，否则不要投入太多的时间。
• 如果发现 CPU 持续偏高，排除代码问题后可以找运维咨询下阿里云客服，这次调查过程中就发现 CPU100% 是由于服务器问题导致的，进行服务器迁移后就正常了。
• 数据查询的时候也是算作服务器的入口流量的，如果访问业务没有这么大量，而且没有攻击的问题的话可以往数据库方面调查。
• 有必要时常关注服务器的GC，可以及早发现问题。