性能文章>依赖包滥用System.gc()导致的频繁Full GC>

依赖包滥用System.gc()导致的频繁Full GC原创

2年前
770611

介绍

业务部门的一个同事遇到个奇怪的 Full GC 问题,有个服务迁移到新的应用后,一直频繁 Full GC。新应用机器的配置是 4c 8g,老应用是 4c 4g,老应用 GC 都很正常,并且代码没有变更,所以比较奇怪。

现象

问题的现象是,从监控图上看一直有大量的 Full GC
15782993791.jpg

排查

遇到这个问题,一般都是先看看各个区的内存占用情况:
15782997231.jpg
1578299740.jpg
从监控图上看 Old Gen、Young Gen、Perm Gen,没什么问题,不会触发 Full GC,当然这里看各个 Gen 是否会触发 Full GC 需要结合 JVM 参数配置来看。

顺便也看了下 GC 日志,一直狂暴 CMS GC 日志,而且可以看到老年代使用空间也不大,细心可以发现,大量的 CMS GC 中夹杂着 Young、Perm 区的回收,所以其实是 Full GC。GC 日志如下:
15782997921.jpg

老应用的 JVM 参数配置
1.jpg
新应用的 JVM 参数配置
2.jpg
通过上面的观察,再根据一般触发 CMS GC 几个可能性:

  • Old Gen 使用达到一定的比率,默认为92%,这里看 CMSInitiatingOccupancyFraction=80%,而实际才使用 2%(看监控图表)不到,所以排除这种情况。

  • 配置了 CMSClassUnloadingEnabled,且 Perm Gen 的使用达到一定的比率默认为 92%,这里看 CMSInitiatingPermOccupancyFraction=80%,而实际才使用 30%(看监控图表)不到,所以排除这种情况。

  • 配置了 ExplictGCInvokesConcurrent 且未配置 DisableExplicitGC 的情况下显示调用了 System.gc()。

  • Hotspot 自己根据估计决定是否要触法,如 CMS 悲观策略,这类可以通过 GC 日志分析。

大致判断很可能是 System.gc() 导致的问题,但是怎么定位调用 System.gc() 的代码呢?
当时就想如果是 System.gc() 引起的频繁 Full GC,jstack 线程堆栈应该能看到一些信息,果不其然,确实通过线程堆栈找到了。
3.jpg
jstack 作用非常大,很多问题都能从这里发现,而且比较轻量,对应用基本无影响。某次的 jstack 信息只代表那个时刻的线程堆栈,有时只看一个 jstack 信息可能看不出什么问题,一般可以多 jstack 几次,然后对比去看,基本就能发现一些问题。
(当然该问题,也可能不是频繁的 Full GC,可能通过 jstack 定位不到问题,可以 jstat -gccause pid 1000,来查看 gc 原因。)

很明显,是由于 jxl 这个包中的 close 方法显示调用了 System.gc() 导致的问题。

跟了下代码,自然确实存在这段代码,不过有个设置开关,可以 disable 这个功能,所以在使用的时候可以设置 setGCDisabled(true),关闭触发 System.gc()。
4.jpg
但是为什么老应用没有问题呢,主要是因为它 -XX:+DisableExplicitGC,屏蔽了 System.gc() 动作,新应用的 JVM 没有这个配置。

可能大家还有个疑问,都知道 System.gc() 会触发 Full GC,那为什么一直进行 CMS GC(通过GC日志)呢?
主要是因为这个参数 -XX:+ExplicitGCInvokesConcurrent,打开此参数后,会做并行 Full GC,只有配置 -XX:+UseConcMarkSweepGC 这个参数,该参数才会生效。因此,System.gc() 时 Old 区会进行 CMS GC,可提高 Full GC 效率。

总结

尽量减少显示使用 System.gc() 来触发 Full GC,这会导致频繁 Full GC,非常影响应用性能。

分类:标签:
请先登录,查看1条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

不起眼,但是足以让你有收获的JVM内存分析案例
分析 这个问题说白了,就是说有些int[]对象不知道是哪里来的,于是我拿他的例子跑了跑,好像还真有这么回事。点该 dump 文件详情,查看相关的 int[] 数组,点该对象的“被引用对象”,发现所
从一起GC血案谈到反射原理
前言 首先回答一下提问者的问题。这主要是由于存在大量反射而产生的临时类加载器和 ASM 临时生成的类,这些类会被保留在 Metaspace,一旦 Metaspace 即将满的时候,就会触发 Fu
关于内存溢出,咱再聊点有意思的?
概述 上篇文章讲了JVM在GC上的一个设计缺陷,揪出一个导致GC慢慢变长的JVM设计缺陷,可能有不少人还是没怎么看明白的,今天准备讲的大家应该都很容易看明白 本文其实很犹豫写不写,因为感觉没有
协助美团kafka团队定位到的一个JVM Crash问题
概述 有挺长一段时间没写技术文章了,正好这两天美团kafka团队有位小伙伴加了我微信,然后咨询了一个JVM crash的问题,大家对crash的问题都比较无奈,因为没有现场,信息量不多,碰到这类问题我
又发现一个导致JVM物理内存消耗大的Bug(已提交Patch)
概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12),发现一个系统老是被OS Kill掉,是内存泄露导致的。在查的过程中,阴差阳错地发现了JVM另外的一个Bug。这个B
JVM实战:优化我的IDEA GC
IDEA是个好东西,可以说是地球上最好的Java开发工具,但是偶尔也会卡顿,仔细想想IDEA也是Java开发的,会不会和GC有关,于是就有了接下来对IDEA的GC进行调优 IDEA默认JVM参数: -
不起眼,但是足以让你收获的JVM内存案例
今天的这个案例我觉得应该会让你涨姿势吧,不管你对JVM有多熟悉,看到这篇文章,应该还是会有点小惊讶的,不过我觉得这个案例我分享出来,是想表达不管多么奇怪的现象请一定要追究下去,会让你慢慢变得强大起来,
如何通过反射获得方法的真实参数名(以及扩展研究)
前段时间,在做一个小的工程时,遇到了需要通过反射获得方法真实参数名的场景,在这里我遇到了一些小小的问题,后来在部门老大的指导下,我解决了这个问题。通过解决这个问题,附带着我了解到了很多新的知识,我觉得
1
1