垃圾收集器G1和ZGC、颜色指针（思维导图）

<think>好的，我现在需要详细描述CMS、G1和ZGC这三个垃圾收集器。首先，我要确认每个收集器的基本信息，包括它们的工作方式、适用场景、优点和缺点。然后比较它们之间的差异，可能还需要提到它们的演变背景，为什么会有新的收集器出现。 首先，CMS收集器，我记得是并发标记清除，主要目标是减少停顿时间，适用于对延迟敏感的应用。它分为几个阶段：初始标记、并发标记、重新标记、并发清除。不过CMS的问题可能在于内存碎片和CPU资源敏感，还有在并发阶段可能产生浮动垃圾，导致Full GC。 接下来是G1收集器，它取代了CMS，采用了分Region的内存布局，可以预测停顿时间。G1的工作分为年轻代和老年代的收集，使用Remembered Set来跟踪跨Region引用，避免全堆扫描。它的优势在于可控的停顿时间，适合大内存应用，但可能吞吐量稍低。 然后是ZGC，这是较新的收集器，专注于低延迟，甚至亚毫秒级的停顿。它使用了着色指针和读屏障技术，实现并发处理大部分垃圾回收任务。ZGC适合非常大的堆内存，比如TB级别，而且停顿时间不会随堆大小增加而增加。不过可能需要更高的JDK版本支持，比如JDK11以上，并且还在不断优化中。 我需要组织这些信息，分点详细说明每个收集器，包括它们的原理、阶段、优缺点，以及适用场景。同时，用户可能想了解它们之间的对比，所以最后可以做一个对比表格，帮助理解差异。 需要注意的是，避免技术性错误，比如CMS在JDK9后被标记为废弃，而ZGC在后续版本中逐渐成熟。此外，G1是默认收集器，而ZGC可能在最新的JDK版本中成为默认选项，需要确认当前情况。可能还要提到参数设置，比如如何启用这些收集器，以及调优建议。 另外，要使用中文，保持结构清晰，可能分章节介绍每个收集器，最后总结对比。需要检查术语的准确性，比如并发和并行的区别，CMS是并发收集，而并行收集可能指多个GC线程同时工作。 最后，确保内容详细但不过于冗长，覆盖关键点即可。可能还需要举例子或者使用场景，帮助读者理解何时选择哪种收集器。</think>以下是Java中CMS、G1和ZGC垃圾收集器的详细对比解析： --- ### **1. CMS收集器（Concurrent Mark-Sweep）** #### **核心机制** - **目标**：以**最小停顿时间**为核心，适用于对延迟敏感的应用（如Web服务）。 - **工作阶段**： 1. **初始标记（Initial Mark）**：Stop-The-World（STW），标记GC Roots直接关联的对象。 2. **并发标记（Concurrent Mark）**：与用户线程并发，遍历整个对象图。 3. **重新标记（Remark）**：STW，修正并发标记期间变动的对象。 4. **并发清除（Concurrent Sweep）**：删除不可达对象。 - **内存布局**：传统分代模型（年轻代+老年代）。 #### **优点** - **低延迟**：大部分阶段与应用线程并发执行。 - **适合场景**：老年代回收频繁且要求低停顿（如响应时间敏感的OLTP系统）。 #### **缺点** - **内存碎片**：标记-清除算法不整理内存，需定期Full GC（使用Serial Old收集器）。 - **浮动垃圾**：并发阶段用户线程可能产生新垃圾，需预留内存空间。 - **CPU敏感**：并发阶段占用CPU资源，可能影响吞吐量。 #### **关键参数** ```bash -XX:+UseConcMarkSweepGC # 启用CMS -XX:CMSInitiatingOccupancyFraction=70 # 老年代70%时触发CMS -XX:+UseCMSCompactAtFullCollection # Full GC时整理内存 ``` --- ### **2. G1收集器（Garbage-First）** #### **核心机制** - **目标**：平衡**吞吐量**与**可控停顿时间**，替代CMS成为JDK9+默认收集器。 - **内存模型**：将堆划分为**多个等大小Region**（1MB~32MB），动态归属为Eden/Survivor/Old/Humongous区。 - **工作流程**： 1. **年轻代收集**：STW，复制存活对象到Survivor或Old区。 2. **混合收集（Mixed GC）**：回收部分Old Region（基于垃圾比例优先级）。 3. **Full GC（Fallback）**：当回收速度跟不上分配速度时触发（类似Serial Old）。 #### **优点** - **可预测停顿**：通过`-XX:MaxGCPauseMillis`设置目标停顿时间（默认200ms）。 - **高效内存利用**：Region设计减少内存碎片，适合大堆（4GB+）。 - **并行与并发**：充分利用多核CPU，部分阶段并发执行。 #### **缺点** - **内存开销**：维护跨Region引用的Remembered Set占用额外内存。 - **吞吐量略低**：相比Parallel Scavenge/Old，吞吐量降低约10%。 #### **关键参数** ```bash -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:G1HeapRegionSize=16m # 设置Region大小 ``` --- ### **3. ZGC（Z Garbage Collector）** #### **核心机制** - **目标**：**亚毫秒级停顿**（<10ms），支持TB级堆内存（JDK15+正式生产可用）。 - **关键技术**： - **着色指针（Colored Pointers）**：利用指针元数据标记对象状态（无需对象头）。 - **读屏障（Load Barrier）**：动态处理并发阶段的对象访问。 - **并发压缩**：在用户线程运行时整理内存，消除碎片。 - **阶段**： 1. **并发标记**：遍历对象图并标记存活对象。 2. **并发预备重分配**：确定需压缩的Region。 3. **并发重分配**：移动对象并更新引用。 4. **并发重映射**：修正旧地址的访问。 #### **优点** - **极致低延迟**：停顿时间几乎不随堆大小增长。 - **全堆操作**：无分代假设，简化回收逻辑。 - **高吞吐量**：并发处理能力接近G1。 #### **缺点** - **内存开销**：需额外内存维护元数据（约15%~20%堆容量）。 - **JDK版本依赖**：需JDK11+（生产推荐JDK17+）。 #### **关键参数** ```bash -XX:+UseZGC -XX:ZAllocationSpikeTolerance=5 # 容忍内存分配速率波动 -XX:ZProactive # 启用主动回收（默认开启） ``` --- ### **4. 三大收集器对比** | **特性** | **CMS** | **G1** | **ZGC** | |---------------------|----------------------------------|------------------------------------|-----------------------------------| | **目标** | 最小停顿时间 | 平衡吞吐量与可控停顿 | 亚毫秒级停顿，超大堆 | | **算法** | 标记-清除（不整理） | 标记-整理（分Region） | 着色指针+并发压缩 | | **最大堆** | 4-6GB（受碎片限制） | 百GB级 | TB级 | | **停顿时间** | 10ms-100ms | 10ms-200ms（可配置） | <1ms-10ms | | **内存开销** | 低 | 中（Remembered Set） | 高（元数据） | | **并发/并行** | 并发标记/清除 | 并行年轻代收集，并发老年代标记 | 全阶段并发 | | **适用场景** | 低延迟中小堆应用 | 大堆、需平衡吞吐与延迟 | 超大堆、极致低延迟（金融、实时） | | **JDK支持** | JDK8默认，JDK9+废弃 | JDK9+默认 | JDK11+实验，JDK15+生产 | --- ### **5. 选择建议** 1. **CMS**：已逐渐淘汰，仅在JDK8及以下版本的老系统中使用。 2. **G1**：JDK8+通用选择，适合堆内存4GB~50GB，要求平衡吞吐与延迟。 3. **ZGC**：JDK15+首选，适用于堆内存50GB+、要求极低延迟（如高频交易系统）。 --- ### **6. 性能调优要点** - **CMS**：监控Full GC频率，调整`CMSInitiatingOccupancyFraction`避免并发失败。 - **G1**：优化`MaxGCPauseMillis`，避免Region过大导致Humongous对象分配。 - **ZGC**：确保物理内存充足，预留额外内存（堆大小的20%）。