Java8应用young gc时间过长

  • Z时代
  • 2024-01-10
  • 分类：问答

问题描述

求教各位大神，Java 8应用young gc时间过长，平均耗时接近100ms，偶尔能到1.5s
使用垃圾收集器parNew + CMS，几乎没有触发过CMS gc
使用框架spring + mybatis + dubbo + rocketmq
JVM参数：
-server -Xmx5g -Xms5g -Xmn1g -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=512m -Xss256k -XX:SurvivorRatio=8 -XX:+PrintGCDetails -Xloggc:/opt/apps/logs/gc.log -XX:+PrintGCDateStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 -XX:+PrintReferenceGC -XX:+UnlockDiagnosticVMOptions -XX:-DisplayVMOutput -XX:+LogVMOutput -XX:LogFile=/opt/apps/logs/safepoint.log -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/apps/logs

问题出现的环境背景及自己尝试过哪些方法

首先打开了gc日志和停顿点日志
一开始怀疑是safepoint的问题，打印了safepoint日志后，发现spin + block的时间都很短，只有gc的时候vmop时间与gc日志的时间一致，都能到1s多，排除了安全点问题
后来怀疑是finalReference的回收问题，添加了JVM参数打印各类refenrence的回收时间，都非常短，与gc耗时不在一个量级，排除finalize

相关代码

以下是gc日志
图片描述
图片描述
图片描述

回答：

你设置了1G的年轻代，我觉得怎么样都会gc时间长，
而且我看你总占用才 1G，
是不是可以把JVM内存设置小一点，

update:
搜了搜一些博客：
https://www.cnblogs.com/sunzh...
感觉确实耗时比较多，而且也不是安全点原因，不知道你的机器核数是多少，我注意到你没设置ParallelGCThreads，不知道有几条线程用于paraNew的回收，要不你jstack下看看，

回答：

年轻代一直回收说明一直在频繁创建新的对象，建议做个堆dump看看内存对象情况，可能是哪里代码写了循环一直创建对象，要是可以优化就先从代码层面优化。若内存对象都正常的话就把年轻代内存放小一点，这样回收时间短些，用户感知卡顿效果会好些。

回答：

问题找到了，是容器的原因。
背景信息没补充完全，应用是跑在docker里的，jstack看了下，新生代的gc线程有54条，但是容器给的配置只有6核，所以可以确认JVM拿错了CPU的核心数，拿到的是物理机的核心数。增加了参数-XX:ParallelGCThreads=6 -XX:ConcGCThreads=6，现在的新生代收集时间基本稳定在50ms以内。

以上是 Java8应用young gc时间过长 的全部内容， 来源链接： utcz.com/qa/257075.html

回到顶部