JVM垃圾收集器原理与CMS优化实战

1. JVM垃圾收集器概述

作为一名长期奋战在Java性能优化一线的工程师，我深知垃圾收集器选择对系统性能的关键影响。JVM的垃圾收集机制经历了从简单到复杂的演进过程，不同收集器各有其适用场景和实现原理。理解这些底层机制，是进行有效调优的前提。

在主流Java应用中，垃圾收集器主要分为以下几类：

• 串行收集器：如Serial和Serial Old，适合单CPU环境和小型应用
• 并行收集器：如Parallel Scavenge和Parallel Old，注重吞吐量优化
• 并发收集器：如CMS和G1，追求低停顿时间
• 新一代收集器：如ZGC和Shenandoah，针对大内存和超低延迟场景

实际生产中最常见的组合是ParNew+CMS，这也是我们今天要重点分析的对象。这种组合在JDK8及之前的版本中被广泛使用，特别适合中等规模、对响应时间敏感的应用系统。

2. 分代收集理论详解

2.1 分代设计的必要性

JVM采用分代收集的核心依据是"弱代假说"(Weak Generational Hypothesis)：

1. 绝大多数对象朝生夕死：经统计，约98%的Java对象在创建后很快就不再被使用
2. 存活越久的对象越难消亡：经过多次GC仍然存活的对象，大概率会继续存活

基于这个观察，HotSpot虚拟机将堆内存划分为：

• 新生代(Young Generation)：存放新创建的对象
• 老年代(Old Generation)：存放长期存活的对象
• 永久代/元空间(PermGen/Metaspace)：存放类元数据等(JDK8后改为Metaspace)

2.2 各区域收集算法选择

不同区域采用不同的收集算法，这是分代设计的精髓所在：

新生代特点与算法选择：

• 特点：对象存活率低，空间相对较小
• 算法：复制算法(Copying)
  • 将内存分为Eden和两个Survivor区
  • 每次GC将存活对象复制到另一个Survivor
  • 优点：没有碎片，分配高效
  • 缺点：空间利用率只有50%

老年代特点与算法选择：

• 特点：对象存活率高，空间较大
• 算法：标记-清除(Mark-Sweep)或标记-整理(Mark-Compact)
  • 标记-清除：简单但会产生碎片
  • 标记-整理：解决碎片问题但耗时更长

在实际应用中，CMS收集器对老年代采用标记-清除算法，而Parallel Old则使用标记-整理算法。这也是CMS会产生内存碎片的原因。

3. 垃圾收集器深度解析

3.1 ParNew收集器

ParNew是Serial收集器的多线程版本，具有以下特点：

• 新生代收集器：只负责新生代的垃圾回收
• 多线程并行：默认线程数等于CPU核心数
• 复制算法：与Serial收集器算法相同
• 与CMS配合：是CMS收集器的默认新生代搭档

关键配置参数：

bash复制-XX:+UseParNewGC  # 启用ParNew收集器
-XX:ParallelGCThreads=4  # 设置GC线程数

使用场景：

• 多核服务器环境
• 与CMS收集器配合使用
• 对停顿时间有一定要求的应用

3.2 CMS收集器详解

3.2.1 工作流程

CMS(Concurrent Mark Sweep)收集器的工作分为四个阶段：

1. 初始标记(Initial Mark) - STW

   • 标记GC Roots直接关联的对象
   • 速度极快，通常只需几毫秒

2. 并发标记(Concurrent Mark)

   • 从GC Roots开始遍历整个对象图
   • 与用户线程并发执行
   • 耗时较长但不会暂停应用

3. 重新标记(Remark) - STW

   • 修正并发标记期间变动的引用
   • 使用增量更新算法解决漏标问题
   • 比初始标记耗时稍长

4. 并发清除(Concurrent Sweep)

   • 清理未被标记的对象
   • 与用户线程并发执行
   • 会产生浮动垃圾

3.2.2 核心参数配置

bash复制# 基本启用
-XX:+UseConcMarkSweepGC

# 触发阈值设置
-XX:CMSInitiatingOccupancyFraction=75  # 老年代使用率达到75%时触发
-XX:+UseCMSInitiatingOccupancyOnly  # 只按阈值触发，不自动调整

# 内存压缩配置
-XX:+UseCMSCompactAtFullCollection  # Full GC后进行压缩
-XX:CMSFullGCsBeforeCompaction=4  # 每4次Full GC压缩一次

# 标记优化
-XX:+CMSScavengeBeforeRemark  # 重新标记前先做Young GC
-XX:+CMSParallelInitialMarkEnabled  # 初始标记并行
-XX:+CMSParallelRemarkEnabled  # 重新标记并行

3.2.3 优缺点分析

优势：

• 并发收集，停顿时间短
• 适合对延迟敏感的应用
• 老年代收集时应用仍可运行

劣势：

1. CPU资源敏感：默认启动的GC线程数=(CPU核心数+3)/4

   • 在4核机器上会占用1个核心
   • 在16核机器上会占用4个核心
   • 可能影响应用性能

2. 浮动垃圾问题：

   • 并发清理阶段新产生的垃圾无法被本次GC回收
   • 可能导致"并发模式失败"(Concurrent Mode Failure)

3. 内存碎片：

   • 使用标记-清除算法会产生碎片
   • 可能触发Full GC进行压缩

4. 配置复杂：

   • 需要合理设置触发阈值
   • 需要平衡压缩频率和性能

在实际生产环境中，CMS的并发模式失败是需要重点监控的问题。一旦发生，会导致长时间的Full GC，严重影响系统响应。

4. 三色标记算法原理

4.1 基本概念

三色标记算法是JVM实现并发标记的核心技术，它将对象分为三种颜色：

• 白色：尚未被GC访问过的对象(默认颜色)
• 灰色：已被GC访问，但引用的对象还未全部检查
• 黑色：已被GC访问，且所有引用都已检查

标记过程就是从GC Roots出发，逐步将对象从白色变为灰色再变为黑色的过程。最终剩余的白色对象就是可回收的垃圾。

4.2 漏标问题

并发标记时，用户线程可能改变对象引用关系，导致两种漏标情况：

1. 插入新引用：黑色对象新引用了白色对象
2. 删除旧引用：灰色对象删除了对白色对象的唯一引用

这两种情况都可能导致活动对象被错误回收，引发严重错误。

4.3 解决方案

4.3.1 增量更新(Incremental Update)

原理：

• 当黑色对象插入对白色对象的引用时，记录这个新引用
• 重新标记阶段，将黑色对象退回到灰色重新扫描

实现：
通过写屏障(Write Barrier)技术：

java复制void post_write_barrier(oop* field, oop new_value) {
    if($gc_phase == CONCURRENT_MARK && is_black(obj)) {
        // 将对象加入重新标记集合
        remark_set.add(obj);  
    }
}

特点：

• CMS采用此方案
• 需要重新扫描变更的引用链
• 可能增加重新标记时间

4.3.2 原始快照(SATB)

原理：

• 假设标记开始时所有引用关系构成一个快照
• 当灰色对象删除对白色对象的引用时，记录这个删除
• 保证按照快照中的引用关系完成标记

实现：

java复制void pre_write_barrier(oop* field) {
    oop old_value = *field;
    if($gc_phase == CONCURRENT_MARK && old_value != null) {
        // 记录被覆盖的引用
        satb_buffer.add(old_value);
    }
}

特点：

• G1收集器采用此方案
• 不需要重新扫描整个引用链
• 会产生一些浮动垃圾

4.4 写屏障实现细节

写屏障是JVM在对象字段赋值操作前后插入的额外处理逻辑。以HotSpot为例：

cpp复制void oop_field_store(oop* field, oop new_value) {
    pre_write_barrier(field);  // 写前屏障
    *field = new_value;        // 实际赋值
    post_write_barrier(field, new_value);  // 写后屏障
}

性能影响：

• 每次对象字段赋值都会触发写屏障
• 可能增加5%-10%的运行开销
• 是现代GC实现并发的必要代价

5. 记忆集与卡表

5.1 记忆集(Remember Set)

作用：
解决跨代引用问题，避免每次Young GC时扫描整个老年代。

实现原理：

• 记录从非收集区(老年代)指向收集区(新生代)的引用
• 通常使用卡表(Card Table)实现

5.2 卡表(Card Table)

数据结构：

• 字节数组，每个元素对应堆中的一块区域(卡页)
• 卡页大小通常为512字节

工作流程：

1. 写屏障检测到跨代引用时，标记对应卡页为脏(dirty)
2. Young GC时只需扫描脏卡页指向的对象
3. 清除卡表标记

实现示例：

cpp复制void post_write_barrier(oop* field, oop new_value) {
    if(cross_generation_reference(field, new_value)) {
        size_t card_index = ((uintptr_t)field >> 9);  // 计算卡表索引
        card_table[card_index] = 1;  // 标记为脏
    }
}

优化技巧：

• 使用-XX:+UseCondCardMark减少不必要的卡表更新
• 适当调整卡页大小(-XX:CardTableEntrySize)

6. 高并发系统JVM优化实战

6.1 电商系统案例

假设我们有一个日PV过亿的电商系统，面临以下问题：

• 高峰期频繁Full GC，导致服务不可用
• 平均响应时间超过500ms
• 内存使用率长期高于80%

6.2 优化前配置

bash复制-Xms4g -Xmx4g
-XX:NewRatio=2  # 新生代占1/3
-XX:SurvivorRatio=8
-XX:+UseParallelGC

问题分析：

1. 新生代太小，导致对象过早晋升老年代
2. Parallel GC不适合低延迟场景
3. 缺乏合理的GC参数调优

6.3 优化后配置

bash复制# 基础内存设置
-Xms3g -Xmx3g  # 适当减少总内存
-Xmn2g  # 增大新生代占比(约66%)

# 晋升阈值调整
-XX:MaxTenuringThreshold=5  # 提高晋升阈值
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=75

# GC日志配置
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-Xloggc:/path/to/gc.log

# 其他优化
-XX:+ExplicitGCInvokesConcurrent  # System.gc()使用CMS
-XX:+ParallelRefProcEnabled  # 并行处理引用

6.4 优化效果对比

6.5 关键优化点

1. 新生代大小调整：

   • 从1.3G增加到2G
   • 让更多短期对象在Young GC时被回收
   • 减少对象晋升老年代的速度

2. 晋升阈值优化：

   • 从默认15降为5
   • 避免对象在Survivor区过度复制
   • 平衡复制开销与老年代压力

3. CMS参数调优：

   • 设置明确的触发阈值(75%)
   • 避免过早或过晚触发CMS
   • 启用并行标记提升效率

4. 监控增强：

   • 开启详细GC日志
   • 配置合理的日志轮转
   • 建立GC监控告警

7. 生产环境经验总结

7.1 常见问题排查

问题1：并发模式失败

• 现象：CMS日志中出现"Concurrent Mode Failure"
• 原因：老年代空间不足，CMS来不及回收
• 解决：
  • 提高CMS触发阈值
  • 增加老年代大小
  • 优化对象分配速度

问题2：晋升失败

• 现象：Young GC时出现"Promotion Failed"
• 原因：老年代没有足够空间容纳晋升对象
• 解决：
  • 增大Survivor区
  • 降低MaxTenuringThreshold
  • 减少大对象分配

问题3：长时间停顿

• 现象：GC日志中单个停顿超过1秒
• 原因：
  • 大对象分配
  • 系统调用阻塞
  • 锁竞争激烈
• 解决：
  • 分析停顿时间分布
  • 优化IO操作
  • 减少锁竞争

7.2 监控指标建议

1. 基础指标：

   • GC频率和耗时
   • 内存各区域使用率
   • 对象分配速率

2. 高级指标：

   • 晋升速率
   • 卡表脏卡比例
   • 引用处理时间

3. 工具推荐：

   • JDK自带：jstat、jmap、VisualVM
   • 第三方：Prometheus + Grafana
   • 商业工具：New Relic、Dynatrace

7.3 参数调优黄金法则

1. 先测量，后优化：

   • 没有监控数据支撑的优化都是盲目的
   • 至少收集24小时GC日志再分析

2. 循序渐进：

   • 每次只调整1-2个参数
   • 观察足够长时间再评估效果

3. 关注应用指标：

   • 最终目标是改善应用表现
   • 不要过度追求GC指标的优化

4. 考虑整体系统：

   • JVM只是系统的一部分
   • 需要与缓存、DB等组件协同优化

8. 新一代收集器展望

虽然CMS在JDK8及之前版本中广泛使用，但新版本中已经不再推荐：

• JDK9：标记为废弃
• JDK14：完全移除

替代方案：

1. G1收集器：

   • JDK9+默认收集器
   • 平衡吞吐量和延迟
   • 适合大内存(6G+)场景

2. ZGC：

   • 超低延迟(10ms以内)
   • 支持TB级堆内存
   • JDK15后生产可用

3. Shenandoah：

   • 与ZGC类似
   • 由RedHat主导开发
   • 更早的版本支持

迁移建议：

• 新项目直接使用G1或ZGC
• 老系统逐步迁移到JDK11+G1
• 特别关注低延迟场景可评估ZGC