问题：条件性常量的加载开销
大型框架（如依赖注入容器、ORM 或序列化库）常常需要根据配置或环境决定使用哪个常量。例如，一个配置类可能根据系统属性选择不同的正则表达式、字符集或安全算法。传统做法是在类加载阶段就解析这些常量，即使某些常量在当前运行环境中根本不会被使用。这导致两个问题：一是类加载时间变长，因为 JVM 需要解析所有常量；二是内存占用增加，因为那些未被使用的常量也被创建并驻留在堆中。
对于启动时间敏感的微服务或 CLI 工具，这种不必要的开销可能成为瓶颈。更糟糕的是，某些常量的创建可能依赖外部资源（如数据库连接、文件句柄），若在类加载时过早触发，可能引发初始化失败。
传统方案及其局限
在 Java 11 之前，类文件常量池中的常量类型是固定的：字符串、整数、浮点数、类引用、方法句柄、方法类型等。编译器在编译期决定这些常量的值，JVM 在类加载或首次使用时解析它们。对于需要根据运行时条件创建的常量，开发者通常采用以下替代方案：
- 静态初始化块：在类加载时执行代码，创建所需常量。但这样所有常量都会被创建，无法做到按需。
- 静态工厂方法：将常量封装在方法中，延迟到首次调用时创建。这确实能延迟初始化，但调用方必须通过方法调用获取，而不是像常量那样直接使用，且可能引入额外的方法调用开销。
- 枚举：枚举常量在类加载时全部创建，无法避免。
这些方案要么牺牲了延迟性，要么牺牲了使用便利性。CONSTANT_Dynamic 正是为了解决这一矛盾而设计：它允许常量池条目在解析时委托给一个引导方法（Bootstrap Method），从而将常量的创建推迟到首次实际使用时，且对使用方透明——它们仍然像普通常量一样通过 ldc 指令加载。
CONSTANT_Dynamic 的常量池结构
CONSTANT_Dynamic 是 JVM 11（类文件版本 55.0）引入的新常量池条目，其 tag 值为 17。它的结构非常简洁，与 CONSTANT_InvokeDynamic 类似，包含两个索引：
CONSTANT_Dynamic_info {
u1 tag; // 值为 17
u2 bootstrap_method_attr_index; // 指向 BootstrapMethods 属性中的引导方法
u2 name_and_type_index; // 指向 CONSTANT_NameAndType_info，表示名称和字段描述符
}bootstrap_method_attr_index 指向类文件的 BootstrapMethods 属性，该属性在类文件中最多只能出现一次，其中记录了所有引导方法及其静态参数。name_and_type_index 则指向一个 CONSTANT_NameAndType_info，它提供了常量的名称和类型信息。
与 CONSTANT_InvokeDynamic 不同，CONSTANT_Dynamic 的 name_and_type_index 描述的是字段描述符（field descriptor），而不是方法描述符。这是因为动态常量最终是一个值，而不是一个调用点。
引导方法：从 invokedynamic 到动态常量
CONSTANT_Dynamic 的解析机制与 invokedynamic 的链接机制高度相似。当 JVM 首次遇到一个 CONSTANT_Dynamic 条目时，它会调用指定的引导方法，该方法返回一个值，这个值被转换为所需的类型并缓存，供后续使用。
引导方法是一个方法句柄（MethodHandle），其签名约定如下：
- 第一个参数是
java.lang.invoke.MethodHandles.Lookup对象，表示调用上下文。 - 第二个参数是
String，即CONSTANT_NameAndType_info中的名称部分。 - 第三个参数是
Class，表示期望的常量类型。 - 之后是任意数量的静态参数，这些参数来自
BootstrapMethods属性中记录的常量。
引导方法必须返回一个与期望类型兼容的值。与 invokedynamic 不同，它不需要返回 CallSite 对象，而是直接返回值。
这种设计使得常量的创建逻辑可以完全由用户控制，而 JVM 只负责调度和缓存。多个线程可能同时触发解析，但 JVM 保证只有一个线程执行引导方法，其他线程等待结果，确保唯一性。
贯穿场景：框架中的条件性常量
假设我们正在开发一个配置框架，需要根据系统属性 app.encoding 决定使用哪种字符集。传统写法可能是：
public class Config {
public static final Charset CHARSET = Charset.forName(System.getProperty("app.encoding", "UTF-8"));
}这个常量在类加载时就会触发 Charset.forName 调用，即使应用根本不需要它。如果改为 CONSTANT_Dynamic，可以将创建逻辑移到引导方法中，只有首次访问 CHARSET 时才执行。
然而，Java 语言本身并不直接支持声明 CONSTANT_Dynamic 常量，它通常由编译器或字节码生成工具（如 ASM、Byte Buddy）生成。不过，我们可以通过 invokedynamic 间接体验类似机制，因为 CONSTANT_Dynamic 与 invokedynamic 共享引导方法机制。
为了更直观地理解，我们来看一个使用 invokedynamic 的类似场景：字符串拼接（StringConcatFactory）在 Java 9 之后使用 invokedynamic 实现，将拼接策略延迟到运行时决定。同样，LambdaMetafactory 使用 invokedynamic 将 lambda 表达式转换为方法句柄。CONSTANT_Dynamic 则扩展了这一思想，让常量本身也能动态计算。
解析流程与并发控制
当 JVM 执行 ldc 指令并遇到 CONSTANT_Dynamic 条目时，解析过程如下：
- 检查缓存：JVM 维护一个解析后的常量缓存，如果该条目已被解析，直接返回缓存值。
- 触发引导：若未解析，JVM 调用引导方法，传入
Lookup、名称、类型和静态参数。 - 类型转换：引导方法返回的值被转换为期望类型，如果类型不匹配则抛出
BootstrapMethodError。 - 缓存结果：解析成功的值被缓存，后续访问不再调用引导方法。
并发方面，JVM 保证多个线程同时请求解析时，只有一个线程执行引导方法，其他线程阻塞等待。这类似于 invokedynamic 的链接过程，但返回值是常量而非 CallSite。
以下流程图展示了这一过程（以配置框架中的字符集常量为场景）：
flowchart TD
A[执行 ldc 指令] --> B{常量是否已缓存?}
B -- 是 --> C[返回缓存值]
B -- 否 --> D[调用引导方法]
D --> E[引导方法执行创建逻辑]
E --> F[返回常量值]
F --> G[类型转换与校验]
G --> H[缓存结果]
H --> C
与 invokedynamic 的关系与对比
CONSTANT_Dynamic 与 invokedynamic 在机制上高度相似，但用途不同。下表对比了两者的关键差异：
| 维度 | invokedynamic | CONSTANT_Dynamic |
|---|---|---|
| 引入版本 | Java 7 | Java 11 |
| 常量池 tag | 18 | 17 |
| 引导方法返回值 | CallSite 对象 | 任意值 |
| 使用场景 | 动态调用点（如 lambda、字符串拼接） | 动态常量（如按需创建的配置值） |
| 指令 | invokedynamic | ldc / ldc_w / ldc2_w |
| NameAndType 描述符 | 方法描述符 | 字段描述符 |
| 解析时机 | 首次执行 invokedynamic 指令时 | 首次执行 ldc 指令时 |
| 缓存 | 缓存 CallSite 对象 | 缓存常量值 |
两者共享 BootstrapMethods 属性，引导方法的签名也基本一致，只是返回类型不同。这使得 JVM 可以复用引导方法的调用机制，降低了实现复杂度。
实践应用与注意事项
CONSTANT_Dynamic 的主要应用场景包括：
- 按需初始化重量级常量：如正则表达式
Pattern、字符集Charset、VarHandle等，这些对象的创建成本较高，且可能依赖运行时环境。 - 减少类加载开销：将常量创建从类加载阶段推迟到首次使用，缩短类加载时间，尤其适合启动时加载大量类的框架。
- 实现更丰富的常量类型：JEP 309 的目标之一就是支持更多类型的常量，如
VarHandle、小型不可变集合等。
然而，使用 CONSTANT_Dynamic 也有一些注意事项：
- 需要字节码生成工具：Java 语言本身不直接支持声明动态常量，必须通过 ASM、Byte Buddy 等工具生成类文件。
- 引导方法必须幂等：由于解析只发生一次，引导方法不应有副作用，否则可能导致不可预测的行为。
- 异常处理：如果引导方法抛出异常，JVM 会将其包装为
BootstrapMethodError，并在首次解析时抛出。 - 版本兼容性：
CONSTANT_Dynamic需要类文件版本 55.0（Java 11）及以上，运行在旧版本 JVM 上会报UnsupportedClassVersionError。
权衡与替代方案
与传统的静态初始化相比，CONSTANT_Dynamic 的主要优势是延迟性和按需性，但代价是增加了类文件的复杂度，并且需要依赖引导方法的正确实现。如果常量本身创建成本很低，或者几乎总是会被使用，那么使用 CONSTANT_Dynamic 可能得不偿失。
另一种替代方案是使用 invokedynamic 模拟动态常量，但那样需要定义一个返回常量值的方法，并调用它，语义上不如 CONSTANT_Dynamic 直接。
在工程实践中，CONSTANT_Dynamic 更适合那些创建成本高、使用频率低、且依赖运行时条件的常量。例如，配置框架中的正则表达式、数据库连接池中的连接字符串等。
可观测性与失败模式
在生产环境中，如果动态常量的引导方法执行缓慢或抛出异常，会直接影响首次访问该常量的线程。可以通过 JFR（Java Flight Recorder）等工具观察类加载和常量解析事件，但 CONSTANT_Dynamic 本身不提供专门的观测接口。
常见的失败模式包括：
- 引导方法抛异常：导致
BootstrapMethodError，通常是由于静态参数类型不匹配或引导方法内部错误。 - 类型转换失败：引导方法返回的值无法转换为期望类型，同样抛出
BootstrapMethodError。 - 循环依赖：如果引导方法的静态参数中引用了另一个动态常量，而该动态常量的引导方法又引用回当前常量，可能造成死循环。JVM 规范禁止动态常量之间的循环引用。
总结
CONSTANT_Dynamic 为 JVM 提供了一种延迟解析常量的机制，通过引导方法将常量的创建推迟到首次使用，从而减少类加载开销和内存占用。它与 invokedynamic 共享引导方法机制，但用途不同。对于大型框架中的条件性常量，这是一种值得考虑的优化手段，但需要权衡实现复杂度和收益。