反射修改 final 字段的原理与 Java 内存模型解析

本文深入剖析了为何Java中通过反射“修改final字段”本质上是一种幻觉——从编译期常量折叠导致字段值被硬编码进字节码、到类加载阶段JVM对static final的模块化写保护与运行时写屏障拦截，再到JIT优化将final值常量化、以及Java内存模型（JMM）下反射修改破坏happens-before契约引发的严重可见性问题，层层揭示JVM在编译器、类加载器、运行时和内存模型四个层面构建的严密防线；所谓“成功修改”，不过是绕过表层检查的短暂假象，既不可靠、不可见、也不安全，真正理解这些机制，才能避免在高并发或高性能场景中埋下难以排查的隐患。

不能真正“修改”被 final 修饰的编译期常量字段，不是反射用得不对，而是 JVM 在多个层面主动拦截了这种操作——从编译器优化到类加载机制，再到运行时内存模型，层层设防。

编译期常量折叠：值根本不在运行时存在

当一个字段同时满足 static final + 编译期可确定的字面量值（如 public static final int PORT = 8080; 或 static final String MSG = "OK";），Javac 就会把它“内联”掉：

• 所有对该字段的引用，在字节码里直接替换成字面量，比如 System.out.println(PORT) 编译后变成 iconst_8080 指令；
• 运行时根本不会去读取这个字段的内存地址，也就没有“修改目标”；
• 即使你用反射成功改了字段底层值，PORT 在代码中仍显示为 8080，因为那根本不是变量访问，而是硬编码。

类加载与初始化阶段：final 字段被写保护锁定

JVM 在类加载的 准备阶段 分配内存并设默认值，在 初始化阶段 执行 方法完成 final 字段赋值。此后：

• 对于 static final 字段，JDK 9+ 模块系统默认禁止反射写入，调用 set() 会直接抛 IllegalAccessException；
• 即使绕过模块限制（如用 --add-opens），JVM 内部仍会对 final 字段做写屏障校验，部分版本（如 JDK 17）会拒绝修改并静默失败；
• 非 static 的 final 实例字段虽可在对象构造完成后临时覆盖，但 JIT 编译器可能已将其值常量化、缓存或内联，导致后续读取仍是旧值。

Java 内存模型（JMM）的可见性陷阱

final 字段在 JMM 中享有特殊语义保障：构造器内对 final 域的写入，对其他线程首次读取该对象引用时是“保证可见”的。但反射修改破坏了这一契约：

• 修改发生在对象构造完成之后，不触发 final 域的“安全发布”机制；
• 没有 happens-before 关系，其他线程可能永远看不到新值，或看到部分更新（尤其字段是引用类型且对象内容也被修改时）；
• 如果字段是基本类型（如 int），JIT 可能将其提升为寄存器常量，反射写入仅影响堆内存，而读取走的是寄存器副本。

为什么“清除 modifiers 中的 FINAL 位”有时看似成功？

有些示例代码通过反射修改 Field.modifiers 字段来移除 FINAL 标志，再调用 set()：

• 这本质上是在欺骗 JVM 的字段访问检查逻辑，并未解除 JVM 对 final 语义的底层约束；
• 它只对非编译期常量、非 static、且未被 JIT 优化掉读取路径的字段有短暂效果；
• 在 JDK 12+ 中，modifiers 字段本身被标记为 final，甚至无法通过反射修改；某些版本强制要求配合 Unsafe.putObject 或 VarHandle 才能落地。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《反射修改 final 字段的原理与 Java 内存模型解析》文章吧，也可关注golang学习网公众号了解相关技术文章。