來源：tianchi 的博客
《深入理解JAVA虛擬機》筆記
在 C 語言裏面我們想執行一段自己編寫的機器指令的方法大概如下：
|
1
2
3
|
typedef
void (*FUNC)(int);
char* str =
"your code"; FUNC f = (FUNC)str; |
也就是說，我們完全可以做一個工具，從一個文件中讀入指令，然後將這些指令運行起來。上面代碼中“編好的機器指令”當然指的是能在CPU上運行的，如果這裏我還實現了一個翻譯機器：從自己定義的格式指令翻譯到CPU指令，那麼就可以執行根據自定義格式的代碼了。那麼上面這段代碼是不是相當於最簡單的一個虛擬機了？下面來看JVM的總體結構：
ClassLoader的作用是裝載能被JVM識別的指令（當然不只是從磁盤文件或內存去裝載），那麼我們先了解一下該格式：
魔數以及版本就不說了（滿大街的文件格式都是這個東西），接着的便是常量池，其中無非是兩種東西：
1. 字面常量（比如Integer、Long、String等）；
2. 符號引用（方法是哪裏的？什麼樣的？）；
而我們知道，在JVM裏面Class都是根據全限定名去找的，那麼方法的描述當然也應該如此，那麼就得到這些常量之間的關係如下：
在接下來的“訪問權限”中表明瞭該Class是public還是private等，而this&super&interface則表面了“本類”、“繼承自哪個類”、“實現了哪些接口”，實際上這裏只是保存了代表這些信息的CONSTANT_Class_info的下標（u2）。
感覺這裏的NameIndex和DescriptorIndex加起來和NameAndType有點像，那麼爲什麼不直接用一個NameAndType的索引值表示？MethodInfo和FieldInfo之間最大的不同點就是Attributes。比如FieldInfo的屬性表中存放的是變量的初始值，而MethodInfo的屬性表中存放的則是字節碼。那麼我們來依次看這些Attributes，首先是Code：
有幾個有意思的地方：
1. 從Class文件中可以知道在執行的過程中棧的深度；
2. 對於非靜態方法，編譯器會將this通過參數傳遞給方法；
3. 異常表中記錄的範圍是指令的行數（而不是源代碼的）；
4. 這裏的異常是指try-catch中的，而與Code同級的異常表中的則是指throws出去的；
Exceptions則非常簡單：
LineNumberTable保存了字節碼和源碼之間的關係，結構如下：
LocalVariableTable描述了棧幀中局部變量表的變量和源代碼中定義的變量之間的關係，結構如下：
SourceFile指明瞭生成該Class文件的Java源碼文件名（比如在一個Java文件中申明瞭很多類的時候會生成很多Class文件），結構如下：
Deprecated和Synthetic屬性只存在“有”和“沒有”的區別：
1. Deprecated：被程序作者定爲不再推薦使用，通過@deprecated註釋說明；
2. Synthetic：表示字段或方法是由編譯器自動生成的，比如<init>；
這也就是爲什麼Code屬性後面會有Attribute的原因？
類加載的時機就很簡單了：在用到的時候就加載（廢話！）。下來看一下類加載的過程：
執行上面這段過程的是：ClassLoader，這個東西還是非常重要的，在JVM中是通過ClassLoader和類本身共同去判斷兩個Class是否相同。換句話說就是：不同的ClassLoader加載同一個Class文件，那麼JVM認爲他們生成的類是不同的。有些時候不會從Class文件中加載流（比如Java Applet是從網絡中加載），那麼這個ClassLoader和普通的實現邏輯當然是不一樣的，通過不同的ClassLoader就可以解決這個問題。
但是允許使用不同的ClassLoader又引發了新的問題：如果我也聲明瞭一個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去加載類，並且這個被加載的類是不能被別人使用的。
雙親委派模式不是一個強制性的約束，而是Java設計者推薦給開發者的類加載實現方式。雙親委派模式出現過的3次“破壞”：
1. 爲了兼容JDK 1.0，建議使用者去覆蓋findClass方法；
2. 在基礎類要訪問用戶類的代碼會出現問題（比如JNDI）：線程山下文類加載器；
3. 用戶的一些需求，比如HotSwap、OSGI等；
加載完完成後，接下來就要看程序是怎麼運行的。棧幀是用於支持虛擬機進行方法調用和執行，幀的意思就是一個單位，在調用其他方法的時候會向棧中壓入棧幀，結構如下：
在Class文件編譯完成之後，在運行的時候需要多少個局部變量就已經確定（在前面Class文件中也已經看到過了），那麼這裏需要注意這個特性可能會引發GC（具體如何引發就不在這裏細說了）。在棧中，總是底層的棧去調用高層的棧（並且一定的相鄰的），那麼他們在參數傳遞（返回結果）的時往往是通過將其壓入操作數棧，有些虛擬機爲了提高這部分的效率使得相鄰棧幀“糾纏”在一起：
那麼我們接下來要去看是方法是如何執行的，第一個問題就是執行哪個方法？在“面向過程”的編程中似乎不存在在個問題，但是在Java OR C++中這都是比較蛋疼的一個問題。原因就是平時不會這麼用，但是你必須去搞明白= =。JVM確定目標方法的時候有兩種方法：
1. 靜態分派：根據參數類型和方法名稱來決定調用哪個方法。但是，並不是說沒有發現匹配的類型就報錯，比如有：func(int a)，而在調用func(‘a’)的時候也會調用該方法（當然是在沒有func(char a)的前提下），這樣給人的關鍵就有點像一個處理的鏈條。不管多麼複雜，這些都是在編譯期間確定的，因爲這裏是向上找的。
2. 動態分派：最普遍的就是Interface a = new Implements()，a調用方法到底應該是哪個類的在編譯期間是無法確定的。其實動態分派實現起來也很簡單：在調用方法的時候先拿到對象的實際類型。
其實“靜態”和“動態”給人的感覺還是比較模糊的，“靜態分派”給人的感覺是根據參數的類型向上查找方法，“動態分派”給人的感覺則是根據實例的真實類型向上查找。虛擬機優化動態分派的效率一般是爲類在方法區中建立一個虛方法表：
虛方法表中存放各個方法實際入口地址，如果某個方法在子類中沒有被重寫，那麼子類的虛方法表裏面的地址入口和父類相同方法的地址入口是一致的，都指向父類的實現入口。如果子類重寫了這個方法，子類方法表中的地址將會被替換爲指向子類實現版本的入口地址。其實往簡單裏說，就是一個預處理。