学而时习之，不亦说乎？温故而知新，可以为师矣！

本文将带您深入研究Java 21中的一项颠覆性特性——分代ZGC（Generational ZGC）。我们将详细解释这个垃圾回收引擎的原理、设计理念以及在性能优化方面的显著改进。通过对比传统垃圾回收方法，读者将更好地理解分代ZGC如何提供更快、更稳定的内存管理体验。无论您是Java开发者、系统架构师还是对Java最新技术的追随者，本文将为您揭示分代ZGC的魅力，助您在Java编程的道路上更进一步。让我们一同迎接Java 21崭新时代的到来！

不过 JDK 6 Update 24 后，HandlePromotionFailure 参数就没有用了，规则变为只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行 Minor GC，否则将进行 Full GC，这种其实有点赌的动机，如果这次垃圾收集情况特殊，那么尝试 Minor GC 就会出现担保失败，担保失败还是会进行 Full GC，这样停顿时间就更长了。这三个参数限制了 Java 堆大小为 20MB，不可扩展，其中 10MB 分配给新生代，剩下的 10MB 分配给老年代。

关于垃圾回收算法，基本就是那么几种：标记-清除、标记-复制、标记-整理。在此基础上可以增加分代（新生代/老年代），每代采取不同的回收算法，以提高整体的分配和回收效率。无论使用哪种算法，标记总是必要的一步。这是理算当然的，你不先找到垃圾，怎么进行回收？标记出哪些对象是存活的，哪些是垃圾（可回收）；进行回收（清除/复制/整理），如果有移动过对象（复制/整理），还需要更新引用。本文着重来看下标记的部分。

垃圾收集器就是内存回收操作的具体实现，HotSpot 里足足有 7 种，为啥要弄这么多，因为它们各有各的适用场景。有的属于新生代收集器，有的属于老年代收集器，所以一般是搭配使用的（除了万能的 G1）。关于它们的简单介绍以及分类请见下图。

此外，在进行枚举根节点的这个操作时，为了保证准确性，我们需要在一段时间内 “冻结” 整个应用，即 Stop The World（传说中的 GC 停顿），因为如果在我们分析可达性的过程中，对象的引用关系还在变来变去，那是不可能得到正确的分析结果的。在 OopMap 的帮助下，HotSpot 可以快速准确的完成 GC 枚举了，不过，OopMap 也不是万年不变的，它也是需要被更新的，当内存中的对象间的引用关系发生变化时，就需要改变 OopMap 中的相应内容。对于这种情况，我们要依靠安全区域来解决。

当一块内存用完时，将这块内存上还存活的对象复制到另一块内存上去，将这一块内存全部清理掉。标记过程和标记清除算法一样，但是标记后不是对可回收的对象进行处理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。根据对象存活周期的不同将内存划分为几块，一般把 Java 堆分为新生代和老年代。先标记出所有需要回收的对象（图中深色区域），标记完后，统一回收所有被标记对象（留下狗啃似的可用内存区域……可用内存缩小为原来的一半，适合 GC 过后只有少量对象存活的新生代。

什么时候回收对象？当然是这个对象再也不会被用到的时候回收。所以要想解决 “什么时候回收？” 这个问题，我们要先能判断一个对象什么时候什么时候真正的 “死” 掉了，判断对象是否可用主要有以下两种方法。

具体 JVM 的内存结构，其实取决于其实现，不同厂商的 JVM，或者同一厂商发布的不同版本，都有可能存在一定差异。主要以 Oracle HotSpot VM 为默认虚拟机。

总共也就这么 5 个区（直接内存不属于 JVM 运行时数据区的一部分），除了程序计数器其他的地方都有可能出现 OOM (OutOfMemoryError)，其中像是程序计数器和两个栈（Java 虚拟机栈 & 本地方法栈)都是每个线程要有一个的，所以肯定是线程隔离的。Java 程序需要通过虚拟机栈上的 reference 数据来操作堆上的具体对象，reference 数据是一个指向对象的引用，不过如何通过这个引用定位到具体的对象，目前主要有以下两种访问方式：句柄访问和直接指针访问。