每小时进行一次FullGC

原创 已于 2024-07-31 09:30:59 修改 · 1.3k 阅读 · 10 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#java #jmx #FullGC #JMX导致FullGC #每小时FullGC

于 2023-03-26 09:51:43 首次发布
本文分析了因JMX开启导致应用每小时自动执行FullGC的问题。通过代码排查和JDK源码分析，发现RMIGCDaemon线程周期性调用System.gc()。提供了三种解决方案，包括调整gcInterval参数、禁用RMIFullGC和禁用显式GC调用。

1. 问题描述

  在排查接口响应慢的过程中，通过prometheus监控系统看到JVM每隔一小时进行一次FullGC(非常准时)，我们都知道FullGC是STW的，所以有必要进行深入排查。

2. 问题分析

  1. 每小时准时进行一次FullGC，我首先怀疑可能是应用本身有定时任务显式调用 System.gc() 进行主动FullGC，排查代码后没有发现主动调用System.gc()，查看gc.log后发现存在System.gc()调用，查看其他应用存在同样的问题，看来是个通用问题；
  2. jstack -l {pid} 查看应用进程的堆栈信息，发现有一个 RMI GC Daemon 和 RMI RenewClean 的 守护线程，应用是开启JMX的，所以会有这些进程；
    在这里插入图片描述
    在这里插入图片描述
  3. 通过进程堆栈信息，查看JDK源码(jdk1.8.0_242)，发现 GC.java 中 Daemon 静态内部类有一个自旋进行 System.gc()；DGCClient.java 中 sun.rmi.dgc.client.gcInterval 可以配置FullGC时间间隔默认3600秒。
    在这里插入图片描述
    在这里插入图片描述

结论：
  由于应用开启了JMX对接监控系统，开启JMX后JDK默认会每小时进行一次 System.gc()；

3. 解决方法

解决方法1：添加 -Dsun.rmi.dgc.client.gcInterval 属性并配置合理的值，默认是3600000毫秒(1小时)，可以适当调大;

解决方法2：禁用RMI FullGC，添加-Dsun.rmi.dgc.client.gcInterval属性并将值设置为 Long.MAX_VALUE即 9223372036854775807；

解决方法3：禁止显示调用System.gc()，添加JVM选项 -XX:+DisableExplicitGC，不建议添加此JVM选项禁用显式调用.System.gc()，影响范围过大，且某些三方组件依赖System.gc()。

线上服务器一小时一次fullGc排查
不良IP的博客
02-17 801
现状： -Xms：8G -Xmx:8G -Xmn:2G 下面是gc日志输出的配置： CommandLine flags: -XX:CMSInitiatingOccupancyFraction=75 -XX:+ExplicitGCInvokesConcurrent -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/logs/Heap...
JVM 菜鸟进阶高手之路六（JVM每隔一小时执行一次Full GC）
热门推荐
最简单的东西，往往包含了最复杂的实现。
08-03 1万+
上次分析详细地址在：http://blog.youkuaiyun.com/lirenzuo/article/details/76257526 以为结束了上次那个知识才想rmi问题，其实本次问题不是该问题但是也会有sys.gc fullgc问题。 查看GC统计汇总情况： jstat -gcutil pid  3s 30 参考gc，发现大概一小时运行一次FGC，特别奇怪，笨神一看这样的问题
jQuery 一次定时器_为什么JVM每隔一小时执行一次Full GC?
weixin_39808143的博客
11-21 379
随着接口自动化监控的完善，线上大多数的接口都被自动化监控系统接入，因此开发、测试人员可以及时的了解API的健康情况，监控内容包括检查API的状态码是否正常、返回的内容断言是否成功等，异常的接口会对外发出报警信息，从某个时间周期开始我们发现了报警内容的一些异常情况，每天都会收到一些接口状态码为502的报警。报警信息由自动化监控系统发给钉钉报警群根据报警的时间我们查了对应服务的日志，并没有发...
每小时一次定时FullGC问题解决
Laiix的博客
03-15 3940
原文地址：http://www.eussi.top/view/16 一、问题描述 生产运行跟踪过程中，遇到FullGC次数过多的问题。于是在测试环境将GC日志详细打印出来进行重现，主要表现如下： YGC正常，当Eden区即将满之后进行YGC FGC出现的现象很奇怪，老年代内存还有相当大的空间，整个年轻代装进老年代都不是问题，但是很奇怪却出现了FGC。 长时间运行下去老年代内存也没有因为越积越多出...
JVM每小时执行一次FULL GC问题
吖脖（博）
09-06 707
JVM每小时执行一次FULL GC问题参考文章链接：http://liuxi.name/blo g/20160608/jvm-full-gc-hourly.html
java每隔一小时fullgc_JVM菜鸟进阶高手之路六（JVM每隔一小时执行一次Full GC）
weixin_35843035的博客
02-28 1178
以为上次问题是rmi的问题就此结束了，但是问题并没有结束，其实本次问题不是rmi问题导致的，但是rmi也的确可能会有sys.gc fullgc问题。查看GC统计汇总情况：jstat -gcutil pid 3s30参考gc，发现大概一小时运行一次FGC，特别奇怪，笨神一看这样的问题就知道是system gc导致的System.gc()的默认效果是引发一次stop-the-world的full G...
问题解决：Full GC固定10小时执行一次问题解决记录
Sucreyy的博客
12-24 1501
文章目录一.问题描述二.问题排查1.问题猜测2.源码分析三.解决办法 一.问题描述 环境：JDK1.8、CentOS 6.9、容器undertow、Spring boot 1.5.8 最近线上运维，发现gclog里打印了很多Full GC的日志，通关gclog前面的时间可以看到间隔时间都是在10小时左右。 大概看了一下都是调用了System.gc()产生的Full GC，然后查看堆栈信息还远...
记一次频繁fullgc排查到解决全流程复盘
zhang09090606的博客
08-07 5451
阿里云oss文件上传导致的频繁fullgc问题排查到解决全流程复盘
一次FullGC问题的定位
qq_28112995的博客
11-21 1059
问题背景 一次在查看服务器的gc状态的时候发现，fgc的次数过高(200多次)且远大于ygc(3次)，在线上环境和测试环境都有同样的现象，长时间的观察发现ygc的次数基本不变，fgc隔段时间后就会增加一次(ygc的平均时间：27ms, fgc的平均时间：58.28ms， 因为内存几乎没什么数据，fgc的时间不是很特别长) 问题分析 查看服务器启动期间在线人数和内存使用情况，可以看到在线人数很少，且内存的占用很低，排除内存泄露导致的JVM内存占用过高而触发fgc的原因 通过jstat -gccause
一次让人难以忘怀的排查频繁Full GC过程
huaweitman的专栏
03-15 8863
我们的Java应用因频繁FULL GC导致性能降低很多，经过多人的定位也没有结论，于是我自主请命，经过一天的研究终于搞定了，现把经验与大家共享，相关的gc日志如下： 4.758: [Full GC [PSYoungGen: 464K->0K(71936K)] [PSOldGen: 37949K->33994K(68672K)] 38413K->33994K(140608K) [PSPermGen
FullGC多久一次合适
qq_30246135的博客
03-17 2592
1.yongGC 执行时间不超过50ms 执行频率不小于10s每次。2.FullGC 执行时间不超过1s执行频率不低于10分钟。
java每隔一小时fullgc_tomcat每隔一小时full gc的问题
weixin_39695701的博客
02-28 465
关于gc信息的收集，除了在启动时设置gclog选项，对于已经启动的java进程，也可以通过jstat去查看gc发生的原因。$ jstat -gccause java_pid 1sS0 S1 E O P YGC YGCT FGC FGCT GCT LGCC GCC0.00 100.00 ...
Java工程定时执行Full GC（每隔1h）
weixin_39195030的博客
07-07 2124
运维侧反馈阿里云ARMS监控显示服务频繁执行Full GC，且执行曲线很规律。查询gc.log日志文件显示Full GC有规律的每1h执行一次，且通过System.gc()显示触发。 通过开发环境验证此问题。 1、安装arthas查询是谁调用了System.gc https://github.com/alibaba/arthas/issues/20 可以看到该方法是由sun.misc.GC创建GC Daemon线程调用。 执行jstack pid 也可以佐证。 （关于这块目前仍然不是很清
Full GC 频率优化实战
vivo互联网技术
04-24 806
本文介绍了游戏业务使用MAT和GC日志等工具对 Full GC频率进行优化的过程。
fullgc一小时发生一次的原因
jueshengtianya的专栏
01-11 3197
问题：之前在线上遇到过一个问题，每一小时都会执行fullgc，但是此时的堆内存大小是足够的。 分析： 当前我的tomcat的版本是6.0.35，此时tomcat有这样的配置： 6.0.35的org.apache.catalina.core.JreMemoryLeakPreventionListener的261行有如下代码 if (gcDaemonProtection) {
full gc优化时间
oZiSeFengYe1的专栏
04-24 521
Full GC 执行频率不算频繁，不低于 10 分钟 1 次;Minor GC 执行不频繁，约 10 秒一次;Minor GC 执行时间不到 50ms;Full GC 执行时间不到 1s;
jvm gc合适时间
oZiSeFengYe1的专栏
07-08 3273
1.yongGC 执行时间不超过50ms 执行频率不小于10s每次。2.FullGC 执行时间不超过1s执行频率不低于10分钟。
echarts定时切换数据柱形图
xn的博客
10-20 793
动图有点丑，大概是这么个意思； <template> <div id="scatterAqi" :style="{ width: '100%', height: '100%' }"></div> </template> <script> import echarts from "echarts"; import { EleResize } from "@/assets/js/esresize.js"; export default { .
full GC 一天11次有问题吗
最新发布
10-01
一天发生 **11 次 Full GC** 是否有问题，取决于你的应用类型、堆内存大小、业务负载以及每次 Full GC 的持续时间和影响。但从一般生产环境的稳定性与性能角度来说，**一天 11 次 Full GC 是偏高的，通常意味着存在潜在问题**，需要深入排查。 --- ### ✅ 正常情况下的 Full GC 频率 - 理想情况下：Full GC 应该很少发生，比如几天一次甚至更少。 - 轻量级服务或中等负载应用：每月几次或每周一次是可接受的。 - 如果每天超过 **5~6 次 Full GC**，就需要引起注意。 - **11 次/天 ≈ 每 2 小时一次**，这在大多数场景下属于 **异常频繁**。 --- ### ❌ 可能的问题原因 | 原因 | 说明 | |------|------| | **老年代空间不足** | 对象过早晋升到老年代，或大对象直接进入老年代导致频繁回收。 | | **内存泄漏（Memory Leak）** | 比如缓存未清理、静态集合持有对象引用等，导致对象无法被回收，最终填满老年代。 | | **堆设置不合理** | 堆太小，尤其是老年代太小；或者新生代比例过大，导致老年代容易满。 | | **CMS 或 G1 配置不当** | 使用 CMS 但触发时机太晚，G1 回收不及时等。 | | **大量大对象分配** | 如缓存大数组、大 Map、文件读取未流式处理等。 | | **显式调用 System.gc()** | 第三方库或代码中手动触发 GC，可通过 `-XX:+DisableExplicitGC` 禁用。 | --- ### 🔍 如何诊断？ #### 1. 查看 GC 日志（关键） 启用并分析 GC 日志： ```bash -XX:+PrintGC # 启用基本GC日志 -XX:+PrintGCDetails # 更详细信息 -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -Xloggc:/path/to/gc.log ``` 然后使用工具分析： - **[GCViewer](https://github.com/chewiebug/GCViewer)** - **[gceasy.io](https://gceasy.io)**（上传 gc.log 即可可视化分析） 关注以下指标： - 每次 Full GC 前后老年代使用量（Old Gen Usage） - Full GC 是否能有效回收内存（回收后是否仍很高？） - 是否有 `System.gc()` 调用？ - Full GC 时间长短（是否造成长时间 STW？） #### 2. 使用 jstat 实时监控 ```bash jstat -gcutil <pid> 1000 10 ``` 观察 `FGC` 列增长速度，结合时间判断频率。 #### 3. 使用 MAT 或 JProfiler 分析堆 dump 生成堆转储文件： ```bash jmap -dump:format=b,file=heap.hprof <pid> ``` 用 [Eclipse MAT](https://www.eclipse.org/mat/) 打开，查找： - 最大对象是什么？ - 是否存在重复的大对象？ - 是否有可疑的集合类（HashMap、List）不断增长？ --- ### ✅ 示例：如何减少 Full GC 假设你使用的是 **G1GC**，可以优化 JVM 参数： ```bash # 示例JVM参数（根据实际情况调整） -Xms8g -Xmx8g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:G1HeapRegionSize=16m -XX:InitiatingHeapOccupancyPercent=45 # 提前启动并发标记 -XX:+G1UseAdaptiveIHOP # 自适应IHOP -XX:-DisableExplicitGC # 禁止System.gc() -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dumps ``` > 关键点：让 G1 在老年代还没满之前就开始混合回收，避免退化为 Full GC。 --- ### 🛠️ 排查流程建议 1. **确认是否真的是“Full GC”** 检查日志中是 `Full GC` 还是 `Major GC`（有些日志把 G1 Mixed GC 也误标为 Full GC）。真正的 Full GC 是 **Serial Old 或 Parallel Old 的 stop-the-world 全堆回收**。 2. **检查是否有 System.gc()** ```bash -XX:+PrintGCApplicationStoppedTime -XX:+PrintReferenceGC ``` 查看是否由显式 GC 引起。 3. **查看老年代增长趋势** 若老年代内存呈线性上升，极可能是内存泄漏。 4. **对比不同时间段的堆 dump** 抓取两次间隔几小时的堆 dump，做差异对比（MAT 中的 "Compare Basket"），看哪些对象在持续增加。 --- ### ✅ 总结 | 情况 | 是否正常 | |------|----------| | 一天 11 次 Full GC + 每次回收效果差（内存没释放） | ❌ 严重问题，可能存在内存泄漏 | | 一天 11 次 Full GC + 老年代很快填满 | ❌ 需优化对象生命周期或堆大小 | | 一天 11 次 Full GC + 来自 System.gc() | ⚠️ 可禁用 | | 一天 11 次 Full GC + 实际是 G1 Mixed GC（非真正 Full GC） | ✅ 可接受，但需确认 STW 时间 | > 🔴 **结论：一天 11 次 Full GC 很可能有问题，必须结合 GC 日志和堆分析进一步确认。** --- ###
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值