你们要的线上GC问题案例来啦

最新推荐文章于 2022-11-28 11:14:23 发布

编了个程

最新推荐文章于 2022-11-28 11:14:23 发布

阅读量302

点赞数 1

文章标签： java 编程语言 jvm oom 大数据

本文链接：https://blog.csdn.net/yasinshaw/article/details/115587301

版权

本文分享了四个真实的线上GC问题案例，包括Young GC频繁、Young和Old GC都频繁、接口线程池满伴随Full GC以及应用启动时Full GC频繁。通过对监控图表的分析和Heap Dump排查，找到了问题根源并提供了相应的解决方案，如调整Guava Cache配置、优化SQL操作、减少日志打印和调整JVM参数等。

摘要由CSDN通过智能技术生成

点击↑上方↑蓝色“编了个程”关注我~

这是Yasin的第 45 篇原创文章

Y说

今天上午被阿里罚款的消息刷屏了。这个事情也发酵很长一段时间了，今天算是尘埃落定吧。听说因为这事股价蒸发了一千亿美金。。。

很快官方就发表了《致客户和公众的一封信》，态度可以说是非常“认真”且“正确”了。

对我等升斗小民来说，这事应该影响不大。我们能做的，就是把自己的工作尽力做好，少写点bug~

当然，也希望公司越来越好，国家和社会也越来越好。

先推荐一篇好文

最近写了几篇关于GC的文章，主要是因为线上有一些关于GC的问题，所以想顺便总结一波，梳理一下GC的一些知识点和排查思路。

之前有读者留言说能不能写一篇实战经验方面的，这不就来了吗~

我们项目上用到的主要还是CMS + ParNew的组合。所以重点看的资料也是这方面的。

在学习的过程中，也拜读了美团技术团队的这篇文章《Java中9种常见的CMS GC问题分析与解决》。这篇文章质量非常高，从理论知识，源码分析，到常见的GC问题案例，囊括了分析路径、根因、调优策略等等内容，非常详尽且全面，尤其是最后部分的处理流程SOP和根因鱼骨图，非常nice。「墙裂推荐，值得一读」！！！

知道大家喜欢现成的，所以我手动copy了这两张图过来，有需要的自取：

^排查问题SOP^

^根因鱼骨图^

GC问题案例

我遇到的案例可能没有上面文章作者那么丰富，但也是真实遇到的几个案例，所以借这篇文章分享出来，大家可以参考参考，避免踩类似的坑。

案例1 Young GC频繁

之前有个任务会频繁地重复调用一个接口。所以用guava cache做了一个简单的内存缓存。结果上线后发现经常收到Young GC频繁的告警，时间跟这个任务的启动时间也比较吻合。

通过监控看到的GC图大概是这样：

^案例1^

可以看到，Young GC的次数会在某一个时间点飙升。同时伴随着Old区域内存快速升高，最后会触发一次Full GC。

根据这个情况，可以肯定的是由于本次代码改动引起的。通过Heap Dump分析后发现，占用内存较大的是一个guava cache的Map对象。

查找代码发现，使用guava cache的时候，没有设置最大缓存数量和弱引用，而是设置了一个几分钟的过期时间。而这个任务的量又比较大，到线上后很快就缓存了大量的对象，导致频繁触发Young GC，但又由于有引用GC不掉（这个从Survivor区的内存大小图像可以推测），所以慢慢代数比较多的对象就晋升到了老年代，后面老年代内存到达一定阈值引发Full GC。

后面通过设置最大缓存数量解决了这个问题。又积累了一个宝贵的经验，完美！

案例2 Young GC和Old GC都频繁

在线上灰度环境中发现收到Young GC和Old GC频繁的告警。监控看到的GC图大概长这样：

^案例2^

根据GC图大概可以看出来，Young GC和Old GC都非常频繁，且每次都能回收走大量的对象。那可以简单地推测：确实是产生了大量的对象，且极有可能有一部分大对象。小对象引发的Young GC频繁，而大对象引发了Old GC频繁。

排查下来也是一段代码引起的。对于一个查询和排序分页的SQL，同时这个SQL需要join多张表，在分库分表下，直接调用SQL性能很差，甚至超时。于是想了个比较low的办法：查单表，把所有数据查出来，在内存排序分页。用了一个List来保存数据，而有些数据量大，造成了这个现象。用Heap Dump分析，也印证了这个猜测，List类型的对象占用了大量的空间。

案例3 接口线程池满和Full GC

这是一个报接口线程池满的问题。但每次都会在同一时间Full GC。监控图大概长这样：

^案例3^

从时间上来看，先是Java线程数量飙升，然后触发Full GC。后面重启后，Java线程数量恢复正常水位。

这里涉及到一个冷知识：一个Java线程默认会占用多少内存？

->
这个参数可以控制：-XX:ThreadStackSize。在64 位的Linux下, 默认是1 MB（这个说法也不全对，还是取决于栈深度）。Java 11对这个有一个优化，可以减少内存占用。详情可以参考这篇文章：https://dzone.com/articles/how-much-memory-does-a-java-thread-take
<-

排查下来根因是这个应用还是使用的Log4j 1，而Log4j 1有性能问题，在高并发下，下面这段代码的同步块可能会引起大量线程阻塞：

void callAppenders(LoggingEvent event) {
    int writes = 0;

    for(Category c = this; c != null; c=c.parent) {
        // Protected against simultaneous call to addAppender, removeAppender,...
        synchronized(c) {
            if(c.aai != null) {
                writes += c.aai.appendLoopOnAppenders(event);
            }
            if(!c.additive) {
                break;
            }
        }
    }

    if(writes == 0) {
        repository.emitNoAppenderWarning(this);
    }
}

解决办法就是减少日志打印，升级日志框架到Log4j 2或者Logback。

案例4 应用启动时Full GC频繁

这个是较早的一个案例了，GC图已经找不到了。

但引发Full GC频繁的大概就这几种可能性：

调用System.gc()
Old区空间不足
永久代/元空间满

根据代码和GC图排除了前面两种可能性，那就是元空间满了。在Java 8中，XX:MaxMetaspaceSize是没有上限的，最大容量与机器的内存有关；但是XX:MetaspaceSize是有一个默认值的：21M。而如果应用需要进元空间的对象较多（比如有大量代码），就会频繁触发Full GC。解决办法是可以通过JVM参数指定元空间大小：-XX:MetaspaceSize=128M。