依赖包中System.gc()导致Full GC

1、问题发现

??????Prometheus报警live服务的某个节点Old GC过多,需要排查。

2、问题分析


?????? 查看Prometheus,发现这个节点在11点18分到11点28分,仅仅10分钟内,进行了5次Full GC,根据经验(这样说可能有点扯淡),应该是某个特定接口导致的。

3、使用GCViewer分析GC日志


??????从图中可以看到,在发生Full GC的时间段内,老年代的使用不到200M,老年代的总大小为760多M。很显然,这个不是由于内存不够导致的。

4、查看GC原因


?????? 可以看到5次GC的原因都是System.gc(),说明代码中调用了方法System.gc()(当然可能是业务同学自己写的代码,也可能是依赖包中的)。

5、在ELK中查看该服务在该时间段内的调用情况


?????? ELK日志显示可能是导出Excel导致(历史原因:严格来讲,线上服务不应该提供这种导出功能,这部分功能正在慢慢向大数据团队迁移,但是还没迁移完)

6、查看代码

??????根据日志信息查看代码发现确实是导出Excel操作导致,依赖包中的jxl.read.biff.WorkbookParser类中,强制使用了方法System.gc()进行GC。

原文地址:https://www.cnblogs.com/cuizhiquan/p/11537678.html

时间: 2024-10-07 14:13:05

依赖包中System.gc()导致Full GC的相关文章

spring boot中装配依赖包中的@Configuration

org.springframework.boot.autoconfigure.EnableAutoConfiguration=indi.cyh.jdbctool.modle.DbConfig https://blog.csdn.net/SkyeBeFreeman/article/details/96291283 org.springframework.boot.autoconfigure.EnableAutoConfiguration=\indi.cyh.jdbctool.modle.DbCon

maven(android-maven-plugin3.8.0)打包apk无法启动,apklib依赖包的资源索引出错(R文件与主模块冲突)问题解析

近期在用maven,遇到了一个问题,用maven打出的apk有问题无法启动,但是用idea打包的就是正常的. 日志中显示的问题是,一个apklib形式的依赖包中的一个资源出现了问题.反编译对比maven包和idea包,找到了问题所在. 假设: 主模块包名为com.android.main apklib依赖包包名为com.android.apklib 出问题的资源(layout)名为MyView 问题: apk打包后apklib依赖包的资源文件会与主模块的资源整合到一起,依赖包引用资源实际上是在主

Java中System.gc()和Runtime.getRuntime().gc()

(1) GC是垃圾收集的意思(Gabage Collection),内存处理是编程人员容易出现问题的地方,忘记或者错误的内存回收会导致程序或系统的不稳定甚至崩溃,Java提供的GC功能可以自动监测对象是否超过作用域从而达到自动回收内存的目的,Java语言没有提供释放已分配内存的显示操作方法. (2) 对于GC来说,当程序员创建对象时,GC就开始监控这个对象的地址.大小以及使用情况.通常,GC采用有向图的方式记录和管理堆(heap)中的所有对象.通过这种方式确定哪些对象是"可达的",哪些

jvm中导致Full GC的情况

导致Full GC一般由于以下几种情况: 1)老年代空间不足 调优时尽量让对象在新生代(细分为Eden和幸存区)GC时被回收.让对象在新生代多存活一段时间(增大新生代内存或者调高晋升老年代的门槛)和不要创建过大的对象及数组避免直接在老年代创建对象 2)新生代设置过小  一是新生代GC次数非常频繁,增大系统消耗:二是导致大对象直接进入老年代,占据了老年剩余空间,诱发Full GC 3). 新生代设置过大 一是新生代设置过大会导致老年代过小(堆总量一定),从而诱发Full GC:二是新生代GC耗时大

Spark处理数据出现大量GC导致处理性能变慢的原因及解决方案

Spark应用程序处理的大数据多是运行于JVM上的,经常要面对GC优化问题.下面给出由于Linux系统原因导致的GC耗时异常的处理方式: 打开Spark的GC日志,在spark-env.sh文件中的SPARK_JAVA_OPTS参数上添加 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps 如果每次GC回收的量基本相同,但是在某一时间点,耗时异常大,这种情况下,有两种可能: 1.GC收集对象所在内存被swap了 2.GC线程进入IO等待状

System.gc()与Runtime.gc()的区别

(1) GC是垃圾收集的意思(Gabage Collection),内存处理是编程人员容易出现问题的地方,忘记或者错误的内存回收会导致程序或系统的不稳定甚至崩溃,Java提供的GC功能可以自动监测对象是否超过作用域从而达到自动回收内存的目的,Java语言没有提供释放已分配内存的显示操作方法. (2) 对于GC来说,当程序员创建对象时,GC就开始监控这个对象的地址.大小以及使用情况.通常,GC采用有向图的方式记录和管理堆(heap)中的所有对象.通过这种方式确定哪些对象是"可达的",哪些

一次显式GC导致的High CPU问题处理过程

项目现场反馈系统出现性能问题,具体表现为:所有的客户端响应极其卡顿. 第一反应推测,难道是DB层面出现阻塞?检查v$session会话状态及等待类型未见异常,应该可以排除DB层面原因导致的可能. 继续检查,难道是应用服务器层面出现资源瓶颈?检查任务管理器,w3wp.exe进程占用在10%-20%之间,整体占用也在30%以下(项目现场服务器环境为某通运营商云服务器,此处有坑),内存占用不到4G,w3wp.exe只占了1G多点,服务器的内存好像是48G这个应该也不是瓶颈.继续...难道是网络?显然不

maven项目,去除jar包中的不想要的依赖关系(Document root element "beans", must match DOCTYPE root "null". )

maven dependencies中并不会删除 以下方法maven dependencies中并不会删除,可能程序引入的时候,会去掉这种依赖(猜的) 解释: 就是说项目中要用到某一个a.jar包,通过maven引入了之后,也自动的导入了该jar包所依赖的包,这里就会存在一个问题, 如果a.jar包依赖b.jar这个项目的1.0版本,可是我的项目中已经有b.jar这个项目2.0的版本了,这里就会造成冲突,解决的办 法是去除a.jar包依赖b.jar这个项目的1.0版本的依赖关系,让项目使用我已有

maven项目,去除jar包中的不想要的依赖关系

解释:就是说项目中要用到某一个a.jar包,通过maven引入了之后,也自动的导入了该jar包所依赖的包,这里就会存在一个问题,如果a.jar包依赖b.jar这个项目的1.0版本,可是我的项目中已经有b.jar这个项目2.0的版本了,这里就会造成冲突,解决的办法是去除a.jar包依赖b.jar这个项目的1.0版本的依赖关系,让项目使用我已有的包. 最近搭一个springmvc4.x的maven环境,由于要用到webserice,打算整合jersey做,在导入jersey-spring.jar时出