系列文章目錄

第一章： 走近Java
第二章： Java內(nèi)存區(qū)域與內(nèi)存溢出異常
第三章： Java垃圾收集器與內(nèi)存分配策略

---

代碼編譯的結(jié)果從本地機器碼轉(zhuǎn)變?yōu)樽止?jié)碼，是存儲格式發(fā)展的一小步，卻是編程語言發(fā)展的一大步

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

一、概述

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

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

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

---

二、運行時棧幀結(jié)構(gòu)

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

以Java程序的角度，同一個時刻、同一個線程里，在調(diào)用堆棧的所有方法都同時處于執(zhí)行狀態(tài)； 以執(zhí)行引擎的角度，在活動線程中，只有位于棧頂?shù)姆椒ㄊ沁\行的，只有位于棧頂?shù)臈巧У?#xff0c;稱為當前棧幀，與之關(guān)聯(lián)的方法稱為當前方法 執(zhí)行引擎所運行的所有字節(jié)碼指令都只針對當前棧幀進行操作

1、局部變量表

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

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

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

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

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

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

2、操作數(shù)棧

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

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

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

3、動態(tài)連接

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

4、方法返回地址

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

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

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

5、附加信息

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

---

三、方法調(diào)用

方法調(diào)用并不等同于方法執(zhí)行，唯一的任務(wù)是確定被調(diào)用方法的版本（即調(diào)用哪個方法），暫時還未涉及到方法內(nèi)部的具體運行過程

1、解析

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

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

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

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

示例： package com.tencent;/*** 方法靜態(tài)解析演示** @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 }查看生成字節(jié)碼，發(fā)現(xiàn)是通過invokestatic調(diào)用sayHello方法，且調(diào)用的方法版本已經(jīng)在編譯時以常量池項形式固化到字節(jié)碼指令參數(shù)中（代碼中的31號常量池項）

2、分派

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

2.1 靜態(tài)分派

靜態(tài)分派與重載的關(guān)系

package com.tencent;/*** 方法靜態(tài)分派演示** @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);} }運行結(jié)果 hello,guy! hello,guy!

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

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

所有依賴靜態(tài)類型來決定方法執(zhí)行版本的分派動作都稱為靜態(tài)分派。靜態(tài)分派最典型的應(yīng)用表現(xiàn)就是方法重載。

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

/*** 重載方法匹配優(yōu)先級** @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');} }輸出結(jié)果 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 ...

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

2.2 動態(tài)分派

/*** 方法動態(tài)分派演示** @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();} }字節(jié)碼： 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運行結(jié)果 man say hello woman say hello woman say hello

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

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

找到操作數(shù)棧棧頂?shù)牡谝粋€元素所指向的對象的實際類型，記作C

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

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

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

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

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

/*** 字段不參與多態(tài)** @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);} }輸出結(jié)果 I am Son, i have $0 I am Son, i have $4 This gay has $2

2.3 單分派與多分派

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

/*** 單分派、多分派演示** @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());} }運行結(jié)果： father choose 360 son choose qq

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

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

2.4 虛擬機動態(tài)分派的實現(xiàn)

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

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

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

---

四、動態(tài)類型語言支持

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

什么是類型檢查？

obj.println("hello world");

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

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

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

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

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

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最終是哪個實現(xiàn)類，下面這句都能正確調(diào)用到println方法。getPrintlnMH(obj).invokeExact("icyfenix");}private static MethodHandle getPrintlnMH(Object reveiver) throws Throwable {// MethodType：代表“方法類型”，包含了方法的返回值（methodType()的第一個參數(shù)）和具體參數(shù)（methodType()第二個及以后的參數(shù)）。MethodType mt = MethodType.methodType(void.class, String.class);// lookup()方法來自于MethodHandles.lookup，這句的作用是在指定類中查找符合給定的方法名稱、方法類型，并且符合調(diào)用權(quán)限的方法句柄。// 因為這里調(diào)用的是一個虛方法，按照Java語言的規(guī)則，方法第一個參數(shù)是隱式的，代表該方法的接收者，也即this指向的對象，這個參數(shù)以前是放在參數(shù)列表中進行傳遞，現(xiàn)在提供了bindTo() 方法來完成這件事情。return lookup().findVirtual(reveiver.getClass(), "println", mt).bindTo(reveiver);} }

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

MehtodHandle與反射Reflection區(qū)別？

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

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

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

掌控方法分派規(guī)則可以干什么？

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() {// 請讀者在這里填入適當?shù)拇a（不能修改其他地方的代碼）// 實現(xiàn)調(diào)用祖父類的thinking()方法，打印"i am grandfather"} }

在擁有invokedynamic和invoke包之前，使用純粹的java語言很難處理這個問題（使用ASM字節(jié)碼工具直接生成字節(jié)碼還是可以處理的，但這已經(jīng)不是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()查找方法版本時受到的訪問約束（譬如對訪問控制的限制、對參數(shù)類型的限制）應(yīng)與使用invokespecial指令一樣，兩者必須保持精確對等，包括在上面的場景中它只能訪問到其直接父類中的方法版本，所以以上代碼在JDK8中運行會得到結(jié)果i am father

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

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);輸出結(jié)果： i am grandfather

---

五、基于棧的字節(jié)碼解釋執(zhí)行引擎

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

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

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

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

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

示例分別使用兩種指令集去計算 “1+1”基于棧的指令集 iconst_1 iconst_1 iadd istore_0 兩條iconst_1指令連續(xù)把兩個常量1壓入棧后，iadd指令把棧頂?shù)膬蓚€值出棧、相加，然后把結(jié)果放回棧頂，最后istore_0把棧頂?shù)闹捣诺骄植孔兞勘淼牡?span id="ozvdkddzhkzd" class="token number">0個變量槽中。這種指令流中的指令通常都是不帶參數(shù)的，使用操作數(shù)棧中的數(shù)據(jù)作為指令的運算輸入，指令的運算結(jié)果也存儲在操作數(shù)棧之中?；诩拇嫫鞯闹噶罴?mov eax, 1 add eax, 1 mov指令把EAX寄存器的值設(shè)為1，然后add指令再把這個值加1，結(jié)果就保存在EAX寄存器里面。這種二地址指令是x86指令集中的主流，每個指令都包含兩個單獨的輸入?yún)?shù)，依賴于寄存器來訪問和存儲數(shù)據(jù)。

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

基于棧的解釋器執(zhí)行過程

public int calc() { int a = 100; int b = 200; int c = 300;return (a + b) * c; }字節(jié)碼 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 }從字節(jié)碼可以看出需要深度為2的操作數(shù)棧和4個變量槽的局部變量空間

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

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

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

第四步：把第二個變量槽的數(shù)值入棧

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

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

第七步：執(zhí)行ireturn指令 結(jié)束方法并將操作數(shù)棧棧頂?shù)恼麛?shù)值返回給該方法的調(diào)用者。至此方法調(diào)用結(jié)束

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

---

六、附錄

JVM是怎么實現(xiàn)invokedynamic的？

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。