Java 开发者注意！JEP 500 将彻底改变 final 字段的使用方式

Java 开发者们，你们是否曾经因为反射修改 final 字段而头疼不已？现在，JEP 500 来了，它将彻底改变这一局面，让 final 字段真正不可变！这对于 Java 生态系统来说，可是一个重大变革哦。

1. 背景：final 字段的烦恼

在 Java 中，final 字段原本是用来表示不可变状态的，一旦赋值就不能再修改。这种不可变性在多线程环境中非常关键，能确保对象的安全初始化，还能让 JVM 进行性能优化，比如常量折叠。然而，Java 的反射 API 却允许通过一些手段修改 final 字段，这不仅破坏了代码的正确性预期，还限制了 JVM 的性能优化空间。

举个例子，假设我们有一个类 C，其中有一个 final 字段 x。正常情况下，x 的值在构造函数中赋值后就不应该再改变。但通过反射，我们可以轻易地修改它的值，这简直是对 final 字段不可变性的“挑衅”！

class C {
    final int x;
    C() { x = 100; }
}

通过反射，我们竟然可以将 x 的值从 100 改为 200，甚至 300！

java.lang.reflect.Field f = C.class.getDeclaredField("x");
f.setAccessible(true);      // 使 C 的 final 字段可变
C obj = new C();
System.out.println(obj.x);  // 打印 100
f.set(obj, 200);
System.out.println(obj.x);  // 打印 200
f.set(obj, 300);
System.out.println(obj.x);  // 打印 300

这种行为不仅让代码变得不可靠，还可能引发各种潜在的错误。而且，这种能力还和序列化库的需求冲突，因为序列化库在反序列化时需要修改字段来初始化对象。

2. JEP 500：让 final 字段真正不可变

为了解决这个问题，JEP 500 提出了一个方案，让 final 字段真正不可变。这个方案的核心思想是，在未来的 JDK 版本中，默认情况下不允许通过反射修改 final 字段。开发者如果需要修改 final 字段，必须在启动时显式启用这一能力。这样一来，final 字段的不可变性就得到了保障，同时也为 JVM 的性能优化提供了更多空间。

2.1 JDK 26 的变更

在 JDK 26 中，将限制深度反射，使得默认情况下修改 final 字段会在运行时发出警告。不能简单地通过使用 --add-opens 来启用带有 final 字段的类的深度反射来避免警告。

2.2 启用 final 字段修改

应用开发者可以通过命令行选项或替代方法启用特定 Java 代码的 final 字段修改，以避免警告和未来的异常。启用 final 字段修改表明应用需要修改 final 字段，并解除选定的 final 字段限制。

• 为类路径上的任何代码启用 final 字段修改，无论 final 字段在哪里声明，使用以下命令行选项：

$ java --enable-final-field-mutation=ALL-UNNAMED ...

• 为模块路径上的特定模块启用 final 字段修改，再次传递一个以逗号分隔的模块名称列表：

$ java --enable-final-field-mutation=M1,M2 ...

启用模块的 final 字段修改并不能保证模块中的代码能够通过深度反射修改 final 字段。要被修改的任何 final 字段还必须对执行深度反射的代码开放。

2.3 控制 final 字段限制的效果

如果代码位于未启用 final 字段修改的模块中，或者代码所在的模块未对字段的包开放，则代码通过深度反射修改 final 字段是非法的。当尝试非法修改 final 字段时，Java 运行时采取的操作由新的命令行选项 --illegal-final-field-mutation 控制。这个选项与 JDK 9 中 JEP 261 引入的 --illegal-access 选项以及 JDK 24 中 JEP 472 引入的 --illegal-native-access 选项在精神和形式上类似，其工作方式如下：

• --illegal-final-field-mutation=allow：允许修改而不发出警告。
• --illegal-final-field-mutation=warn：允许修改，但当特定模块中的代码首次执行非法 final 字段修改时发出警告。每个模块最多发出一个警告。这是 JDK 26 中的默认模式。它将在未来的版本中逐步淘汰，并最终被移除。
• --illegal-final-field-mutation=debug：与 warn 相同，但为每次非法 final 字段修改同时发出警告消息和堆栈跟踪。
• --illegal-final-field-mutation=deny：将导致 Field::set 为每次非法 final 字段修改抛出 IllegalAccessException。这种模式将在未来的版本中成为默认模式。

当 deny 成为默认模式时，allow 将被移除，但 warn 和 debug 至少在下一个版本中仍受支持。

2.4 final 字段修改的警告

当代码尝试非法修改 final 字段时，默认情况下，修改会成功，但 Java 运行时会发出警告，标识调用者：

WARNING: Final field f in p.C has been [mutated/unreflected for mutation] by class com.foo.Bar.caller in module N (file:/path/to/foo.jar)
WARNING: Use --enable-final-field-mutation=N to avoid a warning
WARNING: Mutating final fields will be blocked in a future release unless final field mutation is enabled

默认情况下，对于任何特定模块，最多发出一个这样的警告，仅当该模块尚未发出警告时才会发出。警告写入标准错误流。

2.5 识别修改 final 字段的代码

通过深度反射修改 final 字段的代码通常是库代码，而不是应用代码。可以通过以下方式精确识别修改 final 字段的代码：

• 使用上述方法启动 Java 运行时，即 --illegal-final-field-mutation=debug。
• 使用 JDK Flight Recorder (JFR) 启动 Java 运行时。当启用 JFR 时，每当代码修改 final 实例字段或使用 Lookup.unreflectSetter 获取对反射 final 字段具有写访问权限的 MethodHandle 时，JVM会记录一个 jdk.FinalFieldMutation 事件。此事件标识声明 final 字段的类、final 字段的名称以及堆栈跟踪，以显示 final 字段修改的来源。

例如，以下是如何创建 JFR 录制并显示 jdk.FinalFieldMutation 事件的方法：

$ java -XX:StartFlightRecording:filename=recording.jfr ...
$ jfr print --events jdk.FinalFieldMutation recording.jfr

3. 深度反射 API 的行为变更

在 JDK 26 中，深度反射 API 的行为发生了以下变化：

• Field::setAccessible 的行为保持不变。当代码对 Field 对象 f 调用 f.setAccessible(true) 时，代码必须与 f 反映的字段位于同一个模块中，或者如果代码位于不同的模块中，则 f 反映的字段必须通过导出或开放对调用者可访问。如果这些条件不满足，调用将抛出 InaccessibleObjectException。
• Field::set 的行为在 JDK 26 中发生了变化。如果代码对 Field 对象 f 调用 f.set(...)，并且 f 反映的字段是 final 的，则只有在满足以下条件时才会修改字段：
  • 已成功调用 f.setAccessible(true)；
  • 字段的声明类所在的包对调用者的模块开放；
  • 调用者的模块已启用 final 字段修改。
    如果模块未启用 final 字段修改，且该模块中的代码尝试通过深度反射修改任何 final 字段，则会抛出 IllegalAccessException，除非被 --illegal-final-field-mutation 抑制。

如果模块已启用 final 字段修改，且该模块中的代码尝试通过深度反射修改某个包中的 final 字段，但该包未对模块开放，则会抛出 IllegalAccessException，除非被 --illegal-final-field-mutation 抑制。

4. 相关方法的行为变更

• MethodHandles.Lookup::unreflectSetter 的行为变更与 Field::set 相同。
• Module::addOpens 方法允许模块 M 中的调用者在运行时将模块 N 中的包开放给另一个模块 O，前提是该包已对 M 开放。如果模块 M 和 N 均未在命令行上启用 final 字段修改，则 JVM 将信任该包中的 final 字段。随后，从 M 调用 addOpens 不会启用 O 修改该包中的 final 字段。即使 O 在命令行上已启用 final 字段修改，也是如此。
• ModuleLayer.Controller::addOpens 和 Instrumentation::redefineModule 的行为与上述相同。
• java.lang.System 类的 setIn、setOut 和 setErr 方法用于修改该类的 in、out 和 err 这些 final 字段。这些字段始终受到写保护，这意味着只能通过调用相应的方法来修改它们，而不能通过深度反射来修改。在 JDK 26 中，这些字段及其相应方法没有任何变化。

5. 序列化库的替代方案

为了应对未来版本中加强的 final 字段限制，序列化库将无法再直接使用深度反射来修改 final 字段。取而代之的是，序列化库的维护者应使用 sun.reflect.ReflectionFactory API 来序列化和反序列化对象。此 API 允许序列化库获取一个方法句柄，该方法句柄指向特殊代码，用于通过直接分配实例字段（包括 final 字段）的值来初始化对象。这种由 JDK 动态生成的代码赋予了序列化库与 JDK 自身序列化设施相同的权限，无需在序列化库的模块中启用 final 字段修改。

sun.reflect.ReflectionFactory 类仅支持反序列化实现了 java.io.Serializable 接口的类的对象。这一限制平衡了使用序列化库的开发者的利益与所有开发者对正确和高效执行的更广泛利益。它确保了 JVM 在执行优化（如常量折叠）时，不会过度限制其可以做出的假设：它必须假设可序列化对象中的 final 字段可能是可变的，但也可以假设所有其他对象中的 final 字段（占大多数）是永久不可变的。

如果未启用 final 字段修改，那么 sun.reflect.ReflectionFactory 将是唯一能够修改 final 字段的机制。如果 JVM 检测到某个类的 ReflectionFactory API 返回的方法句柄不会修改 final 字段，那么它可以将该类中的 final 字段视为永久不可变的。幸运的是，JVM 可能能够对许多 JDK 类做到这一点。例如，实现不可修改列表的 JDK 类通过调用它们的构造函数来反序列化，而不是通过分配它们的实例字段。对于这些类，ReflectionFactory 代码可以委托给类的反序列化方法，从而避免修改 final 字段。了解这一点后，JVM 可以信任每个不可修改列表的 final 字段，即使这些列表是由第三方库反序列化的。

6. 对其他库和框架的建议

一些依赖注入、单元测试和模拟框架等库使用深度反射来操作对象，包括修改 final 字段。这些组件的维护者应尽量避免要求用户启用 final 字段修改，而是寻找避免修改 final 字段或访问私有字段的架构方法。例如，大多数依赖注入框架现在禁止注入 final 字段，所有框架都建议使用构造函数注入，而不是字段注入。

7. 克隆方法的实现建议

带有 final 字段的类的作者在实现 clone 方法时一直面临挑战。如果 clone 方法的实现调用了 super.clone()，则它无法仅通过赋值来定制返回对象中的 final 字段的值。有时，clone 方法的实现会使用深度反射来修改这些字段，但这在未来的 JDK 版本中将不再可行，因为默认情况下不允许修改 final 字段。

Joshua Bloch 在 2001 年出版的《Effective Java》一书中建议避免使用 clone，并声明静态工厂方法（第 11 条：“谨慎覆盖 clone()”）。在必须继续实现 clone 的类中，应将 super.clone() 替换为通过（可能是非公共的）构造函数实例化类的代码。因为构造函数可以将 final 字段初始化为所需的值，所以 clone 方法无需使用深度反射。

8. 从本地代码修改 final 字段

本地代码可以通过调用 Java 原生接口（JNI）中定义的 Set<type>Field 函数或 SetStatic<type>Field 函数来修改 Java 字段。

对 final 字段调用这些函数的结果是未定义行为。这意味着 Java 构建程序的构建块，如对象、数组和类型，不再具有完整性。JVM 无法保证它们的行为符合其规范；例如，程序可能会在 JVM 不抛出异常的情况下访问数组边界之外的元素，从而导致内存损坏或进程崩溃。随着我们增强 JVM 的优化目录，这些优化利用了对 Java 代码施加的 final 字段限制，由于本地代码中未定义行为导致的奇怪结果的可能性变得越来越大。

由于已经存在由于未定义行为的可能性而对执行本地代码的限制，因此默认情况下 JVM 可以假设不会调用这些函数。然而，如果启用了本地访问，那么我们建议启用新的诊断功能，以减轻由于通过 JNI 修改 final 字段而导致的奇怪结果的风险：

• 如果使用启用了本地代码统一日志记录的应用程序启动（-Xlog:jni=debug），则对 final 字段调用上述 JNI 函数中的任何一个都会导致记录一条消息：

[0.20s][debug][jni] Set<type>Field of final instance field C.f

或者

[0.20s][debug][jni] SetStatic<type>Field of final static field C.f

• 如果使用启用了 JNI 函数额外检查的应用程序启动（-Xcheck:jni），则对 final 字段调用上述 JNI 函数中的任何一个都会导致打印一条警告。
  在未来版本的 JDK 中，我们可能会更改上述 JNI 函数，以便在对 final 字段调用时始终成功返回，但实际上不会进行任何修改。

对于通过 sun.misc.Unsafe API 修改 final 字段的 Java 代码，没有诊断功能。这种修改可能会违反完整性，并可能导致奇怪的错误或 JVM 崩溃。从 JDK 24 开始，我们已经开始移除 sun.misc.Unsafe 中可以用来修改 final 字段的方法。

9. 风险与假设

自 JDK 5 以来，Java 平台一直允许修改 final 字段，因此存在现有应用可能受到提议的 final 字段限制影响的风险。我们假设那些直接或间接依赖 final 字段修改的应用开发者能够通过 --enable-final-field-mutation 配置 Java 运行时来启用该功能，这与他们已经可以通过 --add-opens 配置 Java 运行时以禁用模块的强封装类似。

10. 替代方案

10.1 依赖推测优化

而不是强制 final 字段的不可变性，Java 运行时可以依赖推测：它可以乐观地假设 final 字段没有被修改，检测到修改发生时，再根据需要对代码进行去优化。

尽管推测性优化是 JVM 的 JIT 编译器的常用手段，但在这种情况下可能不够用。未来的计划优化可能不仅依赖于进程生命周期内的不可变性，还依赖于从一次应用运行到下一次的字段不可变性。

10.2 指定允许被修改的模块

而不是指定哪些模块的代码可以修改 final 字段，我们可以要求开发者指定哪些模块允许其 final 字段被修改。

修改 final 字段是不受欢迎的，因此最好在命令行上记录哪些模块的代码应该被更新，以不再尝试修改字段。相反，指定哪些模块的 final 字段可以被修改，不会记录它们为什么允许字段被修改，也不会鼓励库迁移到不修改那些字段。

10.3 指定修改和被修改的模块

我们可以要求 --enable-final-field-mutation 指定执行修改的模块以及包含被修改字段的模块。

这将是不必要的负担。在许多实际情况下，--enable-final-field-mutation 将与 --add-opens 一起指定，后者已经指定了深度反射的双方。

11. 总结

JEP 500 的实施，将让 final 字段真正不可变，提升 Java 程序的安全性和性能。虽然这一变化可能会对一些依赖反射修改 final 字段的代码产生影响，但通过合理的配置和调整，我们可以顺利过渡到新的时代。让我们一起期待一个更安全、更高效的 Java 生态系统吧！

---

12. 致谢

感谢您阅读到这里！如果您觉得这篇文章对您有所帮助或启发，希望您能给我一个小小的鼓励：

• 点赞：您的点赞是我继续创作的动力，让我知道这篇文章对您有价值！
• 关注：关注我，您将获得更多精彩内容和最新更新，让我们一起探索更多知识！
• 收藏：方便您日后回顾，也可以随时找到这篇文章，再次阅读或参考。
• 转发：如果您认为这篇文章对您的朋友或同行也有帮助，欢迎转发分享，让更多人受益！

您的每一个支持都是我不断进步的动力，非常感谢您的陪伴和支持！如果您有任何疑问或想法，也欢迎在评论区留言，我们一起交流！