Java 字節碼視角揭秘實例初始化全過程：從成員變量到繼承多態的執行順序真相

前言：從字節碼看初始化本質

類初始化過程是 Java 基礎知識，但從 字節碼層面 深入理解各場景下的執行順序，能揭示許多源碼層面難以察覺的細節。本文基於 JDK 1.8 環境，通過 javap -c 反編譯字節碼，分析四大典型場景：

1. 成員變量 + 構造函數
2. 成員變量 + 代碼塊 + 構造函數
3. 靜態變量 + 靜態代碼塊
4. 繼承與多態

場景一：成員變量 + 構造函數

代碼聲明四個成員變量與無參構造函數，右側為字節碼棧幀執行順序。

核心發現

1. 隱式調用父構造函數：字節碼 (1) 處隱式調用 super()，決定了多重初始化順序（詳見場景四）；
2. 聲明賦值 vs 構造函數賦值：
   • myId1 聲明未賦值，構造函數中 myId1=100 才有指令；
   • myId2 聲明即賦值，優先於構造函數執行初始化指令；
3. null 賦值也會生成指令：myText2 = null 生成 aconst_null，構造函數中再次賦值又生成指令。null 非對象，JVM 中無明確類型，可視為「類型未定、未分配空間」的標志；
4. 總結規律：
   • 有賦值的成員按聲明順序初始化（與訪問修飾符無關）；
   • 成員初始化 優於 構造函數體代碼；
   • 所有初始化動作均在構造函數中完成（無顯式構造函數時編譯器生成默認構造函數）；
   • 建議：聲明成員時無需賦 null，待真實使用時再初始化或傳值。

場景二：非靜態代碼塊的影響

輸出結果：

text:null
text:text1-1

核心發現

1. 非靜態代碼塊編譯後 同樣被放入構造函數 中執行；
2. 代碼塊與成員變量初始化，按源碼中出現順序 執行（如圖 (2)(3)）；
3. 執行 (1) print 時，myText1 尚未初始化（含聲明賦值），故輸出 null；
4. 緊接著 (2) 賦值，(3) 又被覆蓋，故 (4) 輸出 text1-1；
5. 建議：盡量避免非靜態代碼塊，可讀性差，邏輯可移至構造函數。

場景三：靜態變量與靜態代碼塊

核心發現

1. 靜態變量與靜態代碼塊編譯後 合併到一個 <clinit> 方法 中，執行順序 = 源碼出現順序；
2. <clinit> 在類被 JVM 首次加載時調用一次，與實例化次數無關；
3. 圖中 (4)(5) 實例化兩個對象，但不觸發靜態代碼再次執行；
4. 聲明順序決定引用順序：(6) 處引用後聲明的 myStaticId2 為非法（編譯報錯）；
5. 觸發條件：類加載事件（首次 new、訪問靜態成員、反射、主類啟動等），非由實例化觸發。

場景四：繼承與多態（核心難點）

（原文未展開，此處補充核心結論）

• 子類實例化時，父類 <clinit> 先於子類 <clinit> 執行**；
• 實例初始化順序：**父類靜態 → 子類靜態 → 父類成員/代碼塊 → 父類構造函數 → 子類成員/代碼塊 → 子類構造函數**；
• 多態調用：構造函數中調用被重寫方法時，調用的是 子類實現，但此時子類成員尚未初始化，極易導致空指針或邏輯錯誤（嚴禁在構造函數中調用可重寫方法）。

1. 父類靜態變量/靜態代碼塊（按順序）
2. 子類靜態變量/靜態代碼塊（按順序）
3. 父類成員變量賦值/實例代碼塊（按順序）
4. 父類構造函數
5. 子類成員變量賦值/實例代碼塊（按順序）
6. 子類構造函數