Final字段竟可读到 null？JEP 500 正在重写 Java 不可变规则！

最终，Final 不再只是“看起来不能改”——Java 的不可变边界正在被彻底重定义！

Java 里那个看似人畜无害的 final 关键字，其实藏着整个 JVM 优化体系的命门？你以为加了 final 就万事大吉？线程安全？性能飞升？现实可能狠狠打你脸！

就在 JDK 26 即将落地的关键节点，一篇来自 Norlinder 研究组的深度解析，直接揭开 Java 内存模型（JMM）里关于 final 的终极真相——Final 不等于 Final，除非你真正理解“冻结点”（freeze point）在哪里。

更震撼的是，Oracle 正在推进 JEP 500：“让 Final 真正成为 Final”（Prepare to Make Final Mean Final），这意味着未来你通过反射强行修改 final 字段的操作将彻底失效。

这不只是技术细节的修补，而是一场面向“默认完整性”（Integrity by Default）的架构革命。本文将带你从单线程初始化陷阱、多线程数据竞争，一路杀到 Valhalla 项目的价值类型（value classes）核心要求，彻底搞懂：为什么 final 的边界，就是 Java 安全与性能的边界。

作者背景：站在并发与语言规范交叉口的极客团队

这篇文章背后站着的是 Norlinder 研究组，核心成员 Luke Cheeseman 正在死磕并发与数据竞争难题，其论文《When Concurrency Matters: behavior-Oriented Concurrency》被业内奉为行为导向并发设计的新标杆。

而本文作者——Norlinder 本人，则是那种会直接翻 Java 语言规范（JLS）而不是听信社区“传说”的硬核派。他强调：与其道听途说，不如直奔源头。

正是这种对规范文本的敬畏，让他在 JEP 500 公布后迅速意识到——Java 社区对 final 的认知，存在巨大盲区。尤其当 Valhalla 项目要求所有值类型字段必须为 final 时，搞不清 final 的“法律边界”（而非“道德边界”），你的代码可能在未来的 JDK 上直接崩盘。这不是危言耸听，而是即将发生的现实。

Final 到底是什么？别被“不可变”三个字骗了！

很多人以为 final = 不可变对象，大错特错！JLS（Java 语言规范）第 4.12.4 节写得明明白白：final 变量只能被赋值一次。重点在于“变量”——对于引用类型，这仅意味着引用本身不能变，对象内部状态照样可以改得面目全非。比如下面这段代码：

class User {
  private String username;
  public User(String username) { this.username = username; }
  public String getUsername() { return username; }
  public void setUsername(String username) { this.username = username; }
}

当你这样写：

final User user = new User("Mr. Duke");
user = new User(); // 编译报错！引用不能变

但你完全可以：

user.setUsername("Mr. Final"); // 合法！对象内容照样改

所以 final 实现的是“浅层不可变”（shallow immutability），不是深度冻结。真正的深度不可变，需要你把 User 内部的 username 也声明为 final：

private final String username;

这才叫粒度可控的不可变设计。但问题来了——即使你把字段全标 final，Java 仍可能让你看到“未初始化”的 null 值！这怎么可能？别急，初始化顺序的魔鬼，马上登场。

单线程下的“幽灵状态”：Final 字段竟可被读到 null？

你以为单线程环境就绝对安全？JLS 第 12.4.2 节允许“递归初始化”（recursive initialization），这就埋下了雷。看这个经典例子（保存为 BootSequence.java）：

public class BootSequence {
  public static class Bootloader {
    public static final KeyStore keyStore = new KeyStore();
    static {
      keyStore.observeFinalVariable();
    }
  }

  public static class KeyStore {
    public static final KeyStore cachedKeyStore;
    static {
      cachedKeyStore = Bootloader.keyStore;
    }
    public void observeFinalVariable() {}
  }

  public static void main(String[] args) {
    System.out.println(Bootloader.keyStore);
    System.out.println(KeyStore.cachedKeyStore);
  }
}

运行结果往往是：

BootSequence$KeyStore@28a418fc
null

天啊！一个 final 字段，居然在不同地方看到不同值？KeyStore 的静态块执行时，Bootloader 的 keyStore 还没完成赋值，于是 cachedKeyStore 拿到 null。这完全合法！JLS 故意允许这种“构造中可见性”，避免静态初始化死锁。但代价是：final 的不可变性，仅在“赋值完成后”生效。在此之前，它可能处于“幽灵状态”——不是数据竞争，却是逻辑陷阱。很多资深开发者栽在这里，只因误以为 final = 从声明起就“坚如磐石”。

多线程下的核爆现场：Final 字段竟可被读到默认值！

单线程只是开胃菜，多线程才是地狱模式。JLS 第 17 章（Java 内存模型）引入“冻结”（freeze）概念——只有构造函数执行完毕，final 字段才被“冻结”并全局可见。在此之前，别的线程可能看到默认值（比如 null、0）！这就是 JLS §17.5.2 明确允许的行为：如果读取发生在字段被赋值前，就看到默认值；否则看到赋值后的值。听起来合理？但现实是，很多开发者会“提前泄露 this”（prematurely leak this），导致灾难。看这个 Runner.java：

class Configuration {}

class ServiceRegistry {
  ServiceComponent cachedServiceComponent;

  void register(ServiceComponent component) {
    this.cachedServiceComponent = component;
  }
}

class ServiceComponent {
  final Configuration config;

  ServiceComponent(ServiceRegistry registry) {
    registry.register(this); // 危险！this 还没构造完就泄露了

    for (int i = 0; i < 1_000_000; i++) {
      Thread.yield();
    }

    this.config = new Configuration(); // 此时才赋值
  }
}

public class Runner {
  public static void main(String[] args) throws InterruptedException {
    for (int i = 0; i < 100_000; i++) {
      ServiceRegistry registry = new ServiceRegistry();
      Thread t1 = new Thread(() -> {
        new ServiceComponent(registry);
      });

      Thread t2 = new Thread(() -> {
        if (registry.cachedServiceComponent != null &&
                registry.cachedServiceComponent.config == null) {
          System.out.println("The cachedServiceComponent introduced an observable race!");
          System.exit(0);
        }
      });

      t1.start();
      t2.start();
      t1.join();
      t2.join();
    }
  }
}

跑几次，几乎必现：

The cachedServiceComponent introduced an observable race!

为什么？因为 t1 在构造 ServiceComponent 时，刚 register(this) 就被 t2 抢到，此时 config 还没赋值，所以是 null。注意：这不是未定义行为，而是 JLS 明确允许的“合法数据竞争”！

更绝的是，你不能用 volatile 修复——JLS 禁止 final 和 volatile 共存，因为 final 字段初始化后永不改变，volatile 的内存屏障开销纯属浪费。所以，安全发布（safe publication）的责任，100% 在开发者肩上。

JEP 500 来了！反射修改 Final 字段将成历史

现在，JEP 500 的意义就清晰了。它表面目标是：禁止通过 setAccessible 等反射手段修改 final 字段。但深层动机是——为 Valhalla 项目铺路。Valhalla 要引入值类型（value classes），而值类型要求所有字段必须是 final。如果 JVM 还得防着你用反射偷偷改 final，那还怎么大胆优化？比如 JIT 编译器想把 final 字段直接“常量折叠”（constant folding）进机器码，结果你反射一改，整个优化就崩了。所以 JEP 500 的哲学是：“完整性默认开启”（Integrity by Default）——强大功能（如深度反射）仍可用，但必须显式申请权限，而不是默认开放。这就像给 JVM 吃了一颗定心丸：“从今往后，final 字段真的 final 了，我可以放心优化！”

未来已来：你的代码准备好迎接“Final 即 Final”时代了吗？

JEP 500 不是终点，而是起点。当 Valhalla 上线，值类型普及，final 将从“可选项”变为“强制项”。而那些依赖“提前泄露 this”、或靠反射 hack final 字段的代码，将面临性能退化甚至运行时崩溃。JVM 的优化能力越强，对代码规范的要求就越高。

Java 内存模型的设计哲学从来不是“傻瓜安全”，而是“在开发者守规矩的前提下，榨干最后一滴性能”。所以，真正的安全，不来自 JVM 的保姆式保护，而来自你对 JLS 边界的敬畏。

总结与行动指南

Final 关键字在 Java 中仅保证“赋值一次”，不保证“立即可见”或“深度不可变”。单线程中因初始化顺序可能读到未赋值状态，多线程中因未安全发布可能读到默认值。JEP 500 将禁止反射修改 final 字段，为 Valhalla 值类型和 JVM 深度优化铺路。

开发者必须：1）避免在构造函数中泄露 this；2）确保对象完全构造后再发布；3）理解 final 的 JLS 边界，而非依赖直觉。
唯有如此，才能在“Final 即 Final”的新时代，既享受性能红利，又避开并发陷阱。