shenandoah 收集器未采用布鲁克指针，而是使用读屏障配合转发指针实现并发转移；其设计避免对象头额外开销，兼顾低延迟与工程可控性，并自jdk 12实验至jdk 21正式支持持续优化。
Shenandoah 收集器并没有使用布鲁克指针（Brooks Pointers）。
布鲁克指针是 Azul Zing 的技术，不是 Shenandoah 的设计
布鲁克指针是一种通过在对象头中插入间接层（即一个指向自身或转发地址的指针）来实现并发对象移动的技术，最早由 Azul Systems 在其 Zing JVM 的 C4（Continuously Concurrent Compacting Collector）收集器中提出并工程化应用。它允许在对象被访问时动态重定向到新位置，从而避免写屏障更新所有引用。
Shenandoah 的设计哲学不同：它选择用 读屏障（Load Barrier） 配合 转发指针（Forwarding Pointer） 实现并发标记与并发转移，而非在每个对象头上维护额外的间接跳转结构。
Shenandoah 的并发转发机制依赖转发指针 + 读屏障
当 Shenandoah 决定移动某个对象时，会在原对象的头部写入一个指向新地址的转发指针（forwarding pointer）。此后任何对该对象的加载（load）操作，都必须经过读屏障检查：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 若对象未被移动，直接返回原地址；
- 若对象已移动且头部存在有效转发指针，读屏障自动返回新地址，并可能触发本地线程的“自愈”（healing），即更新栈上或寄存器中的旧引用；
- 读屏障还负责处理弱引用、JNI 引用等特殊场景的可见性问题。
为什么 Shenandoah 不选布鲁克指针？
布鲁克指针虽能减少写屏障开销，但带来显著代价：
- 每个对象头需额外字段或复用空间，增加内存占用；
- 每次字段访问都多一次指针解引用（即使未并发移动），影响热点代码性能；
- 与 Java 对象模型、JVM 优化（如字段偏移内联、逃逸分析）耦合更深，工程复杂度高；
- Shenandoah 目标是低延迟且可预测，读屏障方案更可控——它只在对象加载时介入，且现代 CPU 分支预测和屏障内联能大幅降低开销。
演进脉络：从初始设计到稳定落地
Shenandoah 最早在 JDK 12 作为实验性特性引入，早期版本使用的是“原始转发指针 + 粗粒度读屏障”，随后逐步优化：
- JDK 15 起支持
-XX:+UseShenandoahGC开箱即用； - JDK 18 增强了对大堆和 NUMA 感知的支持；
- JDK 21（LTS）起成为正式支持的 GC，读屏障实现高度精简，支持快速路径（fast-path）跳过已解析的稳定引用；
- 后续版本持续改进转发表结构、TLAB 处理逻辑和与 JIT 编译器的协同（如将部分屏障逻辑编译进热点方法）。
整个演进过程始终围绕“最小化暂停、明确控制延迟上限”展开，技术选型服务于目标，而非追随某一种学术方案。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
