之前在網上看到一道面試題,很形象的描述了類的加載初始化程序,要完全理解這道題,就不得不深入理解類加載的程序,面試題如下:
class SingleTon {
private static SingleTon singleTon = new SingleTon();
public static int count1;
public static int count2 = 0;
private SingleTon() {
count1++;
count2++;
}
public static SingleTon getInstance() {
return singleTon;
}
}
public class Test {
public static void main(String[] args) {
SingleTon singleTon = SingleTon.getInstance();
System.out.println("count1=" + singleTon.count1);
System.out.println("count2=" + singleTon.count2);
}
}
這道題的正確答案為 :
count1=1
count2=0
至于為什么會是這個答案,這就涉及到了 JVM 類加載的程序,
類的生命周期
類從被加載到虛擬機記憶體中開始,到卸載出記憶體為止,它的整個生命周期包括加載、驗證、準備、決議、初始化、使用和卸載 7 個階段,其中驗證、準備和決議 3 個階段統稱為連接,這 7 個階段發生的順序如下圖所示,

加載、驗證、準備、初始化和卸載這 5 個階段的順序是確定的,決議階段則不一定,由于支持運行時系結,類可以在初始化之后再開始進行決議,同時這些階段只是按照順序進行開始,并不一定會按照順序進行或者結束,因為這些階段通常都是互相交叉地混合式進行的,通常會在一個階段執行程序中呼叫、激活另外一個階段,
類的加載程序
加載
加載是類加載程序的一個階段,是根據特定名稱查找類或介面型別的二進制表示(binary representation),并由此二進制表示來創建類或介面的程序,在加載階段,虛擬機需要完成 3 件事:
- 通過一個類的全限定名來獲取定義此類的二進制位元組流,
- 將這個位元組流所代表的靜態存盤結構轉化為方法區的運行時資料結構,
- 在記憶體中生成一個代表這個類的 java.lang.Class 物件,作為方法區這個類的各種資料的訪問入口,
加載途徑
虛擬機加載的是類的二進制流,只是對內容格式做了限制,并沒有指名要從哪里去獲取、怎樣獲取一個類的二進制流,比較常見的有一下幾種:
- 從 jar、ear、war 包中讀取,
- 從網路流中讀取,這種場景的典型應用就是 Applet,
- 運行時計算生成,使用最多的就是動態代理技術,
- 其他檔案生成,典型的場景是 JSP 應用,即由 JSP 檔案生成對應的 Class 類,
加載方式
- 對于一個非陣列類,加載階段可以使用系統提供的引導類加載器來完成,也可以由用戶自定義的類加載器去完成,
- 陣列類是 Java 虛擬機直接創建的,一個陣列類創建的程序遵循以下規則:
- 陣列的元素是參考型別,那就遞回采用本文所講的類加載程序加載這個元素,陣列類將在加載該元素型別的類加載器的類名稱空間上被標識,
- 如果陣列的元素型別不是參考型別(例如:int[] 陣列),Java 虛擬機將會把陣列類標記與引導類加載器關聯,
- 陣列的可見性與他的元素型別的可見性一致,如果元素型別不是參考型別,那陣列的可見性將默認為 public,
加載階段完成后,二級制位元組流就按照虛擬機所需的格式儲存在方法區之中,然后在記憶體中實體化一個 java.lang.Class 物件,將這個物件作為程式訪問方法區中的這些型別資料的外部介面,
驗證
驗證時連接階段的第一步,這一步是為了保證 Class檔案二進制位元組流符合虛擬機規范,并且不會危害虛擬機自身的安全,Java 虛擬機規范有大量的約束和驗證規則,詳細的描述的驗證程序,驗證程序主要還是圍繞 Class 檔案格式對各部分進行驗證,Class 檔案格式課參考另一篇博文位元組碼檔案結構詳解,但從整體上看,驗證階段大致會完成下面 4 個階段的驗證動作,
檔案格式驗證
第一階段要驗證位元組流是否符合 Class檔案格式規范,并且能被當前版本的虛擬機處理,這一階段可能包括下面驗證點:
- 是否一魔數 0xCAFEBEBE 開頭,
- 主次版本號是否在當前虛擬機處理范圍之內,
- 常量池中的常量是否有不被支持的常量型別(檢查常量 tag 標志),
- 指向常量的各種索引值中是否有指向不存在的常量或不符合型別的常量,
- .......
第一階段的驗證遠不止這些,該階段的主要目的是保證輸入的位元組流能正確的決議并存盤于方法區內,這階段的驗證是基于二進制位元組流進行的,只有通過了這個階段的驗證后,位元組流才會進入記憶體的方法區中進行存盤,所以后面的3個驗證階段全部是基于方法區的存盤結構進行的,不會再直接操作位元組流,
元資料驗證
元資料驗證是對位元組碼描述的資訊進行語意分析,確保其描述的資訊符合 Java 語言規范的要求,這個階段可能包括的驗證點如下:
- 這個類是否有父類(出了 java.lang.Object 之外,所有的類都應當有父類),
- 這個類是否繼承了不允許被繼承的類(被 final 修飾的類),
- 如果這個類不是抽象類,是否實作了其父類或介面之中要求實作的所有方法,
- 類中的欄位、方法是否與父類產生矛盾(例如覆寫了父類的final欄位,或者出現不符合規則的方法多載,例如方法引數都一致,但回傳值型別卻不同等),
位元組碼驗證
位元組碼驗證將對類的方法體進行校驗分析,保證被校驗類的方法在運行時不會做出危害虛擬機安全的事件,
- 保證任意時刻運算元堆疊的資料型別與指令代碼序列都能配合作業,
- 保證跳轉指令不會跳轉到方法體以外的位元組碼指令上,
- 保證方法體中的型別轉換是有效的,
如果一個方法通過了位元組碼驗證,也不能說明其一定就是安全的,
符號參考驗證
符號參考驗證可以看做是對類自身以外(常量池中的各種符號參考)的資訊校驗,通常需要校驗一下內容:
- 符號參考中通過字串描述的全限定名是否能找到對應的類,
- 在指定類中是否存在符合方法的欄位描述符以及簡單名稱所描述的方法和欄位,
- 符號參考中的類、欄位、方法的訪問性(private、protected、public、default)是否可被當前類訪問,
如果一個類無法通過符號參考驗證,那么將會拋出一個java.lang.IncompatibleClassChangeError例外的子類,如常見的java.lang.IllegalAccessError、java.lang.NoSuchFieldError、java.lang.NoSuchMethodError等,
準備
準備階段是正式為類變數分配記憶體并設定類變數初始值的階段,這些類變數所使用的記憶體都將在方法區中進行分配,此處需要明確類變數的含義,即被static修飾的變數,而不包括實體變數,實體變數會在初始化階段隨著物件一起分配在 Java 堆中,此時分配的初始值是資料型別的零值,并不是我們定義的初始值,此處還要明確一個概念,如果變數被final修飾,則此欄位的欄位屬性表存在 ConstantValue 屬性,那么在準備階段變數就會被初始化為 ConstantValue屬性所指定的值,可通過下例代碼來對照理解:
public static int a = 10;
public static final int B = 20;
其部分匯編位元組碼為:
Constant pool:
#2 = Fieldref #3.#21 // tech/techstack/blog/Test.a:I
#3 = Class #22 // tech/techstack/blog/Test
#5 = Utf8 a
#6 = Utf8 I
#21 = NameAndType #5:#6 // a:I
#22 = Utf8 tech/techstack/blog/Test
public static int a;
descriptor: I
flags: ACC_PUBLIC, ACC_STATIC
public static final int B;
descriptor: I
flags: ACC_PUBLIC, ACC_STATIC, ACC_FINAL
ConstantValue: int 20
static {};
descriptor: ()V
flags: ACC_STATIC
Code:
stack=1, locals=0, args_size=0
0: bipush 10
2: putstatic #2 // Field a:I
5: return
LineNumberTable:
line 8: 0
從上述代碼可以看出,B 欄位對應的 field_info 與 a 欄位對應的 field_info 相比對了一個 Constant_Value 屬性,而 Constant_Value 屬性的值 20 就會在準備階段直接賦給欄位 B,同時在位元組碼第 19 行有一個 static {};方法,此方法對應的就是類的構造方法<clinit>在初始化階段執行,它的Code屬性中對應的位元組碼指令bipush 10為往運算元堆疊壓入 10,putstatic 則是將值 10 賦值給 a 欄位,
基本資料型別的零值:
資料型別 零值 byte (byte)0 char '\u0000' short (short)0 boolean false int 0 long 0l float 0.0f double 0.0 reference null
決議
決議階段是虛擬機將常量池內的符號參考替換為直接參考的程序,符號參考在 Class 檔案中以 CONSTANT_Class_info、CONSTANT_Feildref_info、CONSTANT_Methodref_info 等型別的常量出現,具體可以參考博文位元組碼檔案結構詳解,此處有符號參考和直接參考兩個概念需要了解一下.
符號參考(Symbolic References)
符號參考以一組符號來描述所參考的目標,符號參考可以是任何形式的字面量,只要使用能無歧義地定義到目標即可,符號參考與虛擬機實作的記憶體布局無關,參考的目標不一定已經加載到記憶體中,各種虛擬機實作的記憶體布局可以各不相同,但是它們能接受的符號參考必須都是一致的,符號參考的字面量形式需要明確的定義在 Class 檔案格式中,
直接參考(Direct References)
直接參考可以是直接執行目標的指標、相對偏移量或是一個能間接定位到目標的句柄,直接參考是和虛擬機實作的記憶體布局相關的,同一個符號參考在不同的虛擬機實體上翻譯出來的直接參考一般不會相同,如果有了直接參考,那參考目標必定已經出現在記憶體中,
關于符號參考和直接參考兩個概念看起來很空洞,此處放一個 R 大的回答:傳送門
虛擬機規范并未規定決議發生的具體時間,只要求在執行anewarray、checkcast、getfield、getstatic、instanceof、invokedynamic、invokeinterface、invokespecial、invokestatic、invokevirtual、ldc、ldc_w、multianewarray、new、putfield和 putstatic這 16 個用于運算子號參考的位元組碼指令之前,先對他們所使用的符號參考進行決議,所以虛擬機實作可以根據需要來判斷到底是在類被加載和加載時就對常量池中的符號參考進行決議還是等到一個符號參考將要被使用前才去決議它,
加載程序中的決議階段為靜態的將符號參考替換為直接參考的程序,可與虛擬機堆疊記憶體中的動態鏈接參照記憶,
決議動作主要針對類或介面、欄位、類方法、介面方法、方法型別、方法句柄和呼叫限定符 7 類符號參考進行,分別對應于常量池的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_InterfaceMethodref_info、CONSTANT_MethodType_info、CONSTANT_MethodHandle_info和CONSTANT_InvokeDynamic_info 7種常量型別,
初始化
初始化階段是類加載程序中的最后一步,此階段才是真正執行類中定義的 Java 程式代碼,初始化階段和準備階段的初始化是不同概念的,準備階段的初始化是給類欄位賦值零值的程序,而類加載程序中的初始化階段可以看做是類物件的初始化,對于類的初始化反映到位元組碼中就是類的<clinit>()方法,從另外一個角度來講,可以將初始化階段理解成是執行類構造器<clinit>()方法的程序,同時對于<clinit>()方法,有幾個概念要弄清楚,
<clinit>()方法是由編譯器自動收集類中的所有類變數的賦值動作和靜態陳述句塊(static {})中的陳述句合并產生的,- 編譯器收集的順序是由陳述句在源檔案中出現的順序決定的,靜態陳述句塊中只能訪問到定義在靜態陳述句塊之前的變數,定義在它之后的變數,在靜態陳述句塊中可以賦值,但不能訪問,
- 在執行子類的
<clinit>()方法之前,虛擬機會確保子類的<clinit>()方法已經執行完畢,因此在虛擬機中第一個被執行的<clinit>()方法的類肯定是java.lang.Object, - 介面中不能使用靜態代碼塊,但仍有變數初始化的賦值操作,因此介面也會生成
<clinit>()方法,與類不同的是,執行介面<clinit>()方法不需要先執行父介面的<clinit>()方法,只有當父介面中定義的變數使用時,父介面才會初始化,介面的實作類在初始化時也不會執行介面的<clinit>()方法, - 在多執行緒的情況下,虛擬機會保證一個類的
<clinit>()方法只被一個執行緒呼叫,其它執行緒會被阻塞,同時,在一個類加載器下,一個類的<clinit>()方法只會被執行一次,
注:
本文所說的類物件與類實體不是一個概念,關于類物件與類實體以及 java.lang.Class 物件之間的關系,此處可以參考
R 大的一個回答傳送門:在HotSpot VM中,物件(類的實體物件)、類的元資料(InstanceKlass)、類的Java鏡像(java.lang.Class 實體),三者之間的關系是這樣的:
Java object InstanceKlass Java mirror [ _mark ] (java.lang.Class instance) [ _klass ] --> [ ... ] <-\ [ fields ] [ _java_mirror ] --+> [ _mark ] [ ... ] | [ _klass ] | [ fields ] \ [ klass ]每個Java物件的物件頭里,_klass欄位會指向一個VM內部用來記錄類的元資料用的InstanceKlass物件;InsanceKlass里有個_java_mirror欄位,指向該類所對應的Java鏡像——java.lang.Class實體,HotSpot VM會給Class物件注入一個隱藏欄位“klass”,用于指回到其對應的InstanceKlass物件,這樣,klass與mirror之間就有雙向參考,可以來回導航,這個模型里,java.lang.Class實體并不負責記錄真正的類元資料,而只是對VM內部的InstanceKlass物件的一個包裝供Java的反射訪問用,
通過上面的參考,可以清楚的知道 Java Object, InstanceKlass, Java mirror(java.lang.Class instance)在記憶體中的分布了,
對于初始化階段可以通過代碼來理解一下:
public class SuperClass {
public static int superClassField = 1;
static {
System.out.println("supper class static code");
}
public SuperClass() {
System.out.println("supper class constructor");
}
}
public interface SuperInterface {
int superInterfaceField = 10;
}
public class SubClass extends SuperClass implements SuperInterface {
public static int subClassField = 20;
static {
System.out.println("sub class static code.");
}
public SubClass() {
System.out.println("sub class constructor");
}
}
public class TestClassLoad {
static {
System.out.println("test class load");
}
}
public class App {
static {
System.out.println("App main static code");
}
public static void main(String[] args) {
System.out.println(SubClass.superClassField);
System.out.println("----------------------");
new Thread(SubClass::new).start();
}
}
在運行 SubClass 的時候加上 -XX:+TraceClassLoading 引數,列印出來運行程序中加載的類,上述代碼運行結果為結果 1:
// 類加載日志(節選)
[Loaded tech.stack.App from file:/Users/chenjianyuan/IdeaProjects/course/target/classes/]
[Loaded tech.stack.SuperInterface from file:/Users/chenjianyuan/IdeaProjects/course/target/classes/]
[Loaded tech.stack.SuperClass from file:/Users/chenjianyuan/IdeaProjects/course/target/classes/]
[Loaded tech.stack.SubClass from file:/Users/chenjianyuan/IdeaProjects/course/target/classes/]
App main static code
supper class static code
1
----------------------
sub class static code.
supper class constructor
sub class constructor
注釋掉new Thread(SubClass::new).start();重新運行程式,得到一下輸出結果 2:
[Loaded tech.stack.App from file:/Users/chenjianyuan/IdeaProjects/course/target/classes/]
[Loaded tech.stack.SuperInterface from file:/Users/chenjianyuan/IdeaProjects/course/target/classes/]
[Loaded tech.stack.SuperClass from file:/Users/chenjianyuan/IdeaProjects/course/target/classes/]
[Loaded tech.stack.SubClass from file:/Users/chenjianyuan/IdeaProjects/course/target/classes/]
App main static code
supper class static code
1
----------------------
然后將 System.out.println(SubClass.superClassField); 替換為 System.out.println(SubClass.subClassField); 再次運行程式,得到輸出結果 3:
[Loaded tech.stack.App from file:/Users/chenjianyuan/IdeaProjects/course/target/classes/]
[Loaded tech.stack.SuperInterface from file:/Users/chenjianyuan/IdeaProjects/course/target/classes/]
[Loaded tech.stack.SuperClass from file:/Users/chenjianyuan/IdeaProjects/course/target/classes/]
[Loaded tech.stack.SubClass from file:/Users/chenjianyuan/IdeaProjects/course/target/classes/]
App main static code
supper class static code
sub class static code.
20
----------------------
這幾段代碼資訊量很大,根據上文所講慢慢分析:
- 加載
- 從類加載日志從看到
TestClassLoad類始終都沒有被加載,而App、SuperInterface、SuperClass、SubClass始終被加載,是不是可以證明屬于 Applicatin 作用域范圍內的類會在首次使用時加載, - 對比結果 1 和結果 2 以及沒有顯示呼叫
SuperInterface任何方法、變數可以看出對于子類來說,在加載子類時首先要加載實作的介面以及父類,
- 從類加載日志從看到
- 初始化
-
當虛擬機啟動時,用戶需要指定一個要執行的主類(包含main()方法的那個類),虛擬機會先初始化這個主類,
-
結果 1 結果 3 都表明父類的
<clinit>()方法在子類<clinit>()方法之前呼叫, -
結果 1 結果 2 對比表明通過子類呼叫父類的靜態的變數只會引起父類的初始化并不會使子類初始化,
-
對比結果 1 和結果 2 說明在多執行緒的情況況下只要類加載器相同,類只初始化一次,
-
對比結果 1、2、3 能得出一個實體的初始化順序
- 父類 static 代碼塊即父類的
<clinit>()方法, - 子類的 static 代碼塊即子類的
<clinit>()方法, - 父類的構造方法即父類的
<init>()方法, - 子類的構造方法
<init>()方法、
- 父類 static 代碼塊即父類的
-
注:
關于類實體的初始化程序即物件的實體化程序會專門在另一篇博客進行講解,
關于"介面中不能使用靜態代碼塊,但仍有變數初始化的賦值操作,因此介面也會生成
<clinit>()方法," 在介面中變數初始化賦值操作可參考如下代碼:public interface SuperInterface { int superInterfaceField = 10; SuperClass su = new SuperClass(); } // bytecode { public static final int superInterfaceField; descriptor: I flags: ACC_PUBLIC, ACC_STATIC, ACC_FINAL ConstantValue: int 10 public static final tech.stack.SuperClass su; descriptor: Ltech/stack/SuperClass; flags: ACC_PUBLIC, ACC_STATIC, ACC_FINAL static {}; descriptor: ()V flags: ACC_STATIC Code: stack=2, locals=0, args_size=0 0: new #1 // class tech/stack/SuperClass 3: dup 4: invokespecial #2 // Method tech/stack/SuperClass."<init>":()V 7: putstatic #3 // Field su:Ltech/stack/SuperClass; 10: return LineNumberTable: line 10: 0 }
類的加載時機
關于類在什么時候加載,我們可以有上面的代碼窺見一斑,但是這只是在JDK1.8, Hotspot 虛擬機測驗的情況下得出的結論,也不一定會是正確的,因為 Java 虛擬機規范中并沒有進行強制約束,關于加載階段,都是根據虛擬機的具體實作來自由把握,但是對于初始化階段,虛擬機嚴格規定了有且只有 5 種情況必須立即對類進行初始化(而加載、驗證、準備自然需要再次之前開始):
- 遇到
new、getstatic、putstatic或invokestatic這4條位元組碼指令時,如果類沒有進行過初始化,則需要先觸發其初始化,生成這4條指令的最常見的Java代碼場景是:使用new關鍵字實體化物件的時候、讀取或設定一個類的靜態欄位(被final修飾、已在編譯期把結果放入常量池的靜態欄位除外)的時候,以及呼叫一個類的靜態方法的時候(已通過上文代碼驗證), - 使用java.lang.reflect包的方法對類進行反射呼叫的時候,如果類沒有進行過初始化,則需要先觸發其初始化,
- 當初始化一個類的時候,如果發現其父類還沒有進行過初始化,則需要先觸發其父類的初始化(上文代碼也已驗證),
- 當虛擬機啟動時,用戶需要指定一個要執行的主類(包含main()方法的那個類),虛擬機會先初始化這個主類(上文代碼也已驗證),
- 當使用JDK 1.7的動態語言支持時,如果一個java.lang.invoke.MethodHandle實體最后的決議結果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄,并且這個方法句柄所對應的類沒有進行過初始化,則需要先觸發其初始化,
嘗試著補充解釋一下這幾條其中的原理,對于 new 關鍵字自然不用多說,new 關鍵字實體化類的實體物件之前自然會執行類的初始化操作,以完成 Java 程式對類的一些操作,getstatic putstatic 指令的含義為讀取或設定一個類的靜態欄位,此處還是應用R大的回答,原文與上處參考出自同一處:
從JDK 1.3到JDK 6的HotSpot VM,靜態變數保存在類的元資料(InstanceKlass)的末尾,而從JDK 7開始的HotSpot VM,靜態變數則是保存在類的Java鏡像(java.lang.Class實體)的末尾,假如有這樣的A類:
class A { static int value = https://www.cnblogs.com/41uLove/p/1; }那么在JDK 6或之前的HotSpot VM里:
Java object InstanceKlass Java mirror [ _mark ] (java.lang.Class instance) [ _klass ] --> [ ... ] <-\ [ fields ] [ _java_mirror ] --+> [ _mark ] [ ... ] | [ _klass ] [ A.value ] | [ fields ] \ [ klass ]可以看到這個A.value靜態欄位就在InstanceKlass物件的末尾存著了,而在JDK 7或之后的HotSpot VM里:
Java object InstanceKlass Java mirror [ _mark ] (java.lang.Class instance) [ _klass ] --> [ ... ] <-\ [ fields ] [ _java_mirror ] --+> [ _mark ] [ ... ] | [ _klass ] | [ fields ] \ [ klass ] [ A.value ]可以看到這個A.value靜態欄位就在java.lang.Class物件的末尾存著了,
據此我們應該就能得出結論,在設定靜態變數的時候已經需要根據InstanceKlass生成java.lang.Class物件了,而靜態變數已經不能在方法區通過讀取類元資訊進行獲取或者儲存,而生成 Java mirror 必然要通過完整的類元資訊,因此需要進行初始化動作,對于java.lang.reflect包的反射方法,其根據的就是 java.lang.Class物件,對于子類初始化時,因為 Java 的繼承特性,繼承的是父類完整的類資訊,父類進行初始化也是理所當然的,
上述 5 種場景中的行為稱為對一個類的主動參考,除此之外,所有的參考類的方式都不會觸發初始化,稱為被動參考,例:
-
通過子類呼叫父類的靜態欄位(變數+常量),不會導致子類的初始化,代碼可參考上文,
-
通過陣列定義來參考類,不會觸發此類的初始化
public class App { public static void main(String[] args) { SuperClass[] superClasses = new SuperClass[10]; } } -
常量在編譯階段會存入呼叫類的常量池中,本質上并沒有直接參考到定義常量的類,因此不會觸發定義常量的類的初始化,
public class ConstantClass { public static final String HELLO_WORLD = "hello world !"; } public class App { public static void main(String[] args) { System.out.println(ConstantClass.HELLO_WORLD); } }這是因為雖然在Java原始碼中參考了ConstClass類中的常量HELLOWORLD,但其實在編譯階段通過常量傳播優化,已經將此常量的值"hello world !"存盤到了App類的常量池中,以后App對常量HELLO_WORLD的參考實際都被轉化為App類對自身常量池的參考了,也就是說,實際上App的Class檔案之中并沒有ConstantClass類的符號參考入口,這兩個類在編譯成Class之后就不存在任何聯系了,可以看一下App的位元組碼,
Constant pool: #4 = String #25 // hello world ! #25 = Utf8 hello world ! { public static void main(java.lang.String[]); descriptor: ([Ljava/lang/String;)V flags: ACC_PUBLIC, ACC_STATIC Code: stack=2, locals=1, args_size=1 0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream; 3: ldc #4 // String hello world ! 5: invokevirtual #5 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 8: return LineNumberTable: line 10: 0 line 11: 8 LocalVariableTable: Start Length Slot Name Signature 0 9 0 args [Ljava/lang/String; }
例題決議
其實講到這里,這道題也算是分析完了,那么就根據上面所講,總結一下這道題:
- 運行
Test類的 main 方法,回顧勺ò趕定要先加載、驗證、初始化Test類(由于加載、驗證必然發生在初始化之前,下面分析就忽略這兩個階段), SingleTon.getInstance()為Test類呼叫SingleTon類的靜態方法,必然引起SingleTon類的初始化,SingleTon類存在singleToncount1count2三個靜態變數,因此這三個靜態變數會被編譯器順序收集值到<clinit>()方法中,<clinit>()開始就是new SingleTon()會創建SingleTon類的實體singleTon,此時 ``singleTon.count1singleTon.count2` 值都為 1,<clinit>()操作完第一個變數singleTon之后便是對第二個變數count1操作,此時就會將 1 賦值給SingleTon變數count1,<clinit>()后續操作便是執行count2 = 0即通過運算元堆疊將 0 賦值給SingleTon變數count2,
查看SingleTon 的位元組碼:
{
static {};
descriptor: ()V
flags: ACC_STATIC
Code:
stack=2, locals=0, args_size=0
0: new #5 // class tech/stack/SingleTon
3: dup
4: invokespecial #6 // Method "<init>":()V
7: putstatic #4 // Field singleTon:Ltech/stack/SingleTon;
10: iconst_0
11: putstatic #3 // Field count2:I
14: return
LineNumberTable:
line 4: 0
line 6: 10
}
其 static{} 方法執行流程正如上文分析,不妨想一下如果將private static SingleTon singleTon = new SingleTon();移動到public static int count2 = 0;下面將會輸出什么結果?
總結

參考:
[1] 周志明.深入理解Java虛擬機:JVM高級特性與最佳實踐.北京:機械工業出版社,2013.
[2] Chapter 5. Loading, Linking, and Initializing
[3] JVM里的符號參考如何存盤?
[4] JVM符號參考轉換直接參考的程序?
文章首發于陳建源的博客,歡迎訪問,
文章作者:陳建源
文章鏈接: https://www.techstack.tech/post/lei-jia-zai-guo-cheng/
轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/77577.html
標籤:Java
