深入解析多态和方法調用在JVM中的實作
多态(polymorphism)是面向對象程式設計的三大特性之一，它建立在繼承的基礎之上。在《Java核心技術卷》中這樣定義：
一個對象變量可以訓示多種實際類型的現象稱為多态。
在面向對象語言中，多态性允許你将一個子類型的實際對象賦予給一個父類型的變量。在這樣的指派完成之後，父類變量就可以根據實際賦予它的子類對象的不同，而以不同的方式工作。
在下面的示例中，Son類繼承了Father類并重寫了<code>f()</code>方法，又将Son類型的對象指派給Father類型的變量，再用它調用<code>f()</code>方法，稍微有點Java基礎的程式員都知道，此時會使用的是Son類中的<code>f()</code>，這種重寫就是一種典型的多态的展現。
在一些資料中，也把重載稱為一種多态的表現形式，本文也将重載視為多态的一種進行講解，但這種說法确實尚存争議。
Java虛拟機規範中，為所有的Java虛拟機位元組碼執行引擎規定了統一的輸入輸出：
輸入為位元組碼形式的二進制流。
輸出為執行結果。
在解釋運作階段，JVM以方法作為最基本的執行單元，棧幀是用于支援虛拟機進行方法調用和執行的資料結構，每一個方法從調用開始至執行結束的過程，都對應着一個棧幀在虛拟機棧裡面從入棧到出棧的過程。處于棧頂的棧幀就是目前棧幀，對應的方法就是正在運作的目前方法。
在這裡我們以服務解釋方法調用為前提，簡單說明JVM的運作時棧幀結構。
局部變量表。用于存放方法參數和方法内部定義的局部變量。
操作數棧。一個後入先出的LIFO棧，輔助方法執行中的運算操作。
動态連接配接。動态連接配接是一個指向運作時常量池中該棧幀所屬方法的引用，指向的顯然是一個符号引用。它的存在主要是支援方法調用過程中的動态連接配接。
方法調用中，符号引用一部分在類加載或者第一次使用時被轉化成直接引用，這種轉化稱為靜态解析。
另外一部分符号引用在每一次運作期間都轉化為直接引用，這種轉化稱為動态連接配接。
方法傳回位址。
正常退出方法時，方法傳回位址指向主調方法的PC計數器。
異常退出方法時，方法傳回位址指向異常處理表。
附加資訊。服務于調試、性能收集等等。
針對不同類型的方法，Java虛拟機支援以下五種方法調用位元組碼指令。
invokestatic。用于調用靜态方法。
invokespecial。用于調用執行個體構造器<code><init>()</code>方法、私有方法和父類中的方法。
在Java11以後，invokespecial已經常常不被用來調用私有方法，詳見下文的實驗和說明。
invokevirtual。用于調用所有的虛方法。
invokeinterface。用于調用接口方法。在運作時确定實作該接口的對象。
invokedynamic。先在運作時動态解析出調用點限定符所引用的方法，然後執行該方法。
詳見《深入了解Java虛拟機》p321
非虛方法指那些能夠在解析階段确定唯一的調用版本的方法，即上面由<code>invokestatic</code>和<code>invokespecial</code>調用的那些方法。而其他那些屬于類的，需要在運作時動态确定調用版本的方法，我們稱之為虛方法，最常見的虛方法就是普通的執行個體方法。
下面我們用位元組碼的形式看看這些方法調用指令。
在上面的代碼中，我們顯然可以看到，<code>staticMethod</code>使用<code>invokestatic</code>來進行調用，<code>"<init>"</code>構造方法使用了<code>invokespecial</code>來調用，這些都符合上面的約定。
但是！作為私有方法的<code>privateMethod</code>方法，卻在位元組碼中被編譯為使用<code>invokevirtrual</code>指令來調用。這是為什麼呢？
筆者查閱資料後，發現在JEP181中，對方法調用位元組碼指令進行了一定程度上的修改。在Java11版本及以後，嵌套類之間的私有方法的通路權限控制，就從編譯期轉移到了運作時，進而這樣的私有方法也被使用<code>invokevirtual</code>指令來調用，
總而言之，在Java11及以後，類中的私有方法往往用<code>invokevirtual</code>來調用，接口中的私有方法往往用<code>invokeinterface</code>調用，<code>invokespecial</code>往往僅用于執行個體構造器方法和父類中的方法。
解析過程是JVM将常量池内的符号引用替換為直接引用的過程。
符号引用以一組符号來描述所引用的目标，符号可以是任意形式的字面量，隻要使用時能無歧義地定位到目标即可。
直接引用是可以直接指向目标的指針、相對偏移量或一個能間接定位到目标的句柄。
《Java虛拟機規範》中明确要求在執行方法調用位元組碼指令之前，必須先對它們使用的符号引用進行解析。即所有<code>invoke...</code>指令之前。由于對同一個符号引用收到多次解析請求是很常見的事，虛拟機實作可以對第一次解析的結果進行緩存，譬如在運作時直接引用常量池中的記錄，并把常量辨別為已解析狀态，進而避免解析動作重複進行。（invokedynamic有一些特殊性質，這裡不做解釋）。
方法解析第一步需要解析出方法表的<code>class_index</code>項中索引的方法所屬的類或接口的符号引用，如果解析成功，那麼用C表示這個類，接下來虛拟機将按照以下步驟進行後續的方法搜尋。
如果我們在解析一個類方法，但C是一個接口，直接抛出<code>java.lang.IncompatibleClassChangeError</code>異常。
如果我們在解析的是接口方法，但C是一個類，也抛出<code>java.lang.IncompatibleClassChangeError</code>異常。
如果通過了第一步，在C中查找是否有簡單名稱和描述符都與目标比對的方法，有則傳回直接引用。
否則，依次在C的父類、接口清單、父接口中進行查找。如果找到則根據情況傳回直接引用或者抛出<code>java.lang.AbstractMethodError</code>異常。
如果都找不到，說明方法查找失敗。抛出<code>java.lang.NoSuchMethodError</code>。
最後，如果成功傳回了直接引用，就對這個方法進行權限驗證，如果發現不具備對此方法的通路權限，則抛出<code>java.lang.IllegalAccessError</code>異常。
已知有類<code>Father</code>、<code>Son</code>，且<code>Son</code>類繼承了<code>Father</code>類。假設我們以以下方式初始化變量。
那我們把上面代碼中的<code>Father</code>稱為變量object的靜态類型或外觀類型，将<code>Son</code>稱為object的實際類型或運作時類型。
當變量被定義的時候，它的靜态類型就已經确定，而實際類型可能會在運作過程中不斷變化，例如下面給出一個例子。
這個例子中，object的靜态類型始終是<code>Father</code>，而實際類型就隻有到運作時才知道了。
非虛方法，即使用<code>invokespecial</code>和<code>invokestatic</code>指令調用的方法，由于無法被覆寫，不可能存在其他版本，是以可以在類加載的解析階段直接進行方法解析，将符号引用全部轉變為明确的直接引用，不必延遲到運作期完成。
解析調用一定是一個靜态的過程，在編譯期間就完全确定。
值得說明的一點是，《Java虛拟機規範》明确地将final方法定義為非虛方法，但final方法是使用<code>invokevirtual</code>調用的，故使用下面講的分派機制，而非解析。
靜态分派用于解釋重載的場景，下面給出一個簡單的例子
顯然，JVM選擇了參數類型為Father的重載方法。
在虛拟機處理重載的情況時，是通過參數的靜态類型而不是實際類型作為判斷依據的。由于靜态類型在編譯期可知，是以在編譯階段Javac編譯器就根據參數的靜态類型決定了會使用哪個重載版本。比如上面會選擇<code>overload(Father)</code>作為調用目标，并把這個方法的符号引用寫入到<code>main()</code>方法的<code>invokevirtual</code>指令的參數中，後續在解釋階段執行<code>invokevirtual</code>時，這個選好的方法就會直接被使用。這個操作是在Javac前端編譯的文法分析階段直接完成的。
值得注意的是Javac編譯器确定的重載版本并非确定的某一個，而是在現有的選擇中選擇的“最合适的”一個。下面給出一個示例。
假如按照上面的代碼運作，那麼會被調用的是<code>sayHello(char arg)</code>方法，這就是Javac認為的最合适的方法。但假如我們将<code>sayHello(char arg)</code>注釋掉，那麼會被調用的是<code>sayHello(int arg)</code>方法，以此類推。
當然，一個腦子正常的程式員，不應該在自己的任何工程中寫出上述這樣的重載代碼。
靜态分派用于解釋重寫的場景，下面給出一個簡單的例子
顯然，JVM選擇了子類Son的重寫方法。顯然，在進行動态分派的時候，選擇方法的依據是調用方法的變量的實際類型。為了解釋清楚<code>invokevirtual</code>的作用方式，我們使用<code>javap</code>指令輸出這段代碼中<code>main</code>部分的位元組碼。
0 ~ 7 行的位元組碼是一些準備工作。建立了用于存放變量<code>object</code>的記憶體空間，調用了對應的構造器，并将對象執行個體存放在了局部變量表的第一個槽中。實際上對應代碼中下面這行。
第 8 行 的<code>aload_1</code>指令将剛剛建立的<code>object</code>對象引用壓到了操作數棧頂，這個對象即将調用<code>override()</code>方法。
第 9 行，正式使用了方法調用位元組碼指令<code>invokevirtual</code>。根據《Java虛拟機規範》，<code>invokevirtual</code>指令的運作時解析過程分為以下幾步。
找到操作數棧頂第一個元素指向的對象的實際類型并記作C。
在C中查找是否有簡單名稱和描述符都與目标比對的方法，有則傳回直接引用。
這裡所謂的“目标”，是目标方法的簡單外觀，在編譯階段就已經傳遞給<code>invokevirtual</code>作為參數
你應該可以看出來，其實就是我們在<code>2.3</code>節中講的位元組碼方法解析。重點就是我們從操作數棧頂找到了第一個元素指向的實際類型，并用它為基礎來做接下來的方法查找。這種運作期根據實際類型确定方法執行版本的分派過程稱為動态分派。
這裡再給出一個示例，幫助讀者更深入地了解動态分派。
應該不難了解，第一行的輸出來自父類Father構造器調用子類的<code>showmeTheMoney()</code>方法，此時子類尚未初始化，是以結果為0。
第二行的輸出來自子類調用<code>showmeTheMoney()</code>方法，此時子類已經初始化，結果為4。
第三行的輸出，使用<code>gay.money</code>直接取值，注意這個時候通過靜态類型通路變量，自然沒有類似<code>invokevirtual</code>的東西來找所謂的實際類型。是以使用的是變量 gay 的靜态類型，那麼就從<code>Father</code>類中取值，取到<code>money</code>的值為2。
是以，動态分派僅限于方法！
方法的接收者和方法的參數統稱為方法的宗量。選擇方法時使用一種宗量稱為單分派，使用多種宗量稱為多分派。那麼顯而易見的，我們可以總結出Java是一種靜态多分派，動态單分派的語言。
靜态多分派：在靜态分派的過程中，即重載的過程中，我們同時将方法的接收者和方法的參數作為選擇方法的依據，是以是多分派。
動态單分派：在動态分派的過程中，方法的參數模式在編譯階段就已經确定，唯一動态決定的是方法接收者的實際類型，是以是單分派。
注：方法的接收者指調用方法的對象。如<code>object.f()</code>，那麼object就是方法的接收者。
我們可以想見的是，在代碼運作過程中，一個虛方法可能會被大量多次地調用。是以一種在現代JVM中常見的優化手段是建立一個虛方法表，同理對于<code>invokeinterface</code>指令，也有接口方法表，它們的結構如下所示。
虛方法表中存放的是各種方法的實際入口位址。如果父類的方法在子類中沒有重寫，那麼子類虛方法表中的位址入口和父類虛方法表中的入口位址是一緻的，都指向父類的實作。否則子類的位址入口就會指向自己的實作。這樣可以節省大量的，動态分派過程中搜尋方法的開銷。
同時要求在父類和子類的虛方法表中，具有相同簽名的方法應該具有相同的索引序号，這樣當類型動态發生變化的時候，隻需要動态改變要查找的虛方法表，而不需要重新考慮在表中的位置。
虛方法表一般在類加載的連接配接階段進行初始化，準備了類的變量初始值後，虛拟機就會為該類的虛方法表進行初始化。
方法内聯是編譯器最重要的優化手段！簡單說就是把目标代碼以類似複制的方式替換到調用方法的位置，避免發生真實的方法調用。下面是一個示例。
方法内聯有兩個重要功能
去除方法調用的成本，包括查找方法版本和建立棧幀等。
為建立其他優化打好基礎。
是以我們稱方法内聯為最重要的優化手段。然而在Java虛拟機中，方法内聯卻有着一些天生的問題存在。對于Java中的虛方法，在将Java代碼翻譯為位元組碼的編譯階段，很多情況下編譯器根本不可能确定該使用哪個方法版本。而Java作為面向對象的語言，在Java程式設計中絕大多數的方法都是虛方法，絕大多數的方法調用都是<code>invokevirtual</code>或<code>invokeinterface</code>負責的。
但是方法内聯對于優化來說又過于重要，是以Java虛拟機的設計者們想了很多辦法來盡量解決問題。
Java虛拟機引入了一種名為類型繼承關系分析（CHA）的技術，它用于确定在目前已經加載的類中，那些虛方法是否存在多個版本。根據分析結果的不同，Java虛拟機可以采取不同的處理方法。
假如隻有一個方法，那麼就可以直接進行内聯，即假設整個應用程式也隻有這一個版本。這種内聯被稱為守護内聯。當然我們知道，并不是所有的類都被加載，保不齊未來就會有這個方法的新版本出現，是以我們預留好了逃生門，當假設不成立時就通過逃生門抛棄掉已經編譯的代碼，退回到解釋狀态進行執行，或者重新進行編譯。
假如有多個方法版本可供選擇，那麼編譯器會嘗試使用内聯緩存的方式來減少方法調用的開銷。内聯緩存的基本原理很好了解，就是當方法第一次調用發生後，緩存下方法接收者的版本資訊和對應的方法調用點。
每次方法調用時都比較接收者的版本，如果版本不變，那麼就是一種單态内聯緩存。通過該緩存進行調用就解除了方法搜尋帶來的開銷，而僅僅多了一個比較版本的微小開銷。
如果版本發生改變，說明程式用到了虛方法的多态特性，這時候會退化成超多态内聯緩存，這裡說是一種内聯緩存，其實就是不要緩存了，直接正常進行動态分派操作。
當緩存未命中的時候，大多數JVM的實作時退化成超多态内聯緩存，也有一些JVM選擇重寫單态内聯緩存，就是更新緩存為新的版本。這樣做的好處是以後還可能會命中，壞處是可能白白浪費一個寫的開銷。