美文网首页
从JVM角度看为什么final字段可以“延迟“到构造方法中初始化

从JVM角度看为什么final字段可以“延迟“到构造方法中初始化

作者: 司青玄 | 来源:发表于2020-09-01 19:38 被阅读0次

    我们都知道在Java中final字段都是要在定义时完成初始化工作的,否则通不过编译。但是有一处例外,那就是对于对象的字段来说final字段可以"延迟"到构造方法,或者static {}语句块中初始化,例如下面的代码

    public class FinalTest {
        private static final Object staticObj;
        private final Object noneStatic;
    
        static {
            staticObj = new Object();
        }
    
        public FinalTest() {
            noneStatic = new Object();
        }
    
    }
    

    是可以正常通过编译的。

    相信大部分朋友在初学阶段会把这当成一个语法特例记下来,但实际上在字节码层面这是非常合理的。近期笔者在实现自己的Mini-JVM时就意外发现了这个问题的答案,特此分享。

    "多"编译出来的字节码

    还是拿上面的代码为例,稍微修改一下,把手动编写的构造方法和static{}去掉:

    public class FinalTest {
        private static final Object staticObj = new Object();
        private final Object noneStatic = new Object();
    }
    

    如果用javap -verbose FinalTest来看一下编译后的class文件的话会有惊奇的发现:

      public com.fh.FinalTest(); // <init>构造方法
        descriptor: ()V
        flags: ACC_PUBLIC
        Code:
          stack=3, locals=1, args_size=1
             0: aload_0
             1: invokespecial #1                  // Method java/lang/Object."<init>":()V
             4: aload_0
             5: new           #2                  // class java/lang/Object
             8: dup
             9: invokespecial #1                  // Method java/lang/Object."<init>":()V
            12: putfield      #3                  // Field noneStatic:Ljava/lang/Object;
            15: return
          LineNumberTable:
            line 12: 0
            line 13: 4
            line 14: 15
    
      static {}; // <clinit>方法 
        descriptor: ()V
        flags: ACC_STATIC
        Code:
          stack=2, locals=0, args_size=0
             0: new           #2                  // class java/lang/Object
             3: dup
             4: invokespecial #1                  // Method java/lang/Object."<init>":()V
             7: putstatic     #4                  // Field staticObj:Ljava/lang/Object;
            10: return
          LineNumberTable:
            line 9: 0
            line 10: 10
    

    可以看到,虽然编译器确实自动生成了一个无参数的构造方法,但里面不是空的,竟然有字节码,而我们实际上并没有提供构造方法。仔细一看FinalTest()里的字节码的功能其实刚好是对字段noneStatic的初始化工作。同样的,我们并没有编写static {}代码,编译器却依然给们生成了静态语句块代码,而内容也恰好是staticObj的初始化。

    由此我们可以得出结论:对象或者类级别的字段其实是在构造方法或者static {}语句块中完成初始化的。这样一来,允许程序员把final字段"延迟"到构造方法或者static {}中初始化自然也是很正常的事了,因为本来就该如此。站在class文件结构的角度来看,字节码只是常量池中MethodRef,即方法引用常量的一个属性,因此如果我们在定义类/对象的字段时如果后面跟了赋值操作,那么这个操作的字节码别地方也没处待,只能放在常量池的方法引用常量中。这样的话放在构造方法或者static{}中就合情合理了。

    PS: 编译器会把static{}块中的代码抽象成一个叫<clinit>的特殊方法存储在class文件中

    <br />

    其实对于JVM的很多疑问都是可以通过尝试自己去实现一个JVM来解决的,笔者就是在实现JVM的过程中发现class文件中总是有一些"多余"的字节码"偶然"发现的。虽然市面上有很多讲解JVM原理的书,但是看的再多也比不上自己去写,这就跟我们高中数学课本上的公式原理都很简单,但是题就是不会做是一样的道理。

    相关文章

      网友评论

          本文标题:从JVM角度看为什么final字段可以“延迟“到构造方法中初始化

          本文链接:https://www.haomeiwen.com/subject/cpfbsktx.html