CMS垃圾回收和线上Full GC排查

最新推荐文章于 2025-05-29 12:46:34 发布
转载 最新推荐文章于 2025-05-29 12:46:34 发布 · 429 阅读 · 0 ·
CC 4.0 BY-SA版权
原文链接：https://segmentfault.com/a/1190000015182001
文章标签：

#java #运维 #数据结构与算法

本文深入解析了ConcurrentMarkSweep (CMS) 垃圾回收算法的工作原理，包括其各个阶段的特点与流程，并探讨了在实际部署中遇到的FullGC异常问题及解决方案。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

背景

我们上线Java服务的时候需要对其配置一些JVM参数，如堆空间大小、虚拟机栈大小、垃圾回收算法。对于年轻代和老年代我们可以配置不同的垃圾回收算法。在一些对rt要求很高的场景，服务不能有长时间的卡顿，CMS就可以运用于此场景。

Concurrent Mark Sweep,是一款基于并发、使用标记清除算法的垃圾回收算法，只针对老年代进行垃圾回收。CMS收集器工作时，GC工作线程和用户线程可以并发执行，以达到降低STW时间的目的。

开起VM选项-XX:+UseConcMarkSweepGC，表示对老年代的回收采用CMS。

前置知识

STW

首先，我们需要厘清一个概念，即只有标记阶段才需要STW。标记完成以后，需要清除的对象已经确定，无论此时是否产生新的垃圾，都不影响对这些对象的清理。也就是说，清除阶段是可以设计成和用户线程并发执行的。

JVM在暂停的时候，需要选准一个时机，由于JVM系统运行期间的复杂性，不可能做到随时暂停，因此引入了安全点（safepoint）的概念：程序只有在运行到安全点的时候，才可以暂停下来。HotSpot采用主动中断的方式，让执行线程在运行期轮询是否需要暂停的标志，若需要则中断挂起。HotSpot使用了几条短小精炼的汇编指令便可完成安全点轮询以及触发线程中断，因此对系统性能的影响几乎可以忽略不计。

可达性

可达性是指，如果一个对象会被至少一个程序中的可达对象通过直接或间接的方式引用，则称该对象是可达的。更详细地说，一个对象满足一下两个条件之一，即被判定为可达的。

1.本身是根对象。根（root）是指由堆以外空间访问的对象。JVM会将以下对象标记为根：a.虚拟机栈（栈帧中的本地变量表）中引用的对象；b.方法区中的类静态属性引用的对象；c.方法区中的常量引用的对象；d.本地方法栈中JNI的引用对象。

2.被一个可达的对象引用。

CMS的几个阶段

CMS将可达性分析分解成两个阶段：a.仅扫描与根节点直接关联的对象; b.继续向下扫描完所有对象。因此，标记阶段也被拆分成两个阶段，即初始标记和并发标记。

CMS完整的收集过程如下：

  1. 初始标记（init-mark）：仅扫描与根节点直接关联的对象并标记，这个阶段必须STW, 由于跟节点数量有限，所以这个过程非常短暂。
  2. 并发标记（concurrent-marking）：与用户线程并发标记。这个阶段在初始标记的基础上继续向下追溯标记。在并发标记阶段，用户线程和标记线程并发执行，所以用户不会感受到停顿。
  3. 并发预清理（concurrent-precleaning）：与用户线程并发进行。在并发标记阶段一些对象的引用已经发生了变化，precleaning会发现这些引用关系的改变，并将存活的对象标记。举个例子：如果线程A有一个指向对象X的引用，并将该引用传递给了线程B，CMS需要记录下线程B持有了对象X，即使线程A已经不存在了。precleaning是为了减少下一阶段“重新标记”的工作量，因为remark阶段会STW。
  4. 重新标记（remark）： remark阶段会STW。如果应用正在并发运行且在不断地改变对象引用，CMS则不能准确地确定某个对象是否存活。所以CMS会在remark阶段STW，从而获取所有引用关系的改变。
  5. 并发清理（concurrent-sweeping）：清理垃圾对象，这个阶段GC线程和用户线程并发执行。
  6. 并发重置（concurrent-reset）：重置CMS收集器的数据结构，做好下一次执行GC任务的准备工作。

alt text

线上Full GC分析

线上某服务的老年代配置了CMS，但却在gc.log发现连续Full GC的问题。JVM参数配置如下：

-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=68

参数的意义是：在老年代到68%的时候，会触发一次CMS GC，应该是出现类似如下的日志：

T20:10:37.803+0800: 3246087.559: [CMS-concurrent-mark-start]
T20:10:38.463+0800: 3246088.220: [CMS-concurrent-mark: 0.661/0.661 secs] [Times: user=3.17 sys=0.56, real=0.66 secs]
T20:10:38.463+0800: 3246088.220: [CMS-concurrent-preclean-start]
T20:10:38.552+0800: 3246088.309: [CMS-concurrent-preclean: 0.069/0.089 secs] [Times: user=0.14 sys=0.04, real=0.09 secs]_</span>
T20:10:38.552+0800: 3246088.309: [CMS-concurrent-abortable-preclean-start]

但线上环境的日志却出现如下的情况：

alt text

老年代配置了900M，但却在只使用了50+M的时候触发了Full GC，而且是在短暂的时间内连续触发。

配置了CMS却触发Full GC，有以下几种可能：

  1. 大对象分配时，年轻代不够，直接晋升到老年代，老年代空间也不够，触发 Full GC（老年代还剩800+M，显然不可能）
  2. 内存碎片导致（由于CMS是基于标记清除算法的，所有会导致内存碎片，但通过grep -i "cms" gc.log，JVM尚未触发过CMS回收，所以也不存在内存碎片的说法）
  3. CMS GC失败导致（从gc.log并未找到concurrent mode failure的记录，排除）
  4. jmap -histo（人为执行该命令）

经笔者回忆，在中午快12点的时候确实登录过线上机，执行过jmap -histo:live命令，经验证，手动执行jmap -histo:live，也确实会在gc.log出现触发 Full GC的现象，问题得到验证。

原文链接

https://segmentfault.com/a/11...

系统运行缓慢，CPU 100%，以及Full GC次数过多问题的排查思路
weixin_34014555的博客
03-04 1893
2019独角兽企业重金招聘Python工程师标准>>> ...
FULL GC隐患排查 优化
森林里的一天
03-16 419
    最近其它业务线反馈统一的国际化方案容易导致FULL GC，先简单说一下国际化方案：实现了一个filter，过滤所有的http请求，将请求头信息所带的语言环境存储到session里面，然后重新实现了response，对于文案统一采用编码的防范，response输出的时候将编码根据语言环境进行替换。    这里会有一个问题，如果是请求量比较大的应用，由于session的生命周期缘故，可能会导致...
项目full gc 排查
程序猿二大爷的博客
09-29 319
full-gc 排查
JVM Full GC 频繁问题排查、优化及解决方案
最新发布
weixin_56018532的博客
05-29 1978
JVM频繁Full GC问题是Java应用性能调优中常见且重要的挑战。本文系统地分析了导致频繁Full GC的各种原因，包括内存泄漏、高并发、大对象分配、内存碎片化等，并提供了详细的排查方法和优化建议。JVM参数调优：合理配置堆内存大小、分代比例、垃圾收集器等参数，使其适合应用特性。代码层面优化：减少不必要的对象创建，避免内存泄漏，优化数据结构和算法，合理管理资源。架构层面优化：实现流量控制，优化线程模型，改进数据处理方式，提高系统整体效率。监控与预警：建立完善的监控体系，及时发现潜在问题，防患于未然。
CMS与FullGC
Jak的博客
11-19 2021
Full GC：Full GC是一种非并发的垃圾回收算法，它会停止应用程序的所有线程，对整个堆空间进行垃圾回收。CMS GC：CMS GC是一种并发的垃圾回收算法，它在运行期间与应用程序线程并发工作，尽可能减少垃圾回收对应用程序的影响。需要注意的是，Full GC的发生通常会导致较长的停顿时间，因为它会停止应用程序的所有线程进行垃圾回收。在JVM中，CMS GC和Full GC的发生顺序可以是不确定的，取决于垃圾回收器的配置和堆内存的使用情况。而Full GC会同时回收年轻代和老年代的垃圾对象。
full gc排查思路
山楂片的博客
05-12 4259
清楚排查问题时能使用哪些工具 公司的监控系统：大部分公司都会有，可全方位监控JVM的各项指标。 JDK的自带工具，包括jmap、jstat等常用命令： 查看堆内存各区域的使用率以及GC情况 jstat -gcutil -h20 pid 1000 查看堆内存中的存活对象，并按空间排序 jmap -histo pid | head -n20 dump堆内存文件 jmap -dump:format=b,file=heap pid ...
线上问题——频繁 Full GC 问题的排查思路
longool的博客
12-21 1567
启用 GC 日志分析 GC 日志内容选择合适的垃圾回收器调整垃圾回收器参数实时监控内存使用情况分析监控数据
如何有效判断与排查Java GC问题
热门推荐
张彦峰的博客
03-02 7万+
本文介绍了Java垃圾回收（GC）的基本原理及其优化策略。通过分析GC的工作机制，探讨了常见的GC类型、内存管理模型及其对应用性能的影响。文章还详细阐述了如何通过调整JVM参数、选择合适的GC算法和分析GC日志来优化内存回收效率。通过这些实用的优化方法，开发者可以有效减少GC暂停时间，提高应用的响应速度和吞吐量。
记一次 CMS GC导致 FULL GC 时间开销很大的排查
Agly_Charlie的博客
12-22 2294
记一次 CMS GC导致 FULL GC 时间开销很大的排查背景定位分析过程第一次尝试解决方案CMS GC收集器分析了解CMS收集原理优缺点分析总结分析根因解决方案 背景 服务接入注册中心后，就会有实例健康检查，通过ip+port的方式访问接口，检查实例是否健康，某日有个实例出现了告警。检查发现是当时接口超时异常了，触发告警。 短暂的时间后，服务又正常恢复了，接口正常响应。观察日志没有异常问题。 定位分析过程 这个健康接口是个简单的返回，没有经过DB、缓存等。所以超时问题出现在服务本身。 查看CAT、
记一次频繁fullgc排查到解决全流程复盘
zhang09090606的博客
08-07 5274
阿里云oss文件上传导致的频繁fullgc问题排查到解决全流程复盘
一次诡异的full gc查找问题全过程
08-26
在 Java 应用程序中，Full GC 是一种非常 Costly 的垃圾回收操作，它将停止世界（Stop the World）并对整个堆进行垃圾回收。因此，出现 Full GC 问题时，需要快速定位问题原因以避免对系统性能的影响。 在本篇文章...
请你谈谈频繁full gc怎么排查？
一个搬砖工人
04-19 1601
通常的处理，我们还是要在FULLGC时取到当时的dump文件，来分析内存里都有哪些数据占居着内存。这里有两种办法来获取dump文件： 1.通过在jvm里添加参数配置：+HeapDumpBeforeFullGC，+HeapDumpAfterFullGC 这种方法需要在应用启动前要提前配置好，如果不需要的话，还需要修改jvm参数重启应用。 2.使用jinfo命令进行设置。（生产环境常用的方法） 无需重启jvm，即时生效，dump文件生成后，清除JVM参数，通常fullgc 会频繁发生，不需要一直导出dump，
CMS发生FullGc分析
春哥大魔王的博客
06-28 4715
fullgc的原因Full GC触发条件：(1)System.gc()方法的调用该方法不一定执行，但是执行的时候是fullgc。(2)老年代空间不足老年代空间只有在新生代对象转入及创建为...
线上 FullGC 问题排查实践 —— 手把手教你排查线上问题
crg18438610577的博客
05-08 1465
线上 FullGC 问题排查实践 —— 手把手教你排查线上问题
(转载)一次生产系统 Full GC 问题分析与排查总结
weixin_34220834的博客
11-01 321
2019独角兽企业重金招聘Python工程师标准>>> ...
经典线上问题—JVM Full GC 的排查思路
zhangqin111的博客
03-28 1423
Java 虚拟机在执行程序的过程中，会把所管理的内存划分成若干不同的。这些区域各有各有的用途，有的区域会随着虚拟机进程的启动而一直存在；有的区域会伴随着用户线程的启用和结束而创建和销毁。其次，JVM 内存区域也称为等其中，运行时数据区的。
深入探究 JVM 频繁 Full GC 的排查过程
fudaihb的博客
02-23 2997
在当今软件开发领域，Java语言以其跨平台性、面向对象、高性能等特点成为了广泛应用的首选之一。而Java应用程序的核心执行环境就是Java虚拟机（JVM），它负责将Java字节码翻译成机器码并执行，是Java程序运行的基础。在JVM的内存管理机制中，垃圾回收（GC）是一个至关重要的部分，负责释放不再被引用的对象占用的内存空间，以确保应用程序的稳定性和性能。
JVM频繁Full GC问题的排查与解决方案
她们都叫我靓仔
11-20 2526
（JProfiler是一款堆内存分析工具，可以直接连接线上jvm实时查看相关信息，也可以分析dump出来的堆内存快照，对某一时刻的堆内存情况进行分析）将我们dump出来的文件解压，修改后缀名。Heap Dump是JVM堆内存的快照，通过分析Heap Dump，开发者可以了解当前内存中有哪些对象占用了大量空间，从而定位哪些对象导致了内存泄漏或过度的老年代占用。老年代中的内存碎片可能导致对象无法晋升，即使老年代有足够的空闲空间，也无法容纳新的大对象，从而触发Full GC。
gc排查
03-17
### 关于GC排查方法 在Java应用程序中，垃圾回收（Garbage Collection, GC）是一个重要的环节。当遇到GC相关问题时，可以通过以下方式来进行排查： #### 1. **确认GC类型** 需要区分Minor GC和Full GC的发生原因及其影响。Minor GC通常发生在新生代内存不足的情况下[^1]，而Full GC则可能由老年代或永久代/元空间不足引起。 #### 2. **分析GC日志** 启用并解析GC日志是诊断GC问题的关键手段之一。可以设置如下JVM参数以记录详细的GC行为： ```bash -XX:+PrintGCDetails -Xloggc:/path/to/gc.log -verbose:gc ``` 日志文件中的信息可以帮助判断是否存在频繁的GC事件、长时间停顿等问题[^5]。 #### 3. **评估GC频率与时长** 如果发现GC时间较长（例如超过1秒），或者GC过于频繁，则表明可能存在潜在性能瓶颈。此时应进一步深入调查具体哪部分导致了这种现象。 #### 4. **选择合适的垃圾收集器** 不同的应用场景适合不同的垃圾回收算法。常见的几种包括Serial Collector、Parallel Collector、CMS(Collector of Concurrent Mark Sweep) 和 G1(Garbage First)[^2]。每种都有其特定优势与局限性，在实际应用前需充分测试对比效果后再做决策。 #### 5. **调整堆大小及相关参数** 根据业务负载特点合理规划初始堆容量(-Xms)及最大堆容量(-Xmx)，同时考虑Eden区(Survivor Ratio)/Tenured Generation比例等因素的影响[^4]。 #### 6. **检测对象存活周期规律** 利用工具如VisualVM,JConsole 或 MAT(Memory Analyzer Tool) 来观察哪些类型的实例占据大量内存资源，并尝试缩短它们的生命期以便更快释放掉无用数据项[^3]。 --- ### 示例代码展示如何开启GC日志功能 ```java public class EnableGCLogging { public static void main(String[] args){ System.out.println("This is a test program to enable GC logging."); // Simulate memory usage that triggers garbage collection. List<byte[]> list = new ArrayList<>(); while(true){ byte[] b = new byte[10 * 1024]; // Allocate ~10KB each time list.add(b); try{ Thread.sleep(10); // Sleep briefly between allocations }catch(Exception e){} } } } ``` 运行上述程序时加上命令行选项`-XX:+PrintGCDetails -Xloggc:path_to_log_file`, 就能够捕获到完整的GC活动轨迹用于后续审查. ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值