JDK14及以后Java System类中static final字段的初始化疑问

一、为什么static final的in/out/err不会被null覆盖？ #

你观察到的源码层面的矛盾（静态代码块先执行registerNatives()，之后字段初始化赋值null）其实是VM对核心类的特殊处理导致的表象，实际流程如下：

1. VM提前初始化，绕过Java层赋值逻辑
   System类作为JVM的核心基础类，其初始化流程并不完全遵循普通Java类的<clinit>执行顺序。在System类的<clinit>方法执行之前，VM会直接通过native机制调用initPhase1()方法，将in/out/err赋值为实际的标准流对象。
2. VM忽略<clinit>中的null赋值指令
   虽然源码中in/out/err被声明为static final InputStream in = null，对应的字节码里会包含给这些字段赋值null的指令，但VM会检测到这些字段已经被提前初始化，因此会跳过这些赋值操作，确保之前设置的有效流对象不会被覆盖。
3. Native层可修改final字段
   从Java语法上看，final字段一旦赋值就不可修改，但native层可以直接操作内存中的字段数据，不受Java访问控制的限制。VM正是利用这一点，在类初始化流程之外完成了in/out/err的有效赋值。

二、initPhase1()的定义及具体流程 #

定义 #

initPhase1()是System类中的私有静态方法，仅由VM调用，源码逻辑如下：

private static void initPhase1() {
    in = new FileInputStream(FileDescriptor.in);
    out = new PrintStream(new FileOutputStream(FileDescriptor.out));
    err = new PrintStream(new FileOutputStream(FileDescriptor.err));
}

这个方法在Java层没有被显式调用，完全由VM在启动阶段触发。

具体流程 #

1. 触发时机：VM启动时，在加载System类之后、执行其<clinit>方法之前，会通过native调用触发initPhase1()。
2. 流对象创建：
   • 为in创建FileInputStream实例，关联底层的标准输入文件描述符FileDescriptor.in；
   • 为out和err分别创建FileOutputStream实例，关联标准输出/错误输出的文件描述符，再包装为PrintStream（提供字符输出能力）；
3. 赋值final字段：VM直接将上述创建的流对象赋值给static final的in/out/err字段，绕过Java层的final访问限制；
4. 后续流程：完成initPhase1()后，VM才会执行System类的<clinit>方法，此时registerNatives()仅负责注册其他native方法（如currentTimeMillis()、arraycopy()等），不会修改in/out/err的值。

内容的提问来源于stack exchange，提问作者Dmytro Kostenko