在Java方法調(diào)用的過程中，JVM是如何知道調(diào)用的是哪個類的方法源代碼？ 這里面到底有什么內(nèi)幕呢？ 這篇文章我們就將揭露JVM方法調(diào)用的靜態(tài)(static binding)?和動態(tài)綁定機制(auto binding)?。

?

?

★ 靜態(tài)綁定機制

//被調(diào)用的類??

package?hr.test;??

class?Father{??

??????public?static?void?f1(){??

??????????????System.out.println("Father—?f1()");??

??????}??

}??

//調(diào)用靜態(tài)方法??

import?hr.test.Father;??

public?class?StaticCall{??

???????public?static?void?main(){??

????????????Father.f1();?//調(diào)用靜態(tài)方法??

???????}??

}??

???? 上面的源代碼中執(zhí)行方法調(diào)用的語句(Father.f1())被編譯器編譯成了一條指令：invokestatic #13。我們看看JVM是如何處理這條指令的

???? (1) 指令中的#13指的是StaticCall類的常量池中第13個常量表的索引項(關(guān)于常量池詳見《Class文件內(nèi)容及常量池》)。這個常量表(CONSTATN_Methodref_info?)?記錄的是方法f1信息的符號引用(包括f1所在的類名，方法名和返回類型)。JVM會首先根據(jù)這個符號引用找到方法f1所在的類的全限定名: hr.test.Father。

???? (2) 緊接著JVM會加載、鏈接和初始化Father類。

???? (3)?然后在Father類所在的方法區(qū)中找到f1()方法的直接地址，并將這個直接地址記錄到StaticCall類的常量池索引為13的常量表中。這個過程叫常量池解析?，以后再次調(diào)用Father.f1()時，將直接找到f1方法的字節(jié)碼。

???? (4) 完成了StaticCall類常量池索引項13的常量表的解析之后，JVM就可以調(diào)用f1()方法，并開始解釋執(zhí)行f1()方法中的指令了。

?

?????通過上面的過程，我們發(fā)現(xiàn)經(jīng)過常量池解析之后，JVM就能夠確定要調(diào)用的f1()方法具體在內(nèi)存的什么位置上了。實際上，這個信息在編譯階段就已經(jīng)在StaticCall類的常量池中記錄了下來。這種在編譯階段就能夠確定調(diào)用哪個方法的方式，我們叫做?靜態(tài)綁定機制?。

?

???? 除了被static?修飾的靜態(tài)方法，所有被private?修飾的私有方法、被final?修飾的禁止子類覆蓋的方法都會被編譯成invokestatic指令。另外所有類的初始化方法<init>和<clinit>會被編譯成invokespecial指令。JVM會采用靜態(tài)綁定機制來順利的調(diào)用這些方法。

?

?

?

★ 動態(tài)綁定機制

package?hr.test;??

//被調(diào)用的父類??

class?Father{??

????public?void?f1(){??

????????System.out.println("father-f1()");??

????}??

????????public?void?f1(int?i){??

????????????????System.out.println("father-f1()??para-int?"+i);??

????????}??

}??

//被調(diào)用的子類??

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);??

????????}??

}??

??

//調(diào)用方法??

import?hr.test.*;??

public?class?AutoCall{??

????public?static?void?main(String[]?args){??

????????Father?father=new?Son();?//多態(tài)??

????????father.f1();?//打印結(jié)果：?Son-f1()??

????}??

}??

????? 上面的源代碼中有三個重要的概念：多態(tài)(polymorphism)?、方法覆蓋?、方法重載?。打印的結(jié)果大家也都比較清楚，但是JVM是如何知道f.f1()調(diào)用的是子類Sun中方法而不是Father中的方法呢？在解釋這個問題之前，我們首先簡單的講下JVM管理的一個非常重要的數(shù)據(jù)結(jié)構(gòu)——方法表?。

?

??? ?? 在JVM加載類的同時，會在方法區(qū)中為這個類存放很多信息(詳見《Java 虛擬機體系結(jié)構(gòu)?》)。其中就有一個數(shù)據(jù)結(jié)構(gòu)叫方法表。它以數(shù)組的形式記錄了當前類及其所有超類的可見方法字節(jié)碼在內(nèi)存中的直接地址?。下圖是上面源代碼中Father和Sun類在方法區(qū)中的方法表：

?

?

????? 上圖中的方法表有兩個特點：(1) 子類方法表中繼承了父類的方法，比如Father extends Object。 (2) 相同的方法(相同的方法簽名：方法名和參數(shù)列表)在所有類的方法表中的索引相同。比如Father方法表中的f1()和Son方法表中的f1()都位于各自方法表的第11項中。

?

????? 對于上面的源代碼，編譯器首先會把main方法編譯成下面的字節(jié)碼指令：

0??new?hr.test.Son?[13]?//在堆中開辟一個Son對象的內(nèi)存空間，并將對象引用壓入操作數(shù)棧??

3??dup????

4??invokespecial?#7?[15]?//?調(diào)用初始化方法來初始化堆中的Son對象???

7??astore_1?//彈出操作數(shù)棧的Son對象引用壓入局部變量1中??

8??aload_1?//取出局部變量1中的對象引用壓入操作數(shù)棧??

9??invokevirtual?#15?//調(diào)用f1()方法??

12??return??

?????? 其中invokevirtual指令的詳細調(diào)用過程是這樣的：

?????? (1) invokevirtual指令中的#15指的是AutoCall類的常量池中第15個常量表的索引項。這個常量表(CONSTATN_Methodref_info?)?記錄的是方法f1信息的符號引用(包括f1所在的類名，方法名和返回類型)。JVM會首先根據(jù)這個符號引用找到調(diào)用方法f1的類的全限定名: hr.test.Father。這是因為調(diào)用方法f1的類的對象father聲明為Father類型。

?????? (2) 在Father類型的方法表中查找方法f1，如果找到，則將方法f1在方法表中的索引項11(如上圖)記錄到AutoCall類的常量池中第15個常量表中(常量池解析?)。這里有一點要注意：如果Father類型方法表中沒有方法f1，那么即使Son類型中方法表有，編譯的時候也通過不了。因為調(diào)用方法f1的類的對象father的聲明為Father類型。

?????? (3) 在調(diào)用invokevirtual指令前有一個aload_1指令，它會將開始創(chuàng)建在堆中的Son對象的引用壓入操作數(shù)棧。然后invokevirtual指令會根據(jù)這個Son對象的引用首先找到堆中的Son對象，然后進一步找到Son對象所屬類型的方法表。過程如下圖所示：

????????????????????

????? (4) 這是通過第(2)步中解析完成的#15常量表中的方法表的索引項11，可以定位到Son類型方法表中的方法f1()，然后通過直接地址找到該方法字節(jié)碼所在的內(nèi)存空間。

?

??????很明顯，根據(jù)對象(father)的聲明類型(Father)還不能夠確定調(diào)用方法f1的位置，必須根據(jù)father在堆中實際創(chuàng)建的對象類型Son來確定f1方法所在的位置。這種在程序運行過程中，通過動態(tài)創(chuàng)建的對象的方法表來定位方法的方式，我們叫做?動態(tài)綁定機制?。

?

????? 上面的過程很清楚的反映出在方法覆蓋的多態(tài)調(diào)用的情況下，JVM是如何定位到準確的方法的。但是下面的調(diào)用方法JVM是如何定位的呢？(仍然使用上面代碼中的Father和Son類型)

public?class?AutoCall{??

???????public?static?void?main(String[]?args){??

?????????????Father?father=new?Son();??

?????????????char?c='a';??

?????????????father.f1(c);?//打印結(jié)果：father-f1()??para-int?97??

???????}??

}??

?????? 問題是Fahter類型中并沒有方法簽名為f1(char)的方法呀。但打印結(jié)果顯示JVM調(diào)用了Father類型中的f1(int)方法，并沒有調(diào)用到Son類型中的f1(char)方法。

?

?????? 根據(jù)上面詳細闡述的調(diào)用過程，首先可以明確的是：JVM首先是根據(jù)對象father聲明的類型Father來解析常量池的(也就是用Father方法表中的索引項來代替常量池中的符號引用)。如果Father中沒有匹配到"合適"?的方法，就無法進行常量池解析，這在編譯階段就通過不了。

????? 那么什么叫"合適"的方法呢？當然，方法簽名完全一樣的方法自然是合適的。但是如果方法中的參數(shù)類型在聲明的類型中并不能找到呢？比如上面的代碼中調(diào)用father.f1(char)，Father類型并沒有f1(char)的方法簽名。實際上，JVM會找到一種“湊合”的辦法，就是通過?參數(shù)的自動轉(zhuǎn)型?來找?到“合適”的 方法。比如char可以通過自動轉(zhuǎn)型成int，那么Father類中就可以匹配到這個方法了?(關(guān)于Java的自動轉(zhuǎn)型問題可以參見《【解惑】Java類型間的轉(zhuǎn)型?》)。但是還有一個問題，如果通過自動轉(zhuǎn)型發(fā)現(xiàn)可以“湊合”出兩個方法的話怎么辦？比如下面的代碼：

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);?//打印結(jié)果：?double[]??

????}??

}??

??????? null可以引用于任何的引用類型，那么JVM如何確定“合適”的方法呢。一個很重要的標準就是：如果一個方法可以接受傳遞給另一個方法的任何參數(shù)，那么第一個方法就相對不合適。比如上面的代碼: 任何傳遞給f1(double[])方法的參數(shù)都可以傳遞給f1(Object)方法，而反之卻不行，那么f1(double[])方法就更合適。因此JVM就會調(diào)用這個更合適的方法。

?

?

★ 總結(jié)

?

????? (1) 所有私有方法、靜態(tài)方法、構(gòu)造器及初始化方法<clinit>都是采用靜態(tài)綁定機制。在編譯器階段就已經(jīng)指明了調(diào)用方法在常量池中的符號引用，JVM運行的時候只需要進行一次常量池解析即可。

?

????? (2) 類對象方法的調(diào)用必須在運行過程中采用動態(tài)綁定機制。

??? ? ? ?? 首先，根據(jù)對象的聲明類型(對象引用的類型)找到“合適”的方法。具體步驟如下：

?????????? ① 如果能在聲明類型中匹配到方法簽名完全一樣(參數(shù)類型一致)的方法，那么這個方法是最合適的。

?????????? ② 在第①條不能滿足的情況下，尋找可以“湊合”的方法。標準就是通過將參數(shù)類型進行自動轉(zhuǎn)型之后再進行匹配。如果匹配到多個自動轉(zhuǎn)型后的方法簽名f(A)和f(B)，則用下面的標準來確定合適的方法：傳遞給f(A)方法的參數(shù)都可以傳遞給f(B)，則f(A)最合適。反之f(B)最合適?。

?

?????????? ③ 如果仍然在聲明類型中找不到“合適”的方法，則編譯階段就無法通過。

?

?????????? 然后，根據(jù)在堆中創(chuàng)建對象的實際類型找到對應的方法表，從中確定具體的方法在內(nèi)存中的位置。

?

?

?

★ 覆寫（override）

?????? 一個實例方法可以覆寫（override）在其超類中可訪問到的具有相同簽名的所有實例方法，從而使能了動態(tài)分派（dynamic dispatch）；換句話說，VM將基于實例的運行期類型來選擇要調(diào)用的覆寫方法。覆寫是面向?qū)ο缶幊碳夹g(shù)的基礎(chǔ)，并且是唯一沒有被普遍勸阻的名字重用形式：

class?Base{??

??????public?void?f(){}??

}??

class?Derived?extends?Base{??

??????public?void?f(){}??

}??

?

?

★ 隱藏（hide）

?????? 一個域、靜態(tài)方法或成員類型可以分別隱藏（hide）在其超類中可訪問到的具有相同名字（對方法而言就是相同的方法簽名)的所有域、靜態(tài)方法或成員類型。隱藏一個成員將阻止其被繼承。

class?Base{??

??????public?static?void?f(){}??

}??

class?Derived?extends?Base??{??

??????private?static?void?f(){}???//hides?Base.?f()??

}??

?

★ 重載（overload）?
????? 在某個類中的方法可以重載（overload）另一個方法，只要它們具有相同的名字和不同的簽名。由調(diào)用所指定的重載方法是在編譯期選定的。

class?CircuitBreaker{??

??????public?void?f?(int?i){}????//int?overloading??

??????public?void?f(String?s){}???//String?overloading??

}??

?

★ 遮蔽（shadow）
???? 一個變量、方法或類型可以分別遮蔽（shadow）在一個閉合的文本范圍內(nèi)的具有相同名字的所有變量、方法或類型。如果一個實體被遮蔽了，那么你用它的簡單名是無法引用到它的;根據(jù)實體的不同，有時你根本就無法引用到它。

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??

????}??

}??

????? 盡管遮蔽通常是被勸阻的，但是有一種通用的慣用法確實涉及遮蔽。構(gòu)造器經(jīng)常將來自其所在類的某個域名重用為一個參數(shù)，以傳遞這個命名域的值。這種慣用法并不是沒有風險，但是大多數(shù)Java程序員都認為這種風格帶來的實惠要超過
其風險:

class?Belt{??

??????private?find?int?size?;??//Parameter?shadows?Belt.?size??

??????public?Belt?(int?size){??

???????????this.?size=size;??

??????}??

}??

?

★ 遮掩（obscure）

?????? 一個變量可以遮掩具有相同名字的一個類型，只要它們都在同一個范圍內(nèi):如果這個名字被用于變量與類型都被許可的范圍，那么它將引用到變量上。相似地，一個變量或一個類型可以遮掩一個包。遮掩是唯一一種兩個名字位于不同的名字空間的名字重用形式，這些名字空間包括:變量、包、方法或類型。如果一個類型或一個包被遮掩了，那么你不能通過其簡單
名引用到它，除非是在這樣一個上下文環(huán)境中，即語法只允許在其名字空間中出現(xiàn)一種名字。遵守命名習慣就可以極大地消除產(chǎn)生遮掩的可能性:

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!”);??

??????}??

}??

?

?--------------------------------------------------------------------

PS： 歡迎關(guān)注公眾號"Devin說"，會不定期更新Java相關(guān)技術(shù)知識。

--------------------------------------------------------------------

轉(zhuǎn)載于:https://www.cnblogs.com/zhaolizhe/p/6923902.html

總結(jié)

以上是生活随笔為你收集整理的Java动态绑定机制的内幕的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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