《深入理解Java虛擬機》筆記

在C里面我們想履行1段自己編寫的機器指令的方法大概以下：

　　也就是說，我們完全可以做1個工具，從1個文件中讀入指令，然后將這些指令運行起來。上面代碼中“編好的機器指令”固然指的是能在CPU上運行的，如果這里我還實現了1個翻譯機器：從自己定義的格式指令翻譯到CPU指令，那末就能夠履行根據自定義格式的代碼了。那末上面這段代碼是否是相當于最簡單的1個虛擬機了？下面來看JVM的整體結構：

ClassLoader的作用是裝載能被JVM辨認的指令（固然不只是從磁盤文件或內存去裝載），那末我們先了解1下該格式：

魔數和版本就不說了（滿大街的文件格式都是這個東西），接著的便是常量池，其中不過是兩種東西：

1. 字面常量（比如Integer、Long、String等）；
2. 符號援用（方法是哪里的？甚么樣的？）；

而我們知道，在JVM里面Class都是根據全限定名去找的，那末方法的描寫固然也應當如此，那末就得到這些常量之間的關系以下：

在接下來的“訪問權限”中表明了該Class是public還是private等，而this&super&interface則表面了“本類”、“繼承自哪一個類”、“實現了哪些接口”，實際上這里只是保存了代表這些信息的CONSTANT_Class_info的下標（u2）。

感覺這里的NameIndex和DescriptorIndex加起來和NameAndType有點像，那末為何不直接用1個NameAndType的索引值表示？MethodInfo和FieldInfo之間最大的不同點就是Attributes。比如FieldInfo的屬性表中寄存的是變量的初始值，而MethodInfo的屬性表中寄存的則是字節碼。那末我們來順次看這些Attributes，首先是Code：

有幾個成心思的地方：

1. 從Class文件中可以知道在履行的進程中棧的深度；
2. 對非靜態方法，編譯器會將this通過參數傳遞給方法；
3. 異常表中記錄的范圍是指令的行數（而不是源代碼的）；
4. 這里的異常是指try-catch中的，而與Code同級的異常表中的則是指throws出去的；

Exceptions則非常簡單：

LineNumberTable保存了字節碼和源碼之間的關系，結構以下：

LocalVariableTable描寫了棧幀中局部變量表的變量和源代碼中定義的變量之間的關系，結構以下：

SourceFile指明了生成該Class文件的Java源碼文件名（比如在1個Java文件中申明了很多類的時候會生成很多Class文件），結構以下：

Deprecated和Synthetic屬性只存在“有”和“沒有”的區分：

1. Deprecated：被程序作者定為不再推薦使用，通過@deprecated注釋說明；
2. Synthetic：表示字段或方法是由編譯器自動生成的，比如<init>； 

這也就是為何Code屬性后面會有Attribute的緣由？

類加載的時機就很簡單了：在用到的時候就加載（空話?。?。下來看1下類加載的進程：

履行上面這段進程的是：ClassLoader，這個東西還是非常重要的，在JVM中是通過ClassLoader和類本身共同去判斷兩個Class是不是相同。換句話說就是：不同的ClassLoader加載同1個Class文件，那末JVM認為他們生成的類是不同的。有些時候不會從Class文件中加載流（比如Java Applet是從網絡中加載），那末這個ClassLoader和普通的實現邏輯固然是不1樣的，通過不同的ClassLoader就能夠解決這個問題。

但是允許使用不同的ClassLoader又引發了新的問題：如果我也聲明了1個java.lang.Integer，但是里面的代碼非常危險，怎樣辦？這里就引出了雙親委派模式：

除頂層的啟動類加載器外，其余的類加載器都應當有父類加載器（通過組合實現），它在接到加載類的要求時優先委派給父類加載器去完成。

這樣的話，在加載java.lang.Integer的時候會優先使用系統的類加載器，這樣就不會加載用戶自己寫的。在Java程序員看到有3種系統提供的類加載器：

1. Bootstrap ClassLoader：負責加載<JAVA_HOME>\lib目錄中的類庫，沒法被Java程序直接援用；
2. Extension ClassLoader：負責加載<JAVA_HOME>\lib\ext，開發者可以直接使用；
3. Application ClassLoader：加載ClassPath上所指定的類庫，如果沒有自己定義過自己的類加載器則會使用它；

這樣默許的類會是有Application ClassLoader去加載類，然后如果發現要使用新的類型的時候則會遞歸地使用Application ClassLoader去加載（在前面的加載進程中提到）。這樣，只有在自己的程序中能使用自己編寫的ClassLoader去加載類，并且這個被加載的類是不能被他人使用的。

雙親委派模式不是1個強迫性的束縛，而是Java設計者推薦給開發者的類加載實現方式。雙親委派模式出現過的3次“破壞”：

1. 為了兼容JDK 1.0，建議使用者去覆蓋findClass方法；
2. 在基礎類要訪問用戶類的代碼會出現問題（比如JNDI）：線程山下文類加載器；
3. 用戶的1些需求，比如HotSwap、OSGI等； 

加載完完成后，接下來就要看程序是怎樣運行的。棧幀是用于支持虛擬機進行方法調用和履行，幀的意思就是1個單位，在調用其他方法的時候會向棧中壓入棧幀，結構以下：

在Class文件編譯完成以后，在運行的時候需要多少個局部變量就已肯定（在前面Class文件中也已看到過了），那末這里需要注意這個特性可能會引發GC（具體如何引發就不在這里細說了）。在棧中，總是底層的棧去調用高層的棧（并且1定的相鄰的），那末他們在參數傳遞（返回結果）的時常常是通過將其壓入操作數棧，有些虛擬機為了提高這部份的效力使得相鄰棧幀“糾纏”在1起：

那末我們接下來要去看是方法是如何履行的，第1個問題就是履行哪一個方法？在“面向進程”的編程中似乎不存在在個問題，但是在Java OR C++中這都是比較蛋疼的1個問題。緣由就是平時不會這么用，但是你必須去弄明白= =。JVM肯定目標方法的時候有兩種方法：

1. 靜態分派：根據參數類型和方法名稱來決定調用哪一個方法。但是，其實不是說沒有發現匹配的類型就報錯，比如有：func(int a)，而在調用func('a')的時候也會調用該方法（固然是在沒有func(char a)的條件下），這樣給人的關鍵就有點像1個處理的鏈條。不管多么復雜，這些都是在編譯期間肯定的，由于這里是向上找的。
2. 動態分派：最普遍的就是Interface a = new Implements()，a調用方法到底應當是哪一個類的在編譯期間是沒法肯定的。其實動態分派實現起來也很簡單：在調用方法的時候先拿到對象的實際類型。

其實“靜態”和“動態”給人的感覺還是比較模糊的，“靜態分派”給人的感覺是根據參數的類型向上查找方法，“動態分派”給人的感覺則是根據實例的真實類型向上查找。虛擬機優化動態分派的效力1般是為類在方法區中建立1個虛方法表：

虛方法表中寄存各個方法實際入口地址，如果某個方法在子類中沒有被重寫，那末子類的虛方法表里面的地址入口和父類相同方法的地址入口是1致的，都指向父類的實現入口。如果子類重寫了這個方法，子類方法表中的地址將會被替換為指向子類實現版本的入口地址。其實往簡單里說，就是1個預處理。

具體單個方法的履行非常簡單，寫1個簡單的程序然后使用javap -c，再結合每條指令的含義就可以大概知道程序時怎樣履行和返回的了（大體上就是基于棧），這里就不深入和細說了。

1般情況下，從Java文件到運行起來，總的會經歷兩個階段：Java到Class文件和履行Class文件。第1個階段其實就是編譯了，在這個進程中比較成心思的是“語法糖”（其他的比如詞法分析和語法分析就不說了，此處省略1萬字~!~）。所謂Java的語法糖是：for遍歷的簡寫、自動裝箱、泛型等（其實有無感覺String+String也是語法糖，在實際中會變成StringBuffer的append）。其中比較成心思的是泛型：

Java中的泛型和C++中的泛型原理是上不1樣的：對C++來講List<A>和List<B>就是兩個東西，而在Java中List<A>和List<B>都是List<Object>，由于在Java中Object是所有對象的父對象，那末Object o可以指向所有的對象，那末就能夠用List<Object>來保存所有的對象集了（感覺實現的有點廢）。

這里觸及到1個問題就是對象刪除，比以下面代碼：

static void func(List<Integer> a){
        return;
}

在使用javap查看生成的Class的時候會發現：

static void func(java.util.List);
  Signature: (Ljava/util/List;)V
  Code:
   0:   return

其中根本沒有任何Integer的痕跡，但是如果加上返回值，也就是：

static Integer func(List<Integer> a){
        return null;
}

此時再查看的時候就會變成：
static java.lang.Integer func(java.util.List);
  Signature: (Ljava/util/List;)Ljava/lang/Integer;
  Code:
   0:   aconst_null
   1:   areturn
通過泛型實現的原理可以理解很多在實際中會遇到的問題，比如使用List的時候稀里糊涂的類型強迫轉換毛病。

接下來開始討論第2個部份，也就是Class文件的實際的履行。在C++中常會提到的兩個概念是：Debug和Release，而在Java中常提到的兩個概念是Server和Client（雖然他們劃分的根據完全不1樣），Client和Server兩種模式對應兩種編譯器：

1. Client對應C1編譯：將字節碼編譯本錢地代碼并進行耗時短且可靠的優化，在必要的時候加入性能監控。
2. Server對應C2編譯：將字節碼編譯本錢地代碼并進行耗時比較長的優化，還可能會根據性能監控的結果進行1些不可靠激進的優化。

在監測器發現有熱門代碼（被調用了很屢次的方法或是履行很屢次的循環體）的情況下，將會想即時編譯器提交1個該該方法的代碼編譯要求。當這個方法再次被調用時，會先檢查改方法是不是存在被JIT編譯過的版本，如果存在則優先使用編譯后的本地代碼。在默許的情況下，編譯本地代碼的進程和舊的代碼（也就是解釋履行字節碼）是并行的，可使用-XX：-BackgroundCompilation來制止后臺編譯，也就是說履行線程會登島編譯完成后再去履行生成的本地代碼。

在具體編譯優化的時候有1個比較好玩的東西，逃逸分析（所謂逃逸是指能被從方法外援用），對不會逃逸的對象可以進行優化：

1. 在棧上分配對象，可以減少GC的壓力；
2. 不需要對為逃逸的對象進行線程同步；
3. 如果1個對象沒法逃逸，可以在方法里面不申明這個對象，而是放1些“零件”；

關于Java和C++效力的問題，感覺討論起來就沒有甚么意義了：語言到最后肯定是要生成機器指令的，在語言的機制上面各有千秋，致使不同的語言之間生成機器指令的進程可能不同，但是這個生成的進程跟我們這些碼農沒有半毛錢關系（更準確的說我們生成的進程我們毛都不知道），所以在弄清楚之前就不要爭到底哪一個效力高（乃至是哪一個更好）。 

程序的并發主要是斟酌不同的線程操作同1塊內存時候可能產生的1些問題（至于文件鎖之類的東西，咳咳），首先就先了解線程和內存的關系：

這里的主內存就像是內存條，工作內存就像是寄存器+Cache。Java內存模型定義了8中操作，他們的履行以下：

Java虛擬機中最輕量級的同步機制：volatile，它的性質以下：

1. 變量產生修改的時候會立刻被其他線程看到；
2. 制止指令重排序優化；

從Java內存模型操作的角度來看volatile的實現還是挺簡單的：在use之前必須load，在assign以后必須store，這樣就保證了每次用都是從主內存中讀取，每次賦值以后都會同步到主內存（貌似說的是空話）。線程的同步主要是從3個方面斟酌：

1. 原子性：Long和Double需要特殊斟酌；
2. 可見性；除volatile以外還有final（synchronized就不說了吧）；
3. 有序性：指令重排，固然可以制止指令重排；

如果任什么時候候都斟酌同步那代碼寫起來就累死了。下面是Java內存模型的天然先行產生關系：

1. 控制流被履行的順序和代碼的順序保持1致；
2. unlock先行產生于后面對同1個鎖的lock操作；
3. 對volatile變量的寫操作先行于后面對這個變量的讀操作；
4. Thread的start方法先行于線程的任何1個動作；
5. 線程的所有動作都先行于線程的終止檢測；
6. 對線程interrupt方法的調用先行于被中斷線程的代碼檢測到的中斷事件的產生；
7. 對象的初始化完成先行于finalize方法調用；
8. 傳遞性；

其實上面的這8條規則還是很成心思的，如果其中的某1條不成立會產生甚么？說到底Java線程還是用戶級的線程，那末它究竟是個甚么東西（在學C的時候也糾結過這個問題- -）。實現線程主要有幾種方式：

1. 使用1個內核線程（輕量級進程）來代理；
2. 完全在用戶態實現，內核都感覺不到；
3. 用戶和內核混合實現，各自做自己善于的事情；

這里就不深入的去看了（雖然這里的介紹根沒說1樣），想一想看都知道不同虛擬機在不同的操作系統上面的實現方式極可能是不1樣，如果想深入看還是pthread比較成心思1點。關于線程的其他要注意的地方（比如狀態轉移甚么的）就不在這里討論了。

線程安全：當多個線程訪問1個對象時，如果不用斟酌這些線程在運行時環境下的調度和交替履行，也不需要進行額外的同步，或在調用方進行任何其他的調和操作，調用這個對象的行動都可以取得正確的結果，那這個對象是線程安全的。

Java中線程同享的變量可以分為以下5種：

1. 不可變：這個就不需要解釋了（其實不1定非得用final修飾）；
2. 絕對線程安全：也就是滿足上面的線程安全描寫的；
3. 相對線程安全：簡單的說應當是對單個行動的調用不會出錯；
4. 線程兼容：對象其實不是線程安全，但可以通過調用方的同步來彌補；
5. 線程對峙：不管調用方怎樣處理都不能在多線程環境下使用；

鎖的話有以下幾種實現方式：

1. 互斥同步，其實不是說等待的線程會1直等下去；
2. 非阻塞同步，樂觀（沖突并沒有我們想象的那末多）；

如果線程之間的切換非常頻繁的話自旋鎖是1個不錯的選擇，這樣就不需要線程切換時候的系統調用的開消了。如果1個任務能夠很快的完成的話，將全部進程都鎖住也許是個不錯的選擇（而不是給每一個子進程上鎖）。其他的鎖優化包括“輕量級鎖”和“偏心鎖”。

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈