系列文章目錄

第一章： 走近Java
第二章： Java內存區域與內存溢出異常
第三章： Java垃圾收集器與內存分配策略

---

代碼編譯的結果從本地機器碼轉變為字節碼，是存儲格式發展的一小步，卻是編程語言發展的一大步

• 系列文章目錄
• 一、概述
• 二、運行時棧幀結構
• • 1、局部變量表
  • 2、操作數棧
  • 3、動態連接
  • 4、方法返回地址
  • 5、附加信息
• 三、方法調用
• • 1、解析
  • 2、分派
  • • 2.1 靜態分派
    • 2.2 動態分派
    • 2.3 單分派與多分派
    • 2.4 虛擬機動態分派的實現
• 四、動態類型語言支持
• 五、基于棧的字節碼解釋執行引擎
• 六、附錄

一、概述

執行引擎是Java虛擬機核心的組成部分之一

虛擬機是相對于物理機的概念。兩種機器都有代碼執行能力，區別在于物理機的執行引擎是建立在處理器、緩存、指令集和操作系統層面上的，而虛擬機的執行引擎是由軟件自行實現的，可以不受物理條件制約地定制指令集與執行引擎的的結構體系，能夠執行那些不被硬件直接支持的指令集格式

????????《Java虛擬機規范》中制定了Java虛擬機字節碼執行引擎的概念模型，成為各大發行商的Java虛擬機執行引擎的統一外觀。在不同的虛擬機實現中，執行引擎在執行字節碼的時候，通常會有解釋執行（解釋器執行）和編譯執行（通過即時編譯器生成本地代碼執行）兩種選擇，也可能兩者兼備，還可能同時包含幾個不同級別的即時編譯器一起工作的執行引擎。但從外觀看，所有的Java虛擬機的執行引擎輸入、輸出是一致的：輸入的是字節碼二進制流，處理過程是字節碼解析執行的等效過程，輸出的是執行結果

---

二、運行時棧幀結構

????????Java虛擬機以方法作為最基本的執行單元，棧幀則是用于支持虛擬機進行方法調用和方法執行背后的數據結構，也是虛擬機運行時數據區中的虛擬機棧（Virtual Machine Stack）的棧元素。棧幀存儲了方法的局部變量表、操作數棧、動態連接和方法返回地址等信息，這些在Class文件格式的方法表中都能找到大多數的靜態對照物，每一個方法從調用到執行結束的過程都對應著要給棧幀從從入棧到出棧的過程。
????????編譯Java程序源碼時，棧幀中需要多大的局部變量表，多深的操作數棧就已經被計算出來了寫入到方法表的Code屬性中，即一個棧幀需要分配多少內存，并不會受到程序運行期數據的影響，僅僅取決于程序源碼和具體的虛擬機實現的內存布局形式。

以Java程序的角度，同一個時刻、同一個線程里，在調用堆棧的所有方法都同時處于執行狀態； 以執行引擎的角度，在活動線程中，只有位于棧頂的方法是運行的，只有位于棧頂的棧幀是生效的，稱為當前棧幀，與之關聯的方法稱為當前方法 執行引擎所運行的所有字節碼指令都只針對當前棧幀進行操作

1、局部變量表

局部變量表是一組變量值的存儲空間，以變量槽為最小單位，用于存放方法參數和方法內部定義的局部變量（編譯為class文件時Code屬性的max_locals數據項中確定了該方法所需分配的最大局部變量表的最大容量）。

《Java虛擬機規范》中并沒有明確指出一個變量槽所占用的內存空間大小，只是很有導向性地說到每個變量槽都應該能存放一個boolean、byte、char、short、int、float、reference、returnAddress類型的數據，這8種數據類型都可以使用32位或更小的物理內存存儲，它允許變量槽的長度可以隨著處理器、操作系統或虛擬機實現的不同而發生變化，保證了即使在64位虛擬機中使用64位的物理內存去實現一個變量槽，虛擬機仍要使用對齊和補白的方式讓變量槽在外觀上與32位虛擬機保持一致

一個變量槽可以存放一個32位以內的數據類型，Java中占用不超過32位存儲空間的數據類型有boolean、byte、char、short、int、float、reference、returnAddress這8種

reference類型表示對一個對象實例的引用，《Java虛擬機規范》既沒有說明它的長度，也沒有明確指出這種引用的結構，但一般來說，虛擬機實現至少都應當能通過這個引用做到兩件事，一是根據引用直接或間接找到對象在Java堆中數據存放的起始地址或索引，二是根據引用直接或間接查找到對象所屬數據類型在方法區中存儲的類型信息
??
returnAddress類型目前很少見了，它是為字節碼指令jsr、jsr_w和ret服務的，指向一條字節碼指令的地址，某些古老的Java虛擬機曾經使用這幾條指令來實現異常處理時的跳轉，但現在也已經全部改為采用異常表代替了

對于64位的數據類型，Java虛擬機采用高位對齊的方式為其分配兩個連續的變量槽空間，Java中明確規定的64位的數據類型只有long和double兩種，，這里把long和double數據類型分割存儲的做法與“long和double的非原子性協定中允許把一次long和double數據類型讀寫分割為兩次32位讀寫的做法有些類似”，不過由于局部變量表是建立在線程堆棧中，屬于線程私有的數據，無論讀寫兩個連續的變量槽是否為原子操作，都不會引起數據競爭和線程安全問題。

Java虛擬機通過索引定位的方式使用局部變量表，索引值的范圍是從0開始至局部變量表最大的變量槽數據。如果訪問的是32位的變量，索引N就代表使用第N個變量槽，如果訪問的是64位，則說明會同時使用第N和第N+1兩個變量槽。當一個方法被調用時，Java虛擬機采用局部變量表來完成參數值到參數變量列表的傳遞過程，即形參到實參的傳遞，如果執行實例方法（沒有被static修飾）的，局部變量槽表中第0位索引的變量槽默認是用于傳遞方法所屬對象實例的引用，在方法中可以通過關鍵字“this”來訪問到這個隱含的參數，其余參數按照參數表順序排列，占用從1開始的局部變量槽，參數表分配完畢后再根據方法內部定義的變量順序和作用域分配其余的變量槽。
??
為了盡可能節省棧幀耗用的內存空間，局部變量表中的變量槽是可以重用的（方法體中定義的變量，其作用域不一定會覆蓋整個方法，如果當前字節碼PC計數器的值已經超出了某個變量的作用域，那這個變量對應的變量槽就可以交給其他變量來重用，但這樣的設計除了節省棧幀空間以外，在某些特殊情況下變量槽的重用會直接影響到系統的垃圾收集行為）

2、操作數棧

操作數棧稱為操作棧，它是一個先入后出棧，操作數棧的最大深度在編譯時就寫入到Code屬性的max_stacks數據項中，操作數棧的每一個元素都可以是包含long和double在內的任意Java數據類型，32位數據類型所占的棧容量為1，64位數據類型所占的棧容量為2，Javac編譯器的數據流分析工作保證了在方法執行的任何時候，操作數棧的最大深度都不會超過max_stacks中設定的最大值。

當一個方法開始執行時，這個方法的操作數棧是空的，在方法的執行過程中，會有各種字節碼指令往操作數棧中寫入和提取內容，即入棧和出棧操作，譬如在做算術運算時將運算涉及的操作數壓入棧頂后調用運算指令來進行，或在調用其他方法時通過操作數棧來進行方法參數的傳遞，舉個栗子，整數加法字節碼指令iadd運行時要求將操作數棧中最接近棧頂的兩個元素存入int型的數值，當執行指令時，會把這兩個int出棧并相加，然后將相加的結果重新入棧

在概念模型中，兩個不同棧幀作為不同方法的虛擬機棧的元素，是完全相互獨立的，但在大多數虛擬機實現中會進行一些優化處理，令兩個棧幀出現一部分重疊，即下面棧幀的部分操作數棧與上面棧幀的部分局部變量表重疊在一起，不僅可以節約空間，更重要的是在方法調用時可以直接公用一部分數據，無需進行額外的參數復制傳遞。

3、動態連接

每一個棧幀都包含一個指向運行時常量池中該棧幀所屬方法的引用，持有這個引用是為了支持方法調用過程中的動態連接（Class文件的常量池中存有大量的符號引用，字節碼中的方法調用指令就以常量池里指向方法的符號引用作為參數，這些符號引用一部分在類加載階段或第一次使用時被轉換為直接引用，這種轉換稱為靜態解析，另外一部分在每一次運行期間轉換為直接引用，這部分稱為動態連接）。

4、方法返回地址

當一個方法開始執行后，只有兩種方式退出這個方法：

• 第一種方式是執行引擎遇到任意一個方法返回的字節碼指令，可能會有方法返回值傳遞給上層的方法調用者，方法是否有返回值及返回值的類型將根據遇到何種方法返回指令決定，這種退出方法的方式稱為“正常調用完成”
• 第二種方式是在方法執行過程遇到異常，且這個異常在方法內部沒有妥善處理，無論是虛擬機內部產生的異常還是使用athrow字節碼指令產生的異常，只要在本方法的異常表中沒有搜索到匹配的異常處理器，就會導致方法退出，這種退出方法的方式稱為“異常調用完成”，一個方法使用異常完成出口的方式退出，是不會給它的上層調用者提供任何返回值的

無論采用哪種方式退出，在方法退出之后，都必須返回到最初方法被調用的位置程序才能繼續執行，方法返回時可能需要在棧幀中保存一些信息，用來幫助恢復它的上層主調方法的執行狀態，一般來說，方法正常退出時，主調方法的PC計數器的值就作為返回地址，棧幀中很可能會存儲這個計數器值，而當方法異常退出時，返回地址是要通過異常處理器表來確定的，棧幀中一般就不會保存這部分信息
??
方法退出的過程等同于把當前棧幀出棧，因此退出可能執行的操作有：恢復上層方法的局部變量表和操作數棧，把返回值壓入調用者棧幀的操作數棧中，調整PC計數器的值指向方法調用指令后面的下一條指令。（“可能”是由于這是基于概念模型的討論，具體操作需要具體的某一款Java虛擬機）

5、附加信息

《Java虛擬機規范》允許虛擬機實現增加一些規范中沒有描述的信息到棧幀中，例如與調試、性能收集相關的信息，這部分信息取決于具體的虛擬機實現。

---

三、方法調用

方法調用并不等同于方法執行，唯一的任務是確定被調用方法的版本（即調用哪個方法），暫時還未涉及到方法內部的具體運行過程

1、解析

所有方法調用的目標方法在Class文件里面都是一個常量池中的符號引用，在類加載解析階段，會將其中的一部分符號引用轉換為直接引用，這種解析成立的前提是：方法在程序真正執行之前就有一個可確定的調用版本，并且這個方法的調用版本在運行期是不可改變的，即調用目標在程序代碼寫好、編譯器進行編譯那一刻就已經確定了，這類方法的調用稱為“解析”
??
Java語言中符合“編譯期可知，運行期不可變”要求的方法，主要有靜態方法和私有方法，前者與類型相關，后者在外部不可訪問，這兩種方法各自的特點決定了它們不可能通過繼承或別的方式重寫出其他的版本，因此它們都適合在類加載階段進行解析
??
Java虛擬機支持以下5條方法調用的字節碼指令：

• invokestatic 用于調用靜態方法
• invokespecial 用于調用實例構造器方法、私有方法和父類中的方法
• invokevirtual 用于調用所有虛方法
• invokeinterface 用于調用接口方法，會在運行時再確定一個實現該接口的對象
• invokedynamic 先在運行時動態解析出調用點限定符所引用的方法，然后再執行該方法（前4條調用指令是固化在Java虛擬機內部，而invokedynamic指令的分配邏輯是由用戶的引導方法決定的）

只要能被invokestatic和invokespecial指令調用的方法，都可以在解析階段中確定唯一的調用版本，Java語言中符合這個條件的共有靜態方法、私有方法、實例構造器、父類方法及被final修飾的實例方法，這5種方法調用時會在類加載時將符號引用解析為該方法的直接引用，這些方法統稱為“非虛方法”，其他方法稱為“虛方法”。

盡管final使用invokevirtual指令調用，但這是歷史設計原因，它無法被覆蓋，沒有其他版本的可能，即無需對方法接收者進行多態選擇，多態選擇的結構是唯一的，《Java語言規范》中明確定義了final修飾的方法是一種非虛方法

示例： package com.tencent;/*** 方法靜態解析演示** @author zzm*/public class Demo {public static void sayHello() {System.out.println("hello world");}public static void main(String[] args) {Demo.sayHello();} }// class version 52.0 (52) // access flags 0x21 public class com/tencent/Demo {// compiled from: Demo.java// access flags 0x1public <init>()VL0LINENUMBER 9 L0ALOAD 0INVOKESPECIAL java/lang/Object.<init> ()VRETURNL1LOCALVARIABLE this Lcom/tencent/Demo; L0 L1 0MAXSTACK = 1MAXLOCALS = 1// access flags 0x9public static sayHello()VL0LINENUMBER 13 L0GETSTATIC java/lang/System.out : Ljava/io/PrintStream;LDC "hello world"INVOKEVIRTUAL java/io/PrintStream.println (Ljava/lang/String;)VL1LINENUMBER 14 L1RETURNMAXSTACK = 2MAXLOCALS = 0// access flags 0x9public static main([Ljava/lang/String;)VL0LINENUMBER 17 L0INVOKESTATIC com/tencent/Demo.sayHello ()VL1LINENUMBER 18 L1RETURNL2LOCALVARIABLE args [Ljava/lang/String; L0 L2 0MAXSTACK = 0MAXLOCALS = 1 }查看生成字節碼，發現是通過invokestatic調用sayHello方法，且調用的方法版本已經在編譯時以常量池項形式固化到字節碼指令參數中（代碼中的31號常量池項）

2、分派

解析調用一定是個靜態的過程，在編譯器就完全確定，在類加載的解析階段就會把涉及的符號引用全部轉換為明確的直接引用，不必延遲到運行期再去完成，而另一種主要的方法調用形式：分派則要復雜許多，可能是靜態也可能是動態的。

2.1 靜態分派

靜態分派與重載的關系

package com.tencent;/*** 方法靜態分派演示** @author lbz*/ public class Demo {static abstract class Human {}static class Man extends Human {}static class Woman extends Human {}public void sayHello(Human guy) {System.out.println("hello,guy!");}public void sayHello(Man guy) {System.out.println("hello,gentleman!");}public void sayHello(Woman guy) {System.out.println("hello,lady!");}public static void main(String[] args) {Human man = new Man();Human woman = new Woman();Demo sr = new Demo();sr.sayHello(man);sr.sayHello(woman);} }運行結果 hello,guy! hello,guy!

Human man = new Man();
Human稱為變量的靜態類型或外觀類型，Man稱為變量的實際類型或運行時類型。
靜態類型和實際類型在程序中都可能會發生變化，區別是靜態類型的變化僅僅在使用時發生，變量本身的靜態類型不會被改變，并且最終的靜態類型在編譯器是可知的，而實際類型變化的結果在運行期才確定，編譯器在編譯程序時并不知道一個對象的實際類型是什么。
??
實際類型變化：
Human human = (new Random()).nextBoolean() ? new Man() : new Woman();
??
靜態類型變化：
sr.sayHello((Man) human) sr.sayHello((Woman) human)

為什么虛擬機會選擇執行參數類型為Human的重載版本？
答：main()方法里面的兩次sayHelloe()方法調用，確定方法接收者是對象sr的前提下，使用哪個重載版本取決于傳入參數的數量和類型，虛擬機（準確地說是編譯器）在重載時是通過參數的靜態類型作為判定依據的，由于靜態類型在編譯期可知，Javac編譯器就根據參數的靜態類型決定了會使用哪個重載版本，因此選擇sayHello(Human)作為調用方法，并把這個方法的符號引用寫入到main方法的兩條invokevirtual指令的參數中。

所有依賴靜態類型來決定方法執行版本的分派動作都稱為靜態分派。靜態分派最典型的應用表現就是方法重載。

注意：Javac編譯器雖然能確定出方法的重載版本，但很多情況下并不是唯一的，往往只能確定一個“相對更合適”的版本

/*** 重載方法匹配優先級** @author lbz*/ public class Demo {public static void sayHello(Object arg) {System.out.println("hello Object");}public static void sayHello(int arg) {System.out.println("hello int");}public static void sayHello(long arg) {System.out.println("hello long");}public static void sayHello(Character arg) {System.out.println("hello Character");}public static void sayHello(char arg) {System.out.println("hello char");}public static void sayHello(char... arg) {System.out.println("hello char ...");}public static void sayHello(Serializable arg) {System.out.println("hello Serializable");}public static void main(String[] args) {sayHello('a');} }輸出結果 hello char注釋掉sayHello(char arg)方法 hello int注釋掉sayHello(int arg)方法 hello long注釋掉sayHello(long arg)方法 hello Character注釋掉sayHello(Character arg)方法 hello Serializable注釋掉sayHello(Serializable arg)方法 hello Object注釋掉sayHello(Object arg)方法 hello char ...

解析與分派兩者之前的關系并不是二選一的排他關系，它們是在不同層次上去篩選、確定目標方法的過程，例如靜態方法會在編譯期間確定、在類加載期間進行解析，而靜態方法顯然也是可以擁有重載版本的，選擇重載版本的過程也是通過靜態分派完成的

2.2 動態分派

/*** 方法動態分派演示** @author zzm*/ public class Demo {static abstract class Human {protected abstract void sayHello();}static class Man extends Human {@Overrideprotected void sayHello() {System.out.println("man say hello");}}static class Woman extends Human {@Overrideprotected void sayHello() {System.out.println("woman say hello");}}public static void main(String[] args) {Human man = new Man();Human woman = new Woman();man.sayHello();woman.sayHello();man = new Woman();man.sayHello();} }字節碼： public static void main(java.lang.String[]); Code: Stack=2, Locals=3, Args_size=1 0: new #16; //class org/fenixsoft/polymorphic/DynamicDispatch$Man 3: dup 4: invokespecial #18; //Method org/fenixsoft/polymorphic/Dynamic Dispatch$Man."<init>":()V 7: astore_1 8: new #19; //class org/fenixsoft/polymorphic/DynamicDispatch$Woman 11: dup 12: invokespecial #21; //Method org/fenixsoft/polymorphic/DynamicDispatch$Woman."<init>":()V 15: astore_2 16: aload_1 17: invokevirtual #22; //Method org/fenixsoft/polymorphic/Dynamic Dispatch$Human.sayHello:()V 20: aload_2 21: invokevirtual #22; //Method org/fenixsoft/polymorphic/Dynamic Dispatch$Human.sayHello:()V 24: new #19; //class org/fenixsoft/polymorphic/DynamicDispatch$Woman 27: dup 28: invokespecial #21; //Method org/fenixsoft/polymorphic/DynamicDispatch$Woman."<init>":()V 31: astore_1 32: aload_1 33: invokevirtual #22; //Method org/fenixsoft/polymorphic/Dynamic Dispatch$Human.sayHello:()V 36: return運行結果 man say hello woman say hello woman say hello

Java虛擬機是如何判斷應該調用哪個方法的？
這里選擇調用的方法版本是不可能根據靜態類型來決定的，因為靜態類型同樣是Human的兩個變量man和woman在調用方法時產生了不同行為，查看字節碼指令，兩次方法調用都是invokevirtual指令且參數都是常量池中第22項的常量，所以問題的關鍵是invokevirtual指令本身。

根據《Java虛擬機規范》，invokevirtual指令的運行時解析過程大致分為以下幾步

找到操作數棧棧頂的第一個元素所指向的對象的實際類型，記作C

如果在類型C中找到與常量池中的描述符和簡單名稱都相符的方法，則進行訪問權限校驗，如果通過則返回這個方法的直接引用，查找過程結束；不通過則返回java.lang.IllegalAccessError異常

否則按照繼承關系從下往上依次對C的各個父類進行第二步的搜索和驗證過程

如果始終沒有找到合適的方法，則拋出java.lang.AbstractMethodError異常

???????? 正是因為invokevirtual指令執行的第一步就是在運行期確定接收者的實際類型，所以兩次調用中的invokevirtual指令并不是把常量池中方法的符號引用解析到直接引用上就結束了，還會根據方法接收者的實際類型來選擇方法版本，這個過程就是Java語言中方法重寫的本質。我們把這種在運行期根據實際類型確定方法執行版本的分派過程稱為動態分派。

在Java里面只有虛方法存在， 字段永遠不可能是虛的，換句話說，字段永遠不參與多態，哪個類的方法訪問某個名字的字段時，該名字指的就是這個類能看到的那個字段。當子類聲明了與父類同名的字段時，雖然在子類的內存中兩個字段都會存在，但是子類的字段會遮蔽父類的同名字段

/*** 字段不參與多態** @author zzm*/ public class Demo {static class Father {public int money = 1;public Father() {money = 2;showMeTheMoney();}public void showMeTheMoney() {System.out.println("I am Father, i have $" + money);}}static class Son extends Father {public int money = 3;public Son() {money = 4;showMeTheMoney();}@Overridepublic void showMeTheMoney() {System.out.println("I am Son, i have $" + money);}}public static void main(String[] args) {Father gay = new Son();System.out.println("This gay has $" + gay.money);} }輸出結果 I am Son, i have $0 I am Son, i have $4 This gay has $2

2.3 單分派與多分派

方法的接收者和參數統稱為方法的宗量，根據分派基于多少種宗量，可以將分派劃分為單分派和多分派兩種。單分派是根據一個宗量對目標方法進行選擇，多分派是根據多于一個宗量對目標方法進行選擇。

/*** 單分派、多分派演示** @author zzm*/ public class Demo {static class QQ {}static class _360 {}public static class Father {public void hardChoice(QQ arg) {System.out.println("father choose qq");}public void hardChoice(_360 arg) {System.out.println("father choose 360");}}public static class Son extends Father {@Overridepublic void hardChoice(QQ arg) {System.out.println("son choose qq");}@Overridepublic void hardChoice(_360 arg) {System.out.println("son choose 360");}}public static void main(String[] args) {Father father = new Father();Father son = new Son();father.hardChoice(new _360());son.hardChoice(new QQ());} }運行結果： father choose 360 son choose qq

編譯階段編譯器的選擇過程（靜態分派）：一是靜態類型是Father還是Son，二是方法參數是QQ還是360，所以最終分別產生兩條invokevirtual指令，兩條指令的參數分別為常量池中指向Father:hardChoice(360)及Father:hardChoice(QQ)方法的符號引用，因為是根據兩個宗量進行選擇，所以Java語言的靜態分派屬于多分派類型

運行期虛擬機的選擇過程（動態分派）：在執行son.hardChoice(new QQ())所對應的字節碼invokevirtual指令時，由于編譯期已經決定目標方法的簽名必須為hardChoice(QQ)，虛擬機此時不會關心傳遞過來的參數“QQ”到底是“騰訊QQ”還是“奇瑞QQ”，因為這時候參數的靜態類型、實際類型都對方法的選擇不會構成任何影響，唯一可以影響虛擬機選擇的因素只有該方法的接受者的實際類型是Father還是Son。因為只有一個宗量作為選擇依據， 所以Java語言的動態分派屬于單分派類型。

2.4 虛擬機動態分派的實現

前面介紹的分派過程，作為對Java虛擬機概念模型的解釋基本上已經足夠了，它已經解決了虛擬機在分派中“會做什么”這個問題。但如果問Java虛擬機“具體如何做到”的，答案則可能因各種虛擬機的實現不同會有些差別。
??
動態分派是執行非常頻繁的動作，而且動態分派的方法選擇版本過程需要運行時在接收者類型的方法元數據中搜索合適的目標方法，Java虛擬機實現基于執行性能的考慮，一種基礎而常見的優化手段是為類型在方法區中建立一個虛方法表（vtable，對應的在執行invokeinterface時會用到接口方法表-itable），使用虛方法表索引代替元數據查找以提升性能。

虛方法表中存放著各個方法的實際入口地址，如果某個方法在子類中沒有被重寫，那子類的虛方法表中的入口地址和父類相同方法的地址入口是一致的，都指向父類的實現入口。如果子類重寫了這個方法，子類虛方法表中的地址也會被替換為指向子類實現版本的入口地址。

為了實現程序方便，具有相同簽名的方法，在父類、子類的虛方法表中都應當具有一樣的索引序號，這樣設計當類型變換時，僅需要查找變更的虛方法表，就可以從不同的虛方法表中按索引轉換出所需入口地址。虛方法表一般在類加載的連接階段進行初始化，準備了類的變量初始化值后，虛擬機會把該類的虛方法表也一同初始化完畢。
??
虛擬機除了使用虛方法表之外，為了進一步提高性能，還會使用類型繼承關系分析、守護內聯、內聯緩存等方式
??
提高性能是相對于直接搜索元數據來說，實際在Hotspot虛擬機實現中，直接去查vtable和itable已經算是最慢的一種分派，只在解釋執行狀態時使用，在即時編譯執行時，會有更多的性能優化措施。

---

四、動態類型語言支持

動態類型語言的關鍵特征是它的類型檢查的主體過程是在運行期而不是編譯期進行的，常見的動態語言包括：Python、Erlang、JavaScript、PHP、Ruby等，相對地，在編譯期就進行類型檢查過程的靜態類型語言有C++、Java等。

什么是類型檢查？

obj.println("hello world");

????假設這行代碼是在Java語言中，并且obj的靜態變量類型為java.io.PrintStream，那變量obj的實際類型就必須是PrintStream的子類才是合法的，否則哪怕obj屬于一個確實含有println(String)方法相同簽名方法的類型，但只要與PrintStream沒有繼承關系，代碼依然不可能執行-類型檢查不合法。但是相同的代碼在JavaScript中，無論obj是何種類型，無論其繼承關系如何，只要這種類型的方法中確實定義有println(String)方法，能夠找到相同簽名的方法，調用便可成功。

為什么會產生這種差別？
產生這種差別的根據原因是Java語言在編譯期就將pringln(String)方法完整的符號引用生成出來，并作為方法調用指令的參數存儲到Class文件中。例 invokevirtual #4; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
??
這個符號引用包含了這個方法定義在哪個具體類型中、方法的名字、參數順序、參數類型、方法返回值等信息，通過這個符號引用，Java虛擬機就可以翻譯出該方法的直接引用，而JavaScript等動態類型語言與Java核心的差異就是變量obj本身沒有類型，變量obj的值才有類型，所以編譯器在編譯時最多只能確定方法名稱、方法參數、返回值這些信息，而不會去確定方法所在具體類型（方法接收者不固定）?！白兞繜o類型而變量值才有類型”這個特點也是動態類型語言的一個核心特征

動態類型語言和靜態類型語言兩者誰更好？
它們都有各自的優點，選擇哪種語言是需要權衡的事情。靜態語言在編譯期確定變量類型，最顯著的好處就是編譯器可以提供全面嚴謹的類型檢查，這樣與數據類型相關的潛在問題也會在編碼時被及時發現，利于穩定性。而動態類型語言在運行期確定類型可以為開發人員提供極大的靈活性，某些靜態語言要花大量臃腫的代碼實現的功能，由動態類型語言實現會清晰簡潔，即開發效率的提升。

Java與動態類型的關系？
Java虛擬機層面對動態類型語言的支持有所欠缺主要表現在方法調用方面：Jdk7之前的4條字節碼方法調用指令中，第一個參數都是被調用的方法的符號引用（CONSTANT_Methodref_info或者CONSTANT_InterfaceMethodref_info常量），在編譯時產生，而動態類型語言只有在運行期才能確定方法的接收者。因此在Java虛擬機上實現的動態類型語言就不得不使用曲線救國的方式（如編譯時預留個占位符類型，運行時動態生成字節碼實現具體類型到占位符類型的適配）實現，但這種做法會導致動態類型語言實現的復雜度增加，也會帶來額外的性能和內存開銷。所以這種動態類型方法調用的底層問題應當在虛擬機層次上解決，這便是JDK 7 時JSR-292提案中invokedynamic指令以及java.lang.invoke包出現的技術背景。

java.lang.invoke包是什么？
Jdk7加入的invoke包主要目的是在之前單純依靠符號引用來確定調用的目標方法之外，提供一種新的動態確定目標方法的機制，稱為“方法句柄”。

package com.tencent;import java.lang.invoke.MethodHandle; import java.lang.invoke.MethodType;import static java.lang.invoke.MethodHandles.lookup;/*** 單分派、多分派演示** @author zzm*/ public class Demo {static class ClassA {public void println(String s) {System.out.println(s);}}public static void main(String[] args) throws Throwable {Object obj = System.currentTimeMillis() % 2 == 0 ? System.out : new ClassA();// 無論obj最終是哪個實現類，下面這句都能正確調用到println方法。getPrintlnMH(obj).invokeExact("icyfenix");}private static MethodHandle getPrintlnMH(Object reveiver) throws Throwable {// MethodType：代表“方法類型”，包含了方法的返回值（methodType()的第一個參數）和具體參數（methodType()第二個及以后的參數）。MethodType mt = MethodType.methodType(void.class, String.class);// lookup()方法來自于MethodHandles.lookup，這句的作用是在指定類中查找符合給定的方法名稱、方法類型，并且符合調用權限的方法句柄。// 因為這里調用的是一個虛方法，按照Java語言的規則，方法第一個參數是隱式的，代表該方法的接收者，也即this指向的對象，這個參數以前是放在參數列表中進行傳遞，現在提供了bindTo() 方法來完成這件事情。return lookup().findVirtual(reveiver.getClass(), "println", mt).bindTo(reveiver);} }

方法getPrintlnMH()中實際上是模擬了invokevirtual指令的執行過程，只不過它的分派邏輯并非固化在Class文件的字節碼上，而是通過一個由用戶設計的Java方法來實現。而這個方法本身的返回值（MethodHandle對象），可以視為對最終調用方法的一個“引用”。

MehtodHandle與反射Reflection區別？

• 機制本質上都是在模擬方法調用，但是Reflection是在模擬Java代碼層次的方法調用，而MehtodHandle是在模擬字節碼層次的方法調用。在MethodHandles.Lookup中的3個方法findStatic()、findVirtual()、findSpecial()與字節碼指令invokestatic、invokevirtual、invokespecial的執行權限校驗行為對應，而這些底層細節在使用Reflection API是不需要關心的。
• ·Reflection中的java.lang.reflect.Method對象遠比MethodHandle機制中的java.lang.invoke.MethodHandle對象所包含的信息來得多。前者是方法在Java端的全面映像，包含了方法的簽名、描述符以及方法屬性表中各種屬性的Java端表示方式，還包含執行權限等的運行期信息。而后者僅包含執行該方法的相關信息。用開發人員通俗的話來講，Reflection是重量級，而MethodHandle 是輕量級。
• ·由于MethodHandle是對字節碼的方法指令調用的模擬，那理論上虛擬機在這方面做的各種優化(如方法內聯)，在MethodHandle上也應當可以采用類似思路去支持（但目前實現還在繼續完善中），而通過反射去調用方法則幾乎不可能直接去實施各類調用點優化措施。

除了以上列舉的區別外，最關鍵的一點還在于去掉前面討論施加的前 提“僅站在Java語言的角度看”之后：Reflection API的設計目標是只為Java語言服務的，而MethodHandle 則設計為可服務于所有Java虛擬機之上的語言，其中也包括了Java語言而已，而且Java在這里并不是主角。

invokeDynamic指令有什么用？
某種意義上可以說invokedynamic指令與MethodHandle機制的作用是一樣的，都是為了解決原有4 條“invoke*”指令方法分派規則完全固化在虛擬機之中的問題，把如何查找目標方法的決定權從虛擬機轉嫁到具體用戶代碼之中，讓用戶（廣義的用戶，包含其他程序語言的設計者）有更高的自由度。而且，它們兩者的思路也是可類比的，都是為了達成同一個目的，只是一個用上層代碼和API來實現， 另一個用字節碼和Class中其他屬性、常量來完成。
??
每一處含有invokedynamic指令的位置都被稱作“動態調用點（Dynamically-Computed Call Site）”， 這條指令的第一個參數不再是代表方法符號引用的CONSTANT_Methodref_info常量，而是變為JDK 7 時新加入的CONSTANT_InvokeDynamic_info常量，從這個新常量中可以得到3項信息：引導方法（Bootstrap Method，該方法存放在新增的BootstrapMethods屬性中）、方法類型（MethodType）和名稱。引導方法是有固定的參數，并且返回值規定是java.lang.invoke.CallSite對象，這個對象代表了真正要執行的目標方法調用。根據CONSTANT_InvokeDynamic_info常量中提供的信息，虛擬機可以找到并且執行引導方法，從而獲得一個CallSite對象，最終調用到要執行的目標方法上。

掌控方法分派規則可以干什么？

class GrandFather { void thinking() {System.out.println("i am grandfather");} }class Father extends GrandFather { void thinking() {System.out.println("i am father");} }class Son extends Father { void thinking() {// 請讀者在這里填入適當的代碼（不能修改其他地方的代碼）// 實現調用祖父類的thinking()方法，打印"i am grandfather"} }

在擁有invokedynamic和invoke包之前，使用純粹的java語言很難處理這個問題（使用ASM字節碼工具直接生成字節碼還是可以處理的，但這已經不是java 語言層面解決問題了），原因是在Son類的thinking()方法中根本無法獲取到一個實際類型是GrandFather的對象引用，而invokevirtual指令的分派邏輯是固定的，只能按照方法接收者的實際類型進行分派，這個邏輯完全固化在虛擬機中，程序員無法改變。

如果是JDK 7 Update 9可以使用MethodHandler解決 public class Son extends Father {@Overridepublic void thinking() {try {MethodType mt = MethodType.methodType(void.class);Field lookupImpl = MethodHandles.Lookup.class.getDeclaredField("IMPL_LOOKUP");lookupImpl.setAccessible(true);((MethodHandles.Lookup) lookupImpl.get(null)).findSpecial(GrandFather.class, "thinking", mt, Father.class).bindTo(this).invoke();} catch (Throwable e) {}} } 輸出： JDK 7 Update 9但這個邏輯在JDK 7 Update 9之后被視作一個潛在的安全性缺陷修正了，原因是必須保證findSpecial()查找方法版本時受到的訪問約束（譬如對訪問控制的限制、對參數類型的限制）應與使用invokespecial指令一樣，兩者必須保持精確對等，包括在上面的場景中它只能訪問到其直接父類中的方法版本，所以以上代碼在JDK8中運行會得到結果i am father

新版本的JDK中，MethodHandles API實現時是預留了后門的，訪問保護是通過一個allowModes的參數來控制，而且這個參數可以被設置成“TRUSTED”來繞開所有的保護措施。盡管這個類只是在Java類庫本身使用，沒有開放給外部設置，但我們可以通過反射輕易打破這種限制，

MethodType mt = MethodType.methodType(void.class); Field lookupImpl = MethodHandles.Lookup.class.getDeclaredField("IMPL_LOOKUP"); lookupImpl.setAccessible(true); MethodHandle mh = ((MethodHandles.Lookup) lookupImpl.get(null)).findSpecial(GrandFather.class,"thinking",mt, Father.class); mh.invoke(this);輸出結果： i am grandfather

---

五、基于棧的字節碼解釋執行引擎

概念模型中，虛擬機是如何執行方法里面的字節碼指令？其執行引擎是如何工作的？

實際的虛擬機實現并不是按照下文中的動作一板一眼地進行機械式計算，而是動態產生每條字節碼對應的匯編代碼來運行，這與概念模型中執行過程的差異很大，但是結果卻能保證是一致的

下面的那條分支，就是傳統編譯原理中程序代碼到目標機器代碼的生成過程；而中間的那條分支，自然就是解釋執行的過程

在Java語言中，Javac編譯器完成了程序代碼經過詞法分析、語法分析到抽象語法樹，再遍歷語法樹生成線性的字節碼指令流的過程。因為這一部分動作是在Java虛擬機之外進行的，而解釋器在虛擬機的內部，所以Java程序的編譯就是半獨立的實現。

基于棧的指令集和基于寄存器的指令集有什么區別？
Java編譯器輸出的字節碼指令流基本上是一種基于棧的指令集架構，字節碼指令流里面的指令大部分都是零地址指令，依賴操作數棧進行工作，與之相對地是基于寄存器架構的指令集，最典型的是x86的二地址指令集，即現在主流PC機中物理硬件直接支持的指令集架構，這些指令依賴寄存器工作

示例分別使用兩種指令集去計算 “1+1”基于棧的指令集 iconst_1 iconst_1 iadd istore_0 兩條iconst_1指令連續把兩個常量1壓入棧后，iadd指令把棧頂的兩個值出棧、相加，然后把結果放回棧頂，最后istore_0把棧頂的值放到局部變量表的第0個變量槽中。這種指令流中的指令通常都是不帶參數的，使用操作數棧中的數據作為指令的運算輸入，指令的運算結果也存儲在操作數棧之中?；诩拇嫫鞯闹噶罴?mov eax, 1 add eax, 1 mov指令把EAX寄存器的值設為1，然后add指令再把這個值加1，結果就保存在EAX寄存器里面。這種二地址指令是x86指令集中的主流，每個指令都包含兩個單獨的輸入參數，依賴于寄存器來訪問和存儲數據。

兩套指令集各有優勢，同時并存和發展
基于棧的指令集主要優點是可移植，因為寄存器由硬件提供，程序直接依賴這些硬件寄存器則不可避免會受到硬件的約束。
棧結構指令集的主要缺點是理論上執行速度相對會稍慢，這里的執行速度是局限要局限再解釋執行的狀態下，如果經過即時編譯器輸出成物理機的匯編指令，則就與虛擬機采用哪種指令集架構沒有關系了。在解釋執行時，棧架構指令雖然緊湊，但完成同樣的功能所需指令數一般比寄存器架構的多，因為出棧、入棧操作本身就產生大量的指令，更重要的是棧實現在內存中，頻繁的棧訪問意味著頻繁的內存訪問，因此由于指令數量和內存訪問的原因，導致了棧指令集架構的執行速度會相對慢一點。

基于棧的解釋器執行過程

public int calc() { int a = 100; int b = 200; int c = 300;return (a + b) * c; }字節碼 public int calc(); Code: Stack=2, Locals=4, Args_size=1 0: bipush 100 2: istore_1 3: sipush 200 6: istore_2 7: sipush 300 10: istore_3 11: iload_1 12: iload_2 13: iadd 14: iload_3 15: imul 16: ireturn }從字節碼可以看出需要深度為2的操作數棧和4個變量槽的局部變量空間

第一步：執行偏移地址為0的指令，將常量值100推送入操作數棧棧頂

第二步：將操作數棧棧頂的整數值出棧并存放到第一個局部變量槽中，后續4條指令都是做一樣的事，對應代碼中把變量a、b、c賦值為100、200、300

第三步：將局部變量表第一個變量槽的整型數值復制到操作數棧棧頂

第四步：把第二個變量槽的數值入棧

第五步：將操作數棧中前兩個棧頂元素出棧，做整型加法，然后把結果重新入棧

第六步：把存放在第三個變量槽中的300入棧到操作數棧中，這時操作數棧為兩個整數300，下一條指令imul是將操作數棧中頭兩個棧頂元素出棧，做整型乘法，然后把結果入棧，與iadd類似

第七步：執行ireturn指令 結束方法并將操作數棧棧頂的整數值返回給該方法的調用者。至此方法調用結束

上面的執行過程僅是一種概念模型，虛擬機最終會對執行過程做出一系列優化措施，實際的運作過程并不會完全符合概念模型的描述。

---

六、附錄

JVM是怎么實現invokedynamic的？

總結

以上是生活随笔為你收集整理的深入理解Java虚拟机（周志明第三版）- 第八章：虚拟机字节码执行引擎的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。