Java的動態(tài)分派和靜態(tài)分派的實現(xiàn)
Java 方法執(zhí)行時的動態(tài)分派和靜態(tài)分派是 Java 實現(xiàn)多態(tài)的本質
背景
Java 的動態(tài)分派和靜態(tài)分派也是 Java 方法的執(zhí)行原理。 Java 源代碼的編譯之后,方法之間的調用是使用符號引用來表示的。當字節(jié)碼被 JVM 加載之后,符號引用才會被替換為對應方法在方法區(qū)的真實內(nèi)存地址。那么在替換之前,由于 Java 的方法重寫、重載,就導致符號引用對應的方法可能是一個虛方法,那么方法的真實實現(xiàn)在運行時就可能有多個。
所以在將符號引用替換為真實地址時,還需要做一件事情:那就是確定符號引用要替換的方法的版本。
運行時方法幀
與 C,C++ 一樣,JVM 在運行時也會維護一個運行棧,用于方法的調用和返回。當調用一個方法時,會為方法在棧上分配一塊內(nèi)存區(qū)域作為方法的幀。方法調用幀又分為下面幾個區(qū)域:
局部變量表
存儲方法參數(shù)和方法體中的局部變量,其容量在編譯期就已確定。容量的最小單位是 variable slot(變量槽)。
靜態(tài)方法的局部變量數(shù)就是方法體中聲明的變量數(shù);實例方法的局部變量數(shù)會多一個,多出的一個就是我們平時在實例方法中訪問的this。this 其實是編譯器在編譯時悄悄加到實例方法上的,而且是作為第一個參數(shù)。
操作數(shù)棧
JVM 的字節(jié)碼指令執(zhí)行機制是基于棧的,所以需要一個棧來存儲字節(jié)碼指令的操作數(shù)。
Android 的 VM 是基于寄存器的,所以沒有操作棧區(qū)域。
Android VM 采用寄存器存儲操作數(shù)有兩個主要原因:1. 寄存器乃是 CPU 內(nèi)部的高速內(nèi)存, 讀寫寄存器是與 CPU 交互最快的方式。2. 智能手機多使用 ARM 架構的 CPU, ARM 架構的 CPU 有很多通用寄存器可使用。
動態(tài)鏈接
方法體中調用其他方法時,會把將要調用的方法在常量池中的符號引用,轉化為將要其在方法區(qū)內(nèi)存中的開始地址信息,并儲存到動態(tài)鏈接中。
方法返回地址
一個方法執(zhí)行完畢之后,線程需要值得回到哪里繼續(xù)執(zhí)行,方法返回地址就是存儲這個信息的。返回地址一般就是當前方法的調用者的程序計數(shù)器的值(PC寄存器)。
- 正常完成出口: 方法正常返回時,如果有返回值,返回值會被壓入調用方法的操作數(shù)棧中
- 異常完成出口: 當方法發(fā)生了異常,且在異常表中沒有找到匹配的異常處理流程時,方法將不會有返回值
方法調用
方法調用并不等同于方法執(zhí)行,方法調用階段唯一的任務就是確定被調用方法的版本(即調用哪一個方法)
調用方法的指令
有以下字節(jié)碼指令用于方法的調用:
| 指令 | 用途 | 說明 |
|---|---|---|
| invokestatic | 調用類的靜態(tài)方法 | |
| invokespecfical | 調用對象的構造函數(shù)和私有方法 | |
| invokevirtual | 調用對象的 public/protected 的方法 | 可能通過繼承復寫的方法稱做 virtual method: 表示要到運行時才能定位到真正的方法實現(xiàn)。通過符號引用確定虛方法直接引用的過程又叫做動態(tài)分派 |
| invokeinterface | 調用接口的方法 | 具體的實現(xiàn)類將在調用時確定 |
| invokedynamic | JDK1.7 為了讓 JVM 支持動態(tài)類型語言引入的指令 | 讓用戶可以決定如何查找目標方法 |
符號引用到直接引用
由于 Java 的編譯沒有C C++ 編譯過程中的鏈接階段,所以 Class 文件中儲存的只是符號引用,等到了在運行時才通過符號引用定位到方法區(qū)中方法代碼在內(nèi)存布局中的位置--直接引用。
符號引用到直接引用的替換又涉及兩種方式。一種是解析,另一種是分派。解析發(fā)生在類加載的解析階段,分派發(fā)生在編譯或方法調用階段。
解析
在類加載的解析階段會把滿足「編譯期可知,運行期不可變」的方法的符號引用替換為指向方法區(qū)的直接引用,不會延遲到運行時再去完成。
滿足編譯期可知,運行期不可變的方法有:構造函數(shù)、私有方法、靜態(tài)方法、final修飾的方法。不滿足上述條件的方法的符號引用替換發(fā)生在方法調用期間。
分派 Dispatch
多態(tài)的實現(xiàn)原理
變量類型
理解分派之前,需要先看兩個類型概念。
比如:Object obj = new String("");
靜態(tài)類型
定義變量時,聲明的類型。比如這里 obj 的靜態(tài)類型就是 Object。靜態(tài)類型在編譯期的編譯器就能知道。
實際類型
變量賦值時的實際類型。比如這里 obj 的實際類型就是 String。實際類型在編譯期的編譯器是不可知的。
靜態(tài)分派
根據(jù)變量的「靜態(tài)類型(外觀類型)」匹配調用方法的過程稱為靜態(tài)分派。發(fā)生的場景為方法重載。
如下代碼:
public class StaticDispatch {
static abstract class Human { }
static class Man extends Human { }
static class Woman extends Human { }
static class Child extends Human { }
public void say(Human human) {
System.out.println("human");
}
public void say(Man man) {
System.out.println("man");
}
public void say(Woman woman) {
System.out.println("woman");
}
public void say(Child child) {
System.out.println("child");
}
}
public static void main(String[] args) {
Human man = new Man();
Human woman = new Woman();
Human child = new Child();
StaticDispatch dispatch = new StaticDispatch();
dispatch.say(man);
dispatch.say(woman);
dispatch.say(child);
}
main 方法的執(zhí)行結果:
human
human
human
雖然 StaticDispatch 為每種 Human 的子類都重載了一個 say 方法,但是由于重載采用的是靜態(tài)分派,是根據(jù)對象的靜態(tài)類型做方法匹配的。所以結果全都匹配到了 public void say(Human human) 方法。main 方法編譯之后的字節(jié)碼:
public static main([Ljava/lang/String;)V NEW method_invoke/StaticDispatch$Man DUP INVOKESPECIAL method_invoke/StaticDispatch$Man.<init> ()V ASTORE 1 NEW method_invoke/StaticDispatch$Woman DUP INVOKESPECIAL method_invoke/StaticDispatch$Woman.<init> ()V ASTORE 2 NEW method_invoke/StaticDispatch$Child DUP INVOKESPECIAL method_invoke/StaticDispatch$Child.<init> ()V ASTORE 3 NEW method_invoke/StaticDispatch DUP INVOKESPECIAL method_invoke/StaticDispatch.<init> ()V ASTORE 4 // 下面為調用 say ALOAD 4 ALOAD 1 INVOKEVIRTUAL method_invoke/StaticDispatch.say (Lmethod_invoke/StaticDispatch$Human;)V ALOAD 4 ALOAD 2 INVOKEVIRTUAL method_invoke/StaticDispatch.say (Lmethod_invoke/StaticDispatch$Human;)V ALOAD 4 ALOAD 3 INVOKEVIRTUAL method_invoke/StaticDispatch.say (Lmethod_invoke/StaticDispatch$Human;)V RETURN
從字節(jié)碼也能看到,編譯器確實是按照靜態(tài)分派選擇了匹配靜態(tài)類型的 StaticDispatch.say(LStaticDispatch$Human;)V 方法,而沒有按照變量的實際類型去匹配重載的方法。
public class Overload {
public static void out(char a) { System.out.println("char " + a); }
public static void out(int a) {System.out.println("int " + a);}
public static void out(long a) { System.out.println("long " + a); }
public static void out(float a) { System.out.println("float " + a); }
public static void out(double a) { System.out.println("double " + a); }
public static void out(Integer a) { System.out.println("integer"); }
public static void out(Character a) { System.out.println("character"); }
public static void out(Serializable a) { System.out.println("serializable " + a); }
public static void out(Comparable a) { System.out.println("comparable " + a); }
public static void out(Object a) { System.out.println("object " + a); }
public static void out(char... a) { System.out.println("char ... " + Arrays.toString(a)); }
public static void main(String[] args) {
out('c');
}
}
這段代碼也是一個靜態(tài)分派的例子,編譯器會選擇參數(shù)類型做合適的函數(shù)去調用??梢宰⑨尩羲?out 函數(shù),留下 out(Serializable a),你會發(fā)現(xiàn)程序也能成功編譯和運行。如果留下Serializeable 和 Comparable 編譯則會失敗,提示對 out 的引用不明確。
動態(tài)分派
根據(jù)變量的「實際類型」匹配調用方法的過程稱為動態(tài)分派。發(fā)生的場景為方法重寫。當調用一個可能被子類重寫或繼承的方法時,就會觸發(fā)動態(tài)分派。
public class DynamicDispatch {
static class Human {
public void say() {
System.out.println("human");
}
}
static class Man extends Human {
@Override
public void say() {
System.out.println("man");
}
}
static class Woman extends Human {
@Override
public void say() {
System.out.println("woman");
}
}
}
public static void main(String[] args) {
Human human = new Human();
Human man = new Man();
Human woman = new Woman();
human.say();
man.say();
woman.say();
}
main 方法的執(zhí)行結果:
human
man
woman
意料之中,所謂的多態(tài)就是這樣。那多態(tài)是如何實現(xiàn)的?
其實多態(tài)的實現(xiàn)過程也就是確定被重寫的方法版本的過程。main 方法編譯之后的字節(jié)碼:
public static main([Ljava/lang/String;)V NEW method_invoke/DynamicDispatch$Human DUP INVOKESPECIAL method_invoke/DynamicDispatch$Human.<init> ()V ASTORE 1 NEW method_invoke/DynamicDispatch$Man DUP INVOKESPECIAL method_invoke/DynamicDispatch$Man.<init> ()V ASTORE 2 NEW method_invoke/DynamicDispatch$Woman DUP INVOKESPECIAL method_invoke/DynamicDispatch$Woman.<init> ()V ASTORE 3 // 下面為多態(tài)調用 say ALOAD 1 INVOKEVIRTUAL method_invoke/DynamicDispatch$Human.say ()V ALOAD 2 INVOKEVIRTUAL method_invoke/DynamicDispatch$Human.say ()V ALOAD 3 INVOKEVIRTUAL method_invoke/DynamicDispatch$Human.say ()V RETURN
這里通過字節(jié)碼感覺都會調用Hunman#say方法的,但是運行之后并不是。
當 JVM 執(zhí)行這兩行字節(jié)碼時:
ALOAD 1 // 由上面 ASTORE 1 可知, 局部變量表的第一個變量是 Woman 的對象 INVOKEVIRTUAL method_invoke/DynamicDispatch$Human.say ()V // INVOKEVIRTUAL 指令就會到 Woman 類中去尋找 say 方法
調用 say 方法時,JVM 會先去當前調用的對象的類中查找是否存在和目標方法的描述符、簡單名稱一樣的方法,如果存在則將符號引用替換為找到的方法的直接引用,否則就向父類去查找,向父類的父類去查找..., 直到最后找不到拋出NoSuchMethod異常。
Human 的 say 方法的簽名:
public void say(); descriptor: ()V
Woman 的 say 方法的簽名:
public void say(); descriptor: ()V
可見 Woman 類的 Human 類中的 say 方法的描述符和簡單名稱是一樣的,所以 JVM 會優(yōu)先匹配 Woman 類中的方法。這也是多態(tài)調用的底層邏輯。
到此這篇關于Java的動態(tài)分派和靜態(tài)分派的實現(xiàn)的文章就介紹到這了,更多相關Java 動態(tài)分派和靜態(tài)分派內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!
相關文章
Spring Cache優(yōu)化數(shù)據(jù)庫訪問的項目實踐
本文主要介紹了Spring Cache優(yōu)化數(shù)據(jù)庫訪問的項目實踐,將創(chuàng)建一個簡單的圖書管理應用作為示例,并演示如何通過緩存減少對數(shù)據(jù)庫的頻繁查詢,感興趣的可以了解一下2024-01-01
Java實現(xiàn)局域網(wǎng)聊天室功能(私聊、群聊)
這篇文章主要為大家詳細介紹了Java實現(xiàn)局域網(wǎng)聊天室功能,包括私聊、群聊,文中示例代碼介紹的非常詳細,具有一定的參考價值,感興趣的小伙伴們可以參考一下2022-05-05
Spring Boot 中常用的注解@RequestParam及基本用法
@RequestParam 是 Spring Framework 和 Spring Boot 中常用的注解之一,用于從請求中獲取參數(shù)值,本文給大家介紹Spring Boot 中常用的注解@RequestParam,感興趣的朋友一起看看吧2023-10-10
Spring Boot中使用AOP統(tǒng)一處理web層異常的方法
這篇文章主要介紹了Spring Boot中使用AOP統(tǒng)一處理web層異常的相關資料,需要的朋友可以參考下2018-03-03
springboot?vue測試前端項目管理列表分頁功能實現(xiàn)
這篇文章主要為大家介紹了springboot?vue測試前端項目列表分頁功能實現(xiàn),有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪2022-05-05
Java實戰(zhàn)項目之斗地主和斗牛游戲的實現(xiàn)
讀萬卷書不如行萬里路,只學書上的理論是遠遠不夠的,只有在實戰(zhàn)中才能獲得能力的提升,本篇文章手把手帶你用Java實現(xiàn)一個斗地主和一個斗牛游戲,大家可以在過程中查缺補漏,提升水平2021-11-11
Spring和IDEA不推薦使用@Autowired?注解原因解析
這篇文章主要為大家介紹了Spring和IDEA不推薦使用@Autowired?注解原因解析,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪2023-07-07

