JVM垃圾回收器介绍
-
Serial GC:
- 算法: 使用的是标记-清除算法。
- 特点: 串行执行，适用于单CPU环境或较小的堆内存配置。在新生代和老年代的回收中都是单线程执行，因此在进行垃圾回收时会暂停所有应用线程（Stop-The-World）。
-
Parallel GC (也称为吞吐量优先收集器):
- 算法: 在新生代中使用复制算法，老年代通常使用标记-压缩算法。
- 特点: 适用于多CPU环境，可以并行执行以提高垃圾回收速度，从而提高整体应用程序的吞吐量。在新生代回收时可以使用多个线程并行工作，但仍会在老年代回收时引起较长时间的暂停。
-
Concurrent Mark Sweep (CMS) GC (已废弃，但在某些旧版本JDK中可用):
- 算法: 主要使用标记-清除算法，特点是大部分工作可以在应用线程运行的同时并发进行，减少暂停时间。
- 特点: 旨在减少垃圾回收引起的暂停时间，适用于对响应时间要求较高的服务。但可能会导致内存碎片化，并且在极端情况下可能出现内存耗尽而触发Full GC，影响性能。
-
G1 (Garbage First) GC:
- 算法: 结合了分区算法和标记-复制的思想，新生代和老年代都在一个连续的内存空间内被划分为多个区域。
- 特点: 设计用于大型堆内存，目标是实现可预测的暂停时间。G1通过并发标记和分区的方式工作，尝试平衡吞吐量和延迟，最终目标是替代CMS。
-
Z Garbage Collector (ZGC):
- 算法: 使用了染色指针技术结合标记-复制算法，实现了几乎无停顿的垃圾回收。
- 特点: 自JDK 11引入，目标是即使在非常大的堆内存中也能保持暂停时间在10ms以内，适合对延迟敏感的应用。
- Zero GC暂停时间目标：这里的“Zero”体现在它力图使应用程序在进行垃圾回收时的暂停时间非常短，几乎不影响应用的响应时间。
- Zapped（快速处理）：“Z”隐含了快速、即时处理的意思，反映ZGC在处理垃圾回收时的高效和迅速
-
Shenandoah GC:
- 算法: 同样采用了标记-复制算法，并利用了类似ZGC的区域划分和并发回收策略。
- 特点: 提供了低延迟垃圾回收能力，能在不停止应用线程的情况下进行大部分垃圾回收工作，适用于大规模且对延迟有严格要求的应用。
概念解释：
吞吐量：
具体来说，如果一个应用运行了100秒，其中98秒是在执行业务逻辑，而2秒用于垃圾回收，那么这个应用的吞吐量就是98%。
Parallel GC（也称作吞吐量优先收集器）即在牺牲一定GC停顿时间的前提下，使得应用程序能够更快地完成更多的任务。例如，在一个大数据处理或者高负载的服务器应用中，我们可能更关心在一段时间内能处理多少请求，而不是单个请求的响应时间。
吞吐量百分比可通过参数设置，默认情况下，如果不进行特殊配置，JVM的吞吐量目标是99%，这意味着目标是将99%的时间用于应用程序的执行，而只留1%的时间用于垃圾回收。
延迟：
这里特指垃圾回收引起的停顿时间，即Stop-The-World（STW）事件的持续时间。低延迟意味着在垃圾回收期间，应用程序暂停的时间很短，这对于需要即时响应的交互式应用（如在线交易系统、游戏等）来说至关重要，因为长暂停会直接影响用户体验。
平衡吞吐量和延迟：
在垃圾回收器的设计中，吞吐量和延迟往往是相互制约的。例如，为了提高吞吐量，垃圾回收器可能会采取更激进的策略，如更少的垃圾回收频率，但这可能导致每次垃圾回收时的停顿时间变长，从而增加延迟。反之，为了降低延迟，可能需要更频繁但更轻量级的垃圾回收，这又可能降低了整体的吞吐量。
G1 目标是，在确保垃圾回收停顿时间可预测和可控（低延迟）的同时，尽可能维持较高的应用程序执行效率（高吞吐量）。这意味着，G1在设计上既考虑了如何高效地回收内存，减少内存管理对应用运行的影响，也考虑到了如何让应用在面临垃圾回收时的响应更加及时和可预测。这种平衡对于现代复杂多变的应用场景尤其重要。
简单理解：如果吞吐量为98%，停顿时间2%(垃圾回收时间)，怎么来停顿这2%的时间，可一次停顿，也可多次停顿，需要平衡。
应用：
jdk8: 默认使用Parallel GC
jdk9: 从Java 9开始及之后的版本，默认使用G1