Evolution of Garbage Collectors in Java: From Java 8 to Java 21

The evolution of the Garbage Collector (GC) in the Java world has always been crucial for improving application performance and stability. With the constant updates in Java versions, the garbage collectors in the JVM have also evolved to meet the increasing performance demands and application scenarios. This article takes you through the major improvements and changes in garbage collectors from Java 8 to Java 21.

Java 8: The Golden Era of CMS and G1

Java 8 marked a significant milestone in the development of garbage collectors. It introduced two major garbage collectors: CMS (Concurrent Mark-Sweep) and G1 (Garbage First).

CMS: This garbage collector was designed with low latency in mind and was suitable for applications that require quick responses. It reduces pause times by performing concurrent marking and sweeping but has the downside of generating memory fragmentation.

G1: The G1 Garbage Collector was the new star in Java 8. It divides the heap memory into multiple regions and prioritizes collecting the regions with the most garbage, balancing pause times and throughput, effectively solving the fragmentation problem of CMS.

In Java 8, both CMS and G1 had their own advantages, and developers could choose the most appropriate garbage collector based on their application needs.

Java 11: The Birth of ZGC and the Sunset of CMS

With the release of Java 11, the garbage collector landscape began to change. CMS started to phase out, and the introduction of ZGC (Z Garbage Collector) brought new possibilities for garbage collection.

ZGC: This is a forward-looking garbage collector designed to support low latency and high throughput. It is particularly suitable for large-memory applications such as cloud computing and big data processing, significantly reducing GC pause times.

Deprecation of CMS: From Java 9, CMS gradually lost its default status and was no longer the recommended garbage collector in Java 11.

This change in Java 11 marked a shift towards lower latency and higher throughput in garbage collection.

Java 17: The Addition of Shenandoah GC

Java 17 further expanded the family of garbage collectors by introducing Shenandoah GC.

Shenandoah GC: This is another low-latency garbage collector that reduces pause times by performing concurrent marking, relocating, and cleaning. It is designed for high-memory and high-concurrency scenarios.

Optimizations to ZGC: ZGC also received further optimizations in Java 17, improving support for low latency and large heap memory.

These improvements in Java 17 made the JVM more adept at handling high throughput and low latency requirements.

Java 21: A New Era for Virtual Threads and Garbage Collection

By the time Java 21 was released, garbage collectors had reached new heights of performance, especially with the introduction of virtual threads and further optimizations to low-latency garbage collection.

Virtual Threads: The introduction of virtual threads made concurrent programming much lighter. Virtual threads have special support for garbage collection, with new GC mechanisms introduced to prevent pauses during the processing of large numbers of concurrent tasks.

Further Improvements to ZGC and Shenandoah: In Java 21, both ZGC and Shenandoah GC saw further performance improvements, particularly in support for large-memory applications.

These improvements in Java 21 not only enhanced concurrency processing capabilities but also elevated garbage collector performance to new heights.

Summary

From Java 8 to Java 21, garbage collectors in the JVM have undergone significant evolution. Each generation of updates introduced new garbage collectors and optimizations to existing ones, adapting to the changing performance demands and application needs. As developers, understanding these changes is crucial for selecting the most suitable garbage collector for your application. With the ongoing development of Java, we can expect garbage collectors to deliver even better performance with less pause time.

Let me know if you need any further adjustments or details:)

JVM多代垃圾回收器的演进：从Java 8到Java 21

在Java的世界里，垃圾回收器（Garbage Collector，GC）的演进一直是提高应用性能和稳定性的关键。随着Java版本的不断更新，JVM中的垃圾回收器也在不断进化，以适应日益增长的性能需求和应用场景。本文将带你回顾从Java 8到Java 21中垃圾回收器的主要改进和变化。

Java 8：CMS和G1的黄金时代

Java 8是垃圾回收器发展的一个重要里程碑。这个版本引入了两个主要的垃圾回收器：CMS（Concurrent Mark-Sweep）和G1（Garbage First）。
CMS：这是一个以低延迟为目标的垃圾回收器，适用于需要快速响应的应用。它通过并发标记和清除来减少停顿时间，但缺点是容易产生内存碎片。
G1：G1回收器是Java 8中的新星，它通过将堆内存划分为多个区域（Region），并优先回收垃圾最多的区域来平衡停顿时间和吞吐量，有效解决了CMS的碎片化问题。
在Java 8中，CMS和G1各有千秋，开发者可以根据应用的具体需求选择最合适的垃圾回收器。

Java 11：ZGC的诞生和CMS的谢幕

进入Java 11，垃圾回收器的格局开始发生变化。CMS开始逐步退出历史舞台，而ZGC（Z Garbage Collector）的引入为垃圾回收带来了新的可能。
ZGC：这是一个面向未来，支持低延迟和高吞吐量的垃圾回收器。它特别适合于大内存应用，如云计算和大数据处理，能够显著减少GC停顿时间。
CMS的弃用：从Java 9开始，CMS的默认地位逐渐被削弱，到Java 11时，它已经不再是推荐的垃圾回收器。
Java 11的这一变化标志着垃圾回收器向更低延迟和更高吞吐量的方向发展。

Java 17：Shenandoah GC的加入

Java 17进一步扩展了垃圾回收器的家族，引入了Shenandoah GC。
Shenandoah GC：这是另一种低延迟垃圾回收器，它通过并发标记、转移和清理来减少停顿时间，适用于大内存和高并发场景。
ZGC的优化：ZGC在Java 17中也得到了进一步的优化，提升了对低延迟和大堆内存的支持。
Java 17的这些改进使得JVM在处理高吞吐量和低延迟需求时更加得心应手。

Java 21：虚拟线程和垃圾回收的新时代

到了Java 21，垃圾回收器的演进达到了新的高度，特别是虚拟线程的引入和对低延迟垃圾回收器的进一步优化。
虚拟线程：虚拟线程的引入使得并发编程变得更加轻量，它对GC有特殊的支持，通过引入新的垃圾回收机制，能够在处理大量并发任务时，避免GC停顿。
ZGC和Shenandoah的进一步改进：在Java 21中，ZGC和Shenandoah GC在性能和低延迟方面有了进一步的提升，特别是在对大内存应用的支持上。
Java 21的这些改进不仅提升了并发处理的能力，也使得垃圾回收器的性能达到了新的高度。

总结

从Java 8到Java 21，JVM中的垃圾回收器经历了显著的演进。每一代的更新都带来了新的垃圾回收器和对现有回收器的优化，以适应不断变化的性能需求和应用场景。作为程序员，了解这些变化对于选择最适合自己应用的垃圾回收器至关重要。随着Java的不断发展，我们可以期待垃圾回收器将带来更出色的性能和更少的停顿时间。