G1 和 CMS

1、CMS

CMS（Concurrent Mark Sweep，并发标记清除，是为了解决早期垃圾收集器在执行垃圾回收时导致应用程序暂停时间过长的问题而设计的。

CMS的工作流程主要包括以下几个阶段：

初始标记（Initial Mark）：这个阶段是Stop-The-World事件，所有应用线程暂停，垃圾收集器仅标记与根对象直接关联的对象。这个阶段很短。
并发标记（Concurrent Mark）：在这个阶段，应用线程与垃圾收集线程并发执行。垃圾收集器会遍历整个堆，标记出所有存活的对象。这个过程比较耗时，但因为与用户线程并发执行，所以不会导致长时间的暂停。
重新标记（Remark）：这是另一个短暂的Stop-The-World事件，用于修正并发标记期间因用户程序继续运行而可能产生的标记变动。相比初始标记，这个阶段稍长一些，因为它需要处理整个堆的信息。
并发清除（Concurrent Sweep）：此阶段也是与用户线程并发执行的，垃圾收集器会清除那些被标记为死亡的对象所占用的内存空间，回收空间供后续使用。

CMS的优点在于其低延迟特性，能够在大部分垃圾回收工作与应用程序并发执行，从而减少因垃圾回收而导致的暂停时间。然而，CMS也有一些缺点，比如：

对CPU资源消耗较高：由于其并发标记和清除的特性，CMS在运行时会占用较多的CPU资源。
无法处理浮动垃圾（Floating Garbage）：在并发标记和清除阶段，新产生的垃圾不能被这次收集处理，需要等到下一次收集。
可能出现“Concurrent Mode Failure”：如果在老年代剩余空间不足以容纳新生代晋升的对象时，会导致CMS停止并发收集，转而执行完全的垃圾收集（Full GC），这会导致长时间的应用暂停。

尽管CMS在很长一段时间内被广泛使用于对延迟敏感的服务，但随着G1垃圾收集器的发展和完善，CMS在JDK 9中已被废弃，并在JDK 14中完全移除，推荐使用G1或ZGC、Shenandoah等现代垃圾收集器作为替代。

2、G1

G1垃圾收集器（Garbage First Garbage Collector）是Oracle在Java 7中引入的一种高性能垃圾收集器，旨在替代传统的CMS（Concurrent Mark-Sweep）垃圾收集器。它结合了多种垃圾收集技术，旨在提供低停顿、高吞吐量和高效的内存管理；

G1垃圾收集器的工作机制和主要算法：

分区（Region）机制

Region：G1将整个堆划分成多个大小相等的独立区域（Region），每个Region通常为1MB到32MB，根据堆的大小自动调整。
灵活性：Region可以充当Eden区、Survivor区或老年代的一部分，这种设计使得内存管理更加灵活，有助于优化垃圾收集过程。

年轻代收集（Young GC）

复制算法：新生代使用复制算法（Copying），将存活对象从Eden区和一个Survivor区复制到另一个Survivor区。这种方式可以快速整理内存，提高新生代回收的效率。

并发标记周期（Concurrent Marking Cycle）

初始标记（Initial Marking）：暂停所有应用线程，标记从根对象（GC Roots）直接可达的对象。这个过程时间较短。
并发标记（Concurrent Marking）：在应用线程运行时，进行可达性分析，标记所有可达的对象。这个过程中不需要暂停应用线程。
最终标记（Final Marking）：稍微暂停应用线程以完成标记过程，包括处理并发标记阶段新创建的对象。
筛选回收（Selection Phase）：根据之前标记收集的信息，整理并选择有足够垃圾的Region进行回收。这个过程会计算每个Region的回收收益，优先清理垃圾最多的Region。

混合收集（Mixed GC）

混合GC：这是G1垃圾收集器的特性之一，结合了新生代和老年代的垃圾收集。混合收集不仅回收新生代（Eden和Survivor），同时还会选择性地回收一部分老年代的Region。
标记-压缩：在混合GC步骤中，G1对老年代的回收通常使用的是标记-压缩（Mark-Compact）算法。标记阶段标记存活的对象，压缩阶段会移动对象来消除内存碎片，从而可以有连续的空间分配给新的大对象。

回收过程中的暂停时间和吞吐量

暂停时间：G1垃圾收集器设计了暂停时间预测算法，可以根据用户配置的最大暂停时间（-XX:MaxGCPauseMillis）来适应性调整收集行为。
吞吐量：尽量增加应用线程的运行时间，减少垃圾收集的总停顿时间。

总体流程

启动Young GC：当Eden区满时触发年轻代收集，使用复制算法将存活对象移动到Survivor区或老年代。
并发标记阶段启动：当老年代使用率超过特定阈值时，G1启动并发标记周期。
混合收集：在并发标记周期完成后，会进行多次混合收集，回收新生代和部分老年代。
完全垃圾收集（Full GC）：作为最后的手段，当其他方法无法腾出足够空间时，G1会进行Full GC，这是代价最高的一种垃圾收集方式。

通过以上综合设计，G1垃圾收集器能够在大堆内存环境中有效地管理内存，降低垃圾收集停顿时间，提高应用的响应性和吞吐量。

3、是否可以理解：G1的内存管理 = CMS + 标记整理

标记-整理算法：在标记-整理算法中，存活对象会被移动以压缩和消除内存碎片，这个过程需要停止所有应用线程（“Stop-The-World”），导致较长的停顿时间。

虽然CMS可以通过引入标记-整理算法来减少碎片，但无法有效解决长时间停顿和并发处理的复杂性问题。G1通过划分Region+混合收集，使得G1能够更加灵活地选择收集哪些区域，而不是像传统的分代收集器那样对整个年轻代或老年代进行回收。

G1混合收集触发场景

周期性触发：G1有一个称为“Initiating Heap Occupancy Percent”（IHOP）的阈值，默认情况下，当整个Java堆的使用量达到这个阈值时（默认设置通常是45%到70%之间，可以通过-XX:InitiatingHeapOccupancyPercent参数调整），G1会启动一次混合收集。这意味着G1会定期检查堆的占用情况，一旦达到设定的阈值，就会触发一次收集以回收空间。
避免内存耗尽：除了基于IHOP的触发机制外，G1还会根据实际的内存分配速率和当前堆的使用情况动态调整，确保有足够的空闲空间来满足应用程序的内存需求，避免因为没有足够的空间分配对象而导致的Full GC。
目标停顿时间管理：G1在执行时会尽量维持用户设定的目标停顿时间（通过-XX:MaxGCPauseMillis参数指定）。如果系统检测到为了满足这个目标停顿时间，需要进行老年代的清理，那么也会触发混合收集，即使没有达到IHOP设定的阈值。
碎片整理需求：G1在运行过程中会持续监控堆的碎片化程度。如果发现老年代区域过于碎片化，影响了对象分配或者满足不了预设的内存分配需求，G1也可能决定进行一次混合收集来整理内存，减少碎片。

混合收集的主要目的是回收一部分老年代区域，同时保持暂停时间的可预测性，并通过这种方式平衡吞吐量与响应时间的需求。在整个过程中，G1会优先回收垃圾最多（即回收效益最高的）区域，以提高收集效率。

4、为什么选择G1

JDK 9之后，G1（Garbage First）垃圾收集器成为了默认的垃圾收集器。这一改变主要基于以下几点考虑：

适应性更强：G1是一种跨代收集器，能够自动管理整个Java堆，包括年轻代和老年代，而不仅仅是老年代（如同CMS）。
更低暂停、更高吞吐：通过并发和并行处理（充分利用多核处理器的能力），以及灵活的Region管理，减少了应用的全局停顿时间，适合对响应时间要求较高的应用。
内存管理更高效：通过标记-压缩算法和区域回收，有效地管理内存碎片，避免大对象分配困难的问题。同时引入了混合收集模式，即在年轻代收集的同时，也会并发地回收一部分老年代，这有助于减少老年代的碎片化问题。

参考：

https://juejin.cn/post/6844903893906751501
https://docs.oracle.com/javase/9/gctuning/garbage-first-garbage-collector.htm#JSGCT-GUID-ED3AB6D3-FD9B-4447-9EDF-983ED2F7A573