從JVM角度看爲什麼final字段可以“延遲“到構造方法中初始化

我們都知道在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原理的書，但是看的再多也比不上自己去寫，這就跟我們高中數學課本上的公式原理都很簡單，但是題就是不會做是一樣的道理。