JVM 严格字段初始化规范进入预览阶段

## 背景

Java 虚拟机（JVM）的字段初始化长期依赖隐式默认值：未显式赋值的静态字段和实例字段，在首次使用时会被自动设置为 0、false 或 null。这种设计提供了基本的内存安全保障，但也带来了明显缺陷。当字段未初始化就被读取时，程序可能传递 null 或 0 值，导致后续 NullPointerException 等错误，且难以追溯源头。尤其对于 final 字段，在类或实例初始化过程中，该规则不适用，同一字段可能在不同初始化阶段读到不同值。

JDK 14 曾改进异常消息以指向具体行，但无法解决根本的初始化bug问题。Value Classes（值类）和 Null-restricted fields 等新语言特性对字段初始化提出了更高要求，需要更强的完整性保证，而现有模型已无法满足。

## 核心内容

JEP 539 提案引入了严格初始化字段（strictly-initialized fields）的 JVM 机制。这些字段必须在被读取前显式初始化，因此默认值 0 或 null 永远不会被观察到；对于 final 的严格初始化字段，所有读取都会观察到完全相同的数值。

此特性为 preview 版本 JVM 功能，仅供生成类文件的编译器使用，默认禁用。编译器（如 javac）负责标记符合语言特征的字段，设置类文件中的新标志 ACC_STRICT_INIT（值为 0x0800）。

目标：

• 为 JVM 基础编程语言的设计者提供比当前模型更强完整性保证的字段初始化模型。
• 给予这些设计者灵活性：每个静态和实例字段可自由选择是否 opt-in 使用新模型，或继续原有默认初始化模式。

非目标：

• 不引入新 Java 语言特性（如严格初始化修饰符）。
• 不改变 javac 的编译策略，以免对现有 Java 源码强制应用严格初始化。

动机与问题示例

Java 平台规定所有变量在使用前必须初始化，确保程序永不读取未初始化内存。若字段未显式初始化，则隐式设为默认值（0、false 或 null）。这些默认值虽提供安全网，但常被误解为合法数据，导致歧义。例如：

class App {
    public static final long appID = Log.currentPID(); // [1], [4], [6]
    public static void main() {
        IO.println("App[" + appID + "] has started");
        // ...
        Log.log("Completed 'main'");
    }
}

class Log {
    private static final String prefix = "App[" + App.appID + "]: "; // [3]
    public static void log(String msg) {
        IO.println(prefix + msg);
    }
    public static long currentPID() {
        return ProcessHandle.current().pid(); // [5]
    }
}

运行 App 时输出类似：

App[96052] has started
App[0]: Completed 'main'

差异源于：App 类初始化触发 Log 类初始化（[1]），Log 的 prefix 字段在默认值 0 被读取并嵌入字符串（[3]）。随后 App 的 currentPID 调用（[4]）赋值给 appID（[6]），但为时已晚。循环依赖与初始化顺序敏感性使此类 bug 难以复现和诊断。

大多数 Java 变量（局部变量）不受此影响，因需显式赋值；字段是唯一依赖默认值的。

严格初始化模型

提案替代默认初始化：JVM 确保标记的严格初始化字段在被读取前必须显式初始化。若为 final，所有读取值相同。这些属性从直观期望提升为 JVM 强制完整性保证。

字段完整性改进

此机制为 Value Classes 和 Null-restricted fields 奠定基础。Value Classes 实例无身份且不可变，其 final 实例字段需始终观察相同值；Null-restricted fields 不得存储 null，必须显式初始化非 null 值。

JVM 保持对现有程序无新行为：不强加新初始化规则给依赖默认值的代码。新特性可定义自定义规则并采用严格初始化，随着语言演进，组件逐步抵御字段初始化bug。

描述与规范

严格初始化字段无默认值：不可在显式初始化前读取；final 字段所有读取值一致。编译器用 ACC_STRICT_INIT 标志标记字段。

JVM 对严格初始化字段强制不变量：

• 实例字段：读取前不可访问；必须在 super() 构造函数前初始化。若 final，super() 后不可写入。违反任一约束会导致字节码验证失败。
• 静态字段：必须在 <clinit> 方法前初始化；final 字段初始化后不可再写。

优化机会：HotSpot JVM JIT 编译器将严格初始化 final 字段视为“trusted final field”，一旦读取后可复用同一值，减少内存交互，提升运行速度。

## 关键要点

• JEP 539 为 JVM 引入严格初始化字段机制，强制字段在读取前显式初始化，默认值 0/null 永不观察；final 字段所有读取值一致。
• 新标志 ACC_STRICT_INIT（0x0800）仅在 preview 版本类文件（XX.65535）及开启 preview 特性时生效。
• 实例字段初始化受 super() 构造函数顺序严格控制：必须在 super() 前初始化且不可后续写入；静态字段通过 <clinit> 显式初始化。
• 现有 Java 代码和程序行为不变，不强制编译器改变策略；仅供新 JVM 基础语言使用。
• 主要用于支撑 Value Classes（确保 final 实例字段一致性）和 Null-restricted fields（禁止 null 默认值），为后续语言特性奠定完整性基础。
• 受益于 HotSpot JIT：trusted final 字段支持值复用，提升优化效率。
• 仍处于 preview 状态（2026 年 6 月最新更新），需 --enable-preview 运行时启用。

## 意义与影响

此提案填补了 JVM 在字段初始化上的空白，为 JVM 生态提供更健壮的模型。它不改变现有 Java 语言或编译行为，却为 Value Classes、Null-restricted fields 等新特性铺平道路，随着这些特性逐步采用，代码质量将显著提升，减少因字段初始化bug 引发的生产事故。

对 JVM 实现者而言，增加了字节码验证和运行时检查，但同时开启了潜在性能优化（如 JIT 值缓存）。对语言设计者而言，提供了灵活的 opt-in 机制，便于逐步演进新规则而不破坏兼容性。总体而言，这标志着 Java 平台向更严格、安全的类型系统迈进，为下一代 JVM 语言奠定基础，同时保持对现有代码的友好性。