Java 動態繫結機制的內幕
在Java方法呼叫的過程中,JVM是如何知道呼叫的是哪個類的方法原始碼? 這裡面到底有什麼內幕呢? 這篇文章我們就將揭露JVM方法呼叫的靜態(static binding) 和動態繫結機制(auto binding) 。
靜態繫結機制
//被呼叫的類 package hr.test; class Father{ public static void f1(){ System.out.println("Father— f1()"); } } //呼叫靜態方法 import hr.test.Father; public class StaticCall{ public static void main(){ Father.f1(); //呼叫靜態方法 } }
上面的原始碼中執行方法呼叫的語句(Father.f1())被編譯器編譯成了一條指令:invokestatic #13。我們看看JVM是如何處理這條指令的
(1) 指令中的#13指的是StaticCall類的常量池中第13個常量表的索引項(關於常量池詳見《Class檔案內容及常量池 》)。這個常量表(CONSTATN_Methodref_info) 記錄的是方法f1資訊的符號引用(包括f1所在的類名,方法名和返回型別)。JVM會首先根據這個符號引用找到方法f1所在的類的全限定名: hr.test.Father;
(2) 緊接著JVM會載入、連結和初始化Father類;
(3) 然後在Father類所在的方法區中找到f1()方法的直接地址,並將這個直接地址記錄到StaticCall類的常量池索引為13的常量表中。這個過程叫常量池解析 ,以後再次呼叫Father.f1()時,將直接找到f1方法的位元組碼;
(4) 完成了StaticCall類常量池索引項13的常量表的解析之後,JVM就可以呼叫f1()方法,並開始解釋執行f1()方法中的指令了。
通過上面的過程,我們發現經過常量池解析之後,JVM就能夠確定要呼叫的f1()方法具體在記憶體的什麼位置上了。實際上,這個資訊在編譯階段就已經在StaticCall類的常量池中記錄了下來。這種在編譯階段就能夠確定呼叫哪個方法的方式,我們叫做靜態繫結機制 。
除了被static 修飾的靜態方法,所有被private 修飾的私有方法、被final 修飾的禁止子類覆蓋的方法都會被編譯成invokestatic指令。另外所有類的初始化方法<init>和<clinit>會被編譯成invokespecial指令。JVM會採用靜態繫結機制來順利的呼叫這些方法。
動態繫結機制
package hr.test; //被呼叫的父類 class Father{ public void f1(){ System.out.println("father-f1()"); } public void f1(int i){ System.out.println("father-f1() para-int "+i); } } //被呼叫的子類 class Son extends Father{ public void f1(){ //覆蓋父類的方法 System.out.println("Son-f1()"); } public void f1(char c){ System.out.println("Son-s1() para-char "+c); } } //呼叫方法 import hr.test.*; public class AutoCall{ public static void main(String[] args){ Father father=new Son(); //多型 father.f1(); //列印結果: Son-f1() } }
上面的原始碼中有三個重要的概念:多型(polymorphism) 、方法覆蓋 、方法過載 。列印的結果大家也都比較清楚,但是JVM是如何知道f.f1()呼叫的是子類Sun中方法而不是Father中的方法呢?在解釋這個問題之前,我們首先簡單的講下JVM管理的一個非常重要的資料結構——方法表 。
在JVM載入類的同時,會在方法區中為這個類存放很多資訊(詳見《Java 虛擬機器體系結構 》)。其中就有一個資料結構叫方法表。它以陣列的形式記錄了當前類及其所有超類的可見方法位元組碼在記憶體中的直接地址 。下圖是上面原始碼中Father和Sun類在方法區中的方法表:
上圖中的方法表有兩個特點:(1) 子類方法表中繼承了父類的方法,比如Father extends Object。 (2) 相同的方法(相同的方法簽名:方法名和引數列表)在所有類的方法表中的索引相同。比如Father方法表中的f1()和Son方法表中的f1()都位於各自方法表的第11項中。
對於上面的原始碼,編譯器首先會把main方法編譯成下面的位元組碼指令:
0 new hr.test.Son [13] //在堆中開闢一個Son物件的記憶體空間,並將物件引用壓入運算元棧 3 dup 4 invokespecial #7 [15] // 呼叫初始化方法來初始化堆中的Son物件 7 astore_1 //彈出運算元棧的Son物件引用壓入區域性變數1中 8 aload_1 //取出區域性變數1中的物件引用壓入運算元棧 9 invokevirtual #15 //呼叫f1()方法 12 return
其中invokevirtual指令的詳細呼叫過程是這樣的:
(1) invokevirtual指令中的#15指的是AutoCall類的常量池中第15個常量表的索引項。這個常量表(CONSTATN_Methodref_info) 記錄的是方法f1資訊的符號引用(包括f1所在的類名,方法名和返回型別)。JVM會首先根據這個符號引用找到呼叫方法f1的類的全限定名: hr.test.Father。這是因為呼叫方法f1的類的物件father宣告為Father型別。
(2) 在Father型別的方法表中查詢方法f1,如果找到,則將方法f1在方法表中的索引項11(如上圖)記錄到AutoCall類的常量池中第15個常量表中(常量池解析 )。這裡有一點要注意:如果Father型別方法表中沒有方法f1,那麼即使Son型別中方法表有,編譯的時候也通過不了。因為呼叫方法f1的類的物件father的宣告為Father型別。
(3) 在呼叫invokevirtual指令前有一個aload_1指令,它會將開始建立在堆中的Son物件的引用壓入運算元棧。然後invokevirtual指令會根據這個Son物件的引用首先找到堆中的Son物件,然後進一步找到Son物件所屬型別的方法表。過程如下圖所示:
(4) 這是通過第(2)步中解析完成的#15常量表中的方法表的索引項11,可以定位到Son型別方法表中的方法f1(),然後通過直接地址找到該方法位元組碼所在的記憶體空間。
很明顯,根據物件(father)的宣告型別(Father)還不能夠確定呼叫方法f1的位置,必須根據father在堆中實際建立的物件型別Son來確定f1方法所在的位置。這種在程式執行過程中,通過動態建立的物件的方法表來定位方法的方式,我們叫做 動態繫結機制 。
上面的過程很清楚的反映出在方法覆蓋的多型呼叫的情況下,JVM是如何定位到準確的方法的。但是下面的呼叫方法JVM是如何定位的呢?(仍然使用上面程式碼中的Father和Son型別)
public class AutoCall{ public static void main(String[] args){ Father father=new Son(); char c='a'; father.f1(c); //列印結果:father-f1() para-int 97 } }
問題是Fahter型別中並沒有方法簽名為f1(char)的方法呀。但列印結果顯示JVM呼叫了Father型別中的f1(int)方法,並沒有呼叫到Son型別中的f1(char)方法。
根據上面詳細闡述的呼叫過程,首先可以明確的是:JVM首先是根據物件father宣告的型別Father來解析常量池的(也就是用Father方法表中的索引項來代替常量池中的符號引用)。如果Father中沒有匹配到”合適” 的方法,就無法進行常量池解析,這在編譯階段就通過不了。
那麼什麼叫”合適”的方法呢?當然,方法簽名完全一樣的方法自然是合適的。但是如果方法中的引數型別在宣告的型別中並不能找到呢?比如上面的程式碼中呼叫father.f1(char),Father型別並沒有f1(char)的方法簽名。實際上,JVM會找到一種“湊合”的辦法,就是通過 引數的自動轉型 來找 到“合適”的 方法。比如char可以通過自動轉型成int,那麼Father類中就可以匹配到這個方法了 (關於Java的自動轉型問題可以參見《【解惑】Java型別間的轉型》)。但是還有一個問題,如果通過自動轉型發現可以“湊合”出兩個方法的話怎麼辦?比如下面的程式碼:
class Father{ public void f1(Object o){ System.out.println("Object"); } public void f1(double[] d){ System.out.println("double[]"); } } public class Demo{ public static void main(String[] args) { new Father().f1(null); //列印結果: double[] } }
null可以引用於任何的引用型別,那麼JVM如何確定“合適”的方法呢。一個很重要的標準就是:如果一個方法可以接受傳遞給另一個方法的任何引數,那麼第一個方法就相對不合適。比如上面的程式碼: 任何傳遞給f1(double[])方法的引數都可以傳遞給f1(Object)方法,而反之卻不行,那麼f1(double[])方法就更合適。因此JVM就會呼叫這個更合適的方法。
總結
(1) 所有私有方法、靜態方法、構造器及初始化方法<clinit>都是採用靜態繫結機制。在編譯器階段就已經指明瞭呼叫方法在常量池中的符號引用,JVM執行的時候只需要進行一次常量池解析即可。
(2) 類物件方法的呼叫必須在執行過程中採用動態繫結機制。
首先,根據物件的宣告型別(物件引用的型別)找到“合適”的方法。具體步驟如下:
① 如果能在宣告型別中匹配到方法簽名完全一樣(引數型別一致)的方法,那麼這個方法是最合適的。
② 在第①條不能滿足的情況下,尋找可以“湊合”的方法。標準就是通過將引數型別進行自動轉型之後再進行匹配。如果匹配到多個自動轉型後的方法簽名f(A)和f(B),則用下面的標準來確定合適的方法:傳遞給f(A)方法的引數都可以傳遞給f(B),則f(A)最合適。反之f(B)最合適 。
③ 如果仍然在宣告型別中找不到“合適”的方法,則編譯階段就無法通過。
然後,根據在堆中建立物件的實際型別找到對應的方法表,從中確定具體的方法在記憶體中的位置。
覆寫(override)
一個例項方法可以覆寫(override)在其超類中可訪問到的具有相同簽名的所有例項方法,從而使能了動態分派(dynamic dispatch);換句話說,VM將基於例項的執行期型別來選擇要呼叫的覆寫方法。覆寫是物件導向程式設計技術的基礎,並且是唯一沒有被普遍勸阻的名字重用形式:
class Base{ public void f(){} } class Derived extends Base{ public void f(){} }
隱藏(hide)
一個域、靜態方法或成員型別可以分別隱藏(hide)在其超類中可訪問到的具有相同名字(對方法而言就是相同的方法簽名)的所有域、靜態方法或成員型別。隱藏一個成員將阻止其被繼承。
class Base{ public static void f(){} } class Derived extends Base { private static void f(){} //hides Base. f() }
過載(overload)
在某個類中的方法可以過載(overload)另一個方法,只要它們具有相同的名字和不同的簽名。由呼叫所指定的過載方法是在編譯期選定的。
class CircuitBreaker{ public void f (int i){} //int overloading public void f(String s){} //String overloading }
遮蔽(shadow)
一個變數、方法或型別可以分別遮蔽(shadow)在一個閉合的文字範圍內的具有相同名字的所有變數、方法或型別。如果一個實體被遮蔽了,那麼你用它的簡單名是無法引用到它的;根據實體的不同,有時你根本就無法引用到它。
class WhoKnows{ static String sentence=”I don't know.”; public static void main(String[] args〕{ String sentence=”I don't know.”; //shadows static field System.out. println (sentence); // prints local variable } }
儘管遮蔽通常是被勸阻的,但是有一種通用的慣用法確實涉及遮蔽。構造器經常將來自其所在類的某個域名重用為一個引數,以傳遞這個命名域的值。這種慣用法並不是沒有風險,但是大多數Java程式設計師都認為這種風格帶來的實惠要超過
其風險:
class Belt{ private find int size ; //Parameter shadows Belt. size public Belt (int size){ this. size=size; } }
遮掩(obscure)
一個變數可以遮掩具有相同名字的一個型別,只要它們都在同一個範圍內:如果這個名字被用於變數與型別都被許可的範圍,那麼它將引用到變數上。相似地,一個變數或一個型別可以遮掩一個包。遮掩是唯一一種兩個名字位於不同的名字空間的名字重用形式,這些名字空間包括:變數、包、方法或型別。如果一個型別或一個包被遮掩了,那麼你不能通過其簡單名引用到它,除非是在這樣一個上下文環境中,即語法只允許在其名字空間中出現一種名字。遵守命名習慣就可以極大地消除產生遮掩的可能性:
public class Obscure{ static String System;// Obscures type java.lang.System public static void main(String[] args) // Next line won't compile:System refers to static field System. out. println(“hello, obscure world!”); } }
本文完!
相關文章
- java中的靜態繫結與動態繫結Java
- JAVA動態繫結淺析Java
- C++的動態繫結和靜態繫結C++
- 理解靜態繫結與動態繫結
- this繫結機制及特性
- Java動態代理和反射機制Java反射
- 關於動態字串的繫結字串
- 一文弄懂Java和C中動態連結機制Java
- Javascrip—關於this繫結機制的解析(12)Java
- 三、動態繫結屬性
- [譯] Angular 屬性繫結更新機制Angular
- 如何妙用Spring 資料繫結機制?Spring
- 動態生成的html元素繫結click事件HTML事件
- vue 動態繫結 v-modelVue
- 動態繫結 input v-model
- Vue select 繫結動態變數Vue變數
- Vue 動態繫結CSS樣式VueCSS
- 一文學會 Java 動態代理機制Java
- Java進階 | Proxy動態代理機制詳解Java
- 對於動態載入內容 (包括 Ajax 請求內容) 繫結點選事件事件
- 構造器中呼叫動態繫結的方法
- 介面的繫結方案和動態SQLSQL
- class 和 style 資料動態繫結
- 域名繫結動態IP實戰案例
- 帶你學 Java 技術之動態代理機制Java
- 好程式設計師Java教程Java動態代理機制詳解程式設計師Java
- jQuery實現DOM元素事件動態繫結jQuery事件
- 基於NACOS和JAVA反射機制動態更新JAVA靜態常量非@Value註解Java反射
- MVVM雙向繫結機制的原理和程式碼實現MVVM
- 1.1 - Laravel5.6 - Contextual 上下文繫結機制LaravelContext
- Java動態代理機制——那些讓你面試脫穎而出的技能Java面試
- Vue 框架-05-動態繫結 css 樣式Vue框架CSS
- 基於 CGLIB 庫的動態代理機制CGLib
- starrycan的pwn隨筆——ELF檔案和延遲繫結機制
- 後期靜態繫結
- 好程式設計師Java培訓分享Java動態代理機制詳解程式設計師Java
- 動態 SQL 和快取機制SQL快取
- Java類載入機制總結Java
- 05-v-bind動態繫結class(物件語法)物件