JDK17的垃圾回收机制和JKD8有何不同？_jdk17 垃圾回收-优快云博客

翻了一下csdn，没找到具体写这个的，于是笔者决定自己总结一下，本人略菜，可能总结的不全

什么是垃圾回收机制？

先说一下什么是垃圾回收机制，这里引用一下本站大佬的概念

原文链接：https://blog.youkuaiyun.com/qq_32486939/article/details/137817765

垃圾回收（Garbage Collection，GC）是Java语言提供的一种自动内存管理机制。它通过跟踪对象的引用关系，确定哪些对象仍然被程序所使用，哪些对象不再被使用，并在适当的时机回收不再使用的对象的内存。这样，开发者就无需手动管理内存，从而降低了内存泄漏和内存溢出的风险。

在Java中，所有对象都是通过引用进行操作的。当一个对象没有任何引用指向它时，它就被认为是垃圾对象，可以被垃圾回收器回收。垃圾回收器会定期扫描堆内存，找出并回收这些垃圾对象，从而释放内存空间。

JDK 8的垃圾回收器默认是Parallel 回收器、也可以使用CMS (Concurrent Mark-Sweep)回收器、Serial 回收期和G1回收器。x

再次引用该大佬的简介：

Serial回收器是最基本的垃圾回收器，它采用单线程的方式进行垃圾回收。在垃圾回收时，它会暂停所有的工作线程，直到回收完成。这种回收器适用于单CPU环境或内存较小的场景，因为它的开销较小。

Parallel回收器是并行版的Serial回收器，它使用多线程进行垃圾回收，从而提高了回收效率。它适用于多CPU环境，可以充分利用硬件资源来加速垃圾回收过程。

CMS（Concurrent Mark Sweep）回收器是一种以获取最短回收停顿时间为目标的回收器。它采用标记-清除算法，并在垃圾回收过程中尽量保持应用程序的响应性。CMS回收器适用于对停顿时间要求较高的场景，如Web应用等。

但是，CMS回收器存在一些缺点，如对CPU资源消耗较大，以及可能产生内存碎片等。因此，在选择CMS回收器时需要综合考虑这些因素。

G1（Garbage-First）回收器是一款面向服务端应用的垃圾回收器。它采用分代收集算法，并引入了预测模型来优化回收过程。G1回收器能够自动调整新生代和老年代的大小，以及选择合适的回收算法，以适应不同的应用程序需求。

G1回收器的优点包括低停顿时间、高吞吐量以及良好的内存使用效率。它适用于大型服务端应用，可以提供更好的性能和稳定性。
原文链接：https://blog.youkuaiyun.com/qq_32486939/article/details/137817765

JDK 17的默认垃圾回收器是增强的G1回收器，提高了处理大堆内存和避免长时间停顿的能力。G1一直被认为是在追求较低停顿时间的应用场景中的首选垃圾回收器。

ZGC是Java虚拟机的一种垃圾回收器，它专注于低延迟和高吞吐量，是一个可伸缩的低延迟垃圾回收器，可以处理更大的堆内存而不会对程序的性能产生影响。JDK 17对ZGC进行了改进，进一步降低了垃圾回收的停顿时间，提高了系统的响应速度。

Shenandoah GC专注于降低停顿时间，并且适用于大内存的应用场景。在电商应用中，当系统需要处理大量数据时，Shenandoah GC可以帮助我们减少垃圾回收的停顿时间，提高系统的吞吐量和可用性。

这两者都支持低延迟。

jdk8中的CMS和Parallel GC在jdk17中已经被移除

JDK17，引入了更多的自动调优功能，很多情况下开发者无需手动调整GC参数，G1 GC提供了更好的内存管理和更短的停顿实践，

JDK17垃圾回收机制的性能得到了持续优化，包括减少停顿时间、提高垃圾回收效率等方面。

JDK 8的CMS 使用了并发标记和清理阶段，使其能够在应用程序运行时进行回收。

JDK 17的G1 GC 和 ZGC 在并发标记方面有了更好的优化，减少了应用线程的干扰。

JDK 8 使用的内存区域相对简单，主要包括年轻代、年老代和永久代（PermGen）。
JDK 17 永久代已被元空间（Metaspace）替代，元空间动态调整大小，减少了内存使用高峰期的影响。

JDK 8: GC 停顿可能会较长，尤其是在对象较多、大对象存活期较长的情况下。
JDK 17: 通过 ZGC 和 Shenandoah 等新型 GC，显著降低了垃圾回收的停顿时间，适用于对延迟敏感的应用。

JDK 8 和 JDK 17 在垃圾回收机制上的主要区别在于可用的垃圾回收器种类、性能优化、内存管理方式和停顿时间控制方面。选择合适的垃圾回收策略对应用性能至关重要，尤其是对于高并发和低延迟的应用场景，更需要考虑使用 JDK 17 的新特性。