java项目线上JVM调优实践，FullGC大大减少

布满荆棘的人生 2022-09-04 06:53 202阅读 0赞

![a3049a0fd3580c93ba6e48d0c2fcb2d3.png][]

对于JVM垃圾回收，之前一直都是处于理论阶段，就知道新生代，老年代的晋升关系，这些知识仅够应付面试使用的。前一段时间，线上服务器的FullGC非常频繁，平均一天40多次，而且隔几天就有服务器自动重启了，这表明的服务器的状态已经非常不正常了，得到这么好的机会，当然要主动请求进行调优了。未调优前的服务器GC数据，FullGC非常频繁。

![2c3a358a30c379cc129056ef01719e50.png][]

首先服务器的配置非常一般（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内存大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，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就完全不行了。

![b9e7e9e059c335430b5eecaaa8539f55.png][]

就这样第一次优化宣告失败。

# 第二次优化 #

在优化的过程中，我们的主管发现了有个对象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内存，终于抓到了一个大对象。

![09794dba1a7a3d9d4d73754fecaba253.png][]

![5e7a805e2c59696d313d6883b01a1b15.png][]

这个对象竟然有4W多个，而且都是清一色的ByteArrowRow对象，可以确认这些数据是数据库查询或者插入时产生的了。于是又进行一轮代码分析，在代码分析的过程中，通过运维的同事发现了在一天的某个时候入口流量翻了好几倍，竟然高达83MB/s，经过一番确认，目前完全没有这么大的业务量，而且也不存在文件上传的功能。咨询了阿里云客服也说明完全是正常的流量，可以排除攻击的可能。

![c5541b3cb0947394c7b398e6883d97a9.png][]

就在我还在调查入口流量的问题时，另外一个同事找到了根本的原因，原来是在某个条件下，会查询表中所有未处理的指定数据，但是由于查询的时候where条件中少加了模块这个条件，导致查询出的数量达40多万条，而且通过log查看当时的请求和数据，可以判断这个逻辑确实是已经执行了的，dump出的内存中只有4W多个对象，这个是因为dump时候刚好查询出了这么多个，剩下的还在传输中导致的。而且这也能非常好的解释了为什么服务器会自动重启的原因。

解决了这个问题后，线上服务器运行完全正常了，使用未调优前的参数，运行了3天左右FullGC只有5次。

![9c30ea0bd25e8ba650fb8985ef9cfc8f.png][]

# 第二次调优 #

内存泄漏的问题已经解决了，剩下的就可以继续调优了，经过查看GC log，发现前三次GullGC时，老年代占据的内存还不足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

prod1和2只是新生代大小不一样而已，其他的都一致。到线上运行了10天左右，进行对比：  
prod1：

![86d945683a52242f0cb10aa1e3eccc96.png][]

prod2：

![3d7c090be45e0b1b92bebb1f9d5ad874.png][]

prod3：

![cfb6d2d314ae6e22c455a7b2653ea721.png][]

prod4：

![7b6045bc50e273abcd27436ee3f6511f.png][]

对比来说，1，2两台服务器FullGC远远低于3，4两台，而且1，2两台服务器的YounGC对比3，4也减少了一半左右，而且第一台服务器效率更为明显，除了YoungGC次数减少，而且吞吐量比多运行了一天的3，4两台的都要多（通过线程启动数量），说明prod1的吞吐量提升尤为明显。

通过GC的次数和GC的时间，本次优化宣告成功，且prod1的配置更优，极大提升了服务器的吞吐量和降低了GC一半以上的时间。

prod1中的唯一一次FullGC：

![31989aeca85fe1b86fdc5eb875a1fe8b.png][]

![80bd589fe928bd086a206b21914d3022.png][]

通过GC log上也没看出原因，老年代在cms remark的时候只占据了660M左右，这个应该还不到触发FullGC的条件，而且通过前几次的YoungGC调查，也排除了晋升了大内存对象的可能，通过metaspace的大小，也没有达到GC的条件。这个还需要继续调查，有知道的欢迎指出下，这里先行谢过了。

# 总结 #

通过这一个多月的调优总结出以下几点：

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

[![55a872c9a67de2970cd66bca09a6304d.png][]][55a872c9a67de2970cd66bca09a6304d.png 1]

[非常nice的分布式事务方案总结][55a872c9a67de2970cd66bca09a6304d.png 1]

[![ddf6e6fbc442c2a7d656a4d937042d01.png][]][ddf6e6fbc442c2a7d656a4d937042d01.png 1]

[【干货】6500字全面字讲解 Redis 性能优化点！][ddf6e6fbc442c2a7d656a4d937042d01.png 1]

[![9e568b561a5d7e0e494a903d4d5bece1.png][]][9e568b561a5d7e0e494a903d4d5bece1.png 1]

[精髓！深入浅出剖析12个Zookeeper知识点][9e568b561a5d7e0e494a903d4d5bece1.png 1]

[![fe977e0ec13147c3b8edf50db3c848f9.png][]][fe977e0ec13147c3b8edf50db3c848f9.png 1]

[面试官：请你讲讲Thread.sleep(0) 的作用？][fe977e0ec13147c3b8edf50db3c848f9.png 1]

[![b9f2b90d724cd4fb85c4db2c527ae79b.png][]][b9f2b90d724cd4fb85c4db2c527ae79b.png 1]

[Spring+SpringMVC+Mybatis分布式敏捷开发系统架构（附源码）][b9f2b90d724cd4fb85c4db2c527ae79b.png 1]

[![834e9ffd9f0095c9e541ed2758596bb5.png][]][834e9ffd9f0095c9e541ed2758596bb5.png 1]

[Java大文件HTTP断点续传到服务器该怎么做？][834e9ffd9f0095c9e541ed2758596bb5.png 1]

![41b384c5923be7e7637be28549be43e1.png][]

[a3049a0fd3580c93ba6e48d0c2fcb2d3.png]: /images/20220829/8310e9b0c49e4c70bb07a30b3b16086d.png
[2c3a358a30c379cc129056ef01719e50.png]: /images/20220829/178633db87f24b88ba198f9f8877c92b.png
[b9e7e9e059c335430b5eecaaa8539f55.png]: /images/20220829/0f0ad4b3f6f84600b49cfbda77a8d630.png
[09794dba1a7a3d9d4d73754fecaba253.png]: /images/20220829/690c89fa16264ff8a797bf77d23236bc.png
[5e7a805e2c59696d313d6883b01a1b15.png]: /images/20220829/e87ff0d584d74895b27dba9ac11b355b.png
[c5541b3cb0947394c7b398e6883d97a9.png]: /images/20220829/bf738238f84d4da995e744c60d8ef272.png
[9c30ea0bd25e8ba650fb8985ef9cfc8f.png]: /images/20220829/4472e9f6a7f54de88b456c411b97d300.png
[86d945683a52242f0cb10aa1e3eccc96.png]: /images/20220829/f5fd2c77a656423b8528d9fcd7e8a1be.png
[3d7c090be45e0b1b92bebb1f9d5ad874.png]: /images/20220829/c3b3c4e69ddd44569704f1db1b46a2bb.png
[cfb6d2d314ae6e22c455a7b2653ea721.png]: /images/20220829/f7f7891b4f094685b2ff4b4dfebd8b8a.png
[7b6045bc50e273abcd27436ee3f6511f.png]: /images/20220829/3575d72f5d7c4e8480c0543a20af0e18.png
[31989aeca85fe1b86fdc5eb875a1fe8b.png]: /images/20220829/39a15a0157e849e4b339fc3a81a40f86.png
[80bd589fe928bd086a206b21914d3022.png]: /images/20220829/1b705a953f064246a363c51f839d48fb.png
[55a872c9a67de2970cd66bca09a6304d.png]: /images/20220829/3c63f5c670df40bcbfa65a9f6231ad40.png
[55a872c9a67de2970cd66bca09a6304d.png 1]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44efe1cb3366f7bcb5a3bfe09f8fa32bcc427cffe9785fae97fb55fa3dfeac7e5532276b9c&idx=1&mid=2247490264&scene=21&sn=9d1961c731aef698b333988d1978f03f#wechat_redirect
[ddf6e6fbc442c2a7d656a4d937042d01.png]: /images/20220829/aa94c715d2a448888a4b1e73ae2cdecf.png
[ddf6e6fbc442c2a7d656a4d937042d01.png 1]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44efeacb3366fc3f5e828c865265c6ded87a6cc4ee6175e89b14f4a17d572d3a92175a76f4&idx=1&mid=2247490259&scene=21&sn=4051f7f53ce0764d32276a02454e70b7#wechat_redirect
[9e568b561a5d7e0e494a903d4d5bece1.png]: /images/20220829/2ce53eb515d64f84902af695be16f658.png
[9e568b561a5d7e0e494a903d4d5bece1.png 1]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44efe1cb3366f7b86aca68da111b8ab0d19f79141be18b0e456e95480076b2fdf3646bdef6&idx=2&mid=2247490264&scene=21&sn=5ad671d29dc88368317b53c9a57d223e#wechat_redirect
[fe977e0ec13147c3b8edf50db3c848f9.png]: /images/20220829/5a7ef84355994918a9e0ac7bf817d2eb.png
[fe977e0ec13147c3b8edf50db3c848f9.png 1]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44efebcb3366fdeddaf99f3de3e9df6979b3b6b041d230ccca4325f41d41468edc61983455&idx=1&mid=2247490258&scene=21&sn=9d8232c367bf7a9474afef18a12262c1#wechat_redirect
[b9f2b90d724cd4fb85c4db2c527ae79b.png]: /images/20220829/8a53fbfd62d8465a9c1c4939fec04a4f.png
[b9f2b90d724cd4fb85c4db2c527ae79b.png 1]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44efebcb3366fd6242fa41c12b4fe11b5c17fa0fa3445bb6eeeec71f717b0524a05f33a83a&idx=2&mid=2247490258&scene=21&sn=da9a4a506f7af7ab7462d384194e384f#wechat_redirect
[834e9ffd9f0095c9e541ed2758596bb5.png]: /images/20220829/d117c8794360402d8f105a8a76c09ada.png
[834e9ffd9f0095c9e541ed2758596bb5.png 1]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44eff3cb3366e59cb9250dda32a3c27e1287dda6356863978927f05c13b9ee07fdb58ac31a&idx=1&mid=2247490250&scene=21&sn=6699232203bf9dd2ed53779a8395f5a7#wechat_redirect
[41b384c5923be7e7637be28549be43e1.png]: /images/20220829/b9568fb958a14369a857d12a10e0498e.png