Java為何需要平衡方法調用與內聯
在 Java 中，方法調用一般通過 Virtual Call 還有 Classic Call。
Classic Call 就是直接指向方法的地址，需要一次尋址到方法的地址，比直接執行代碼慢。
Virtual Call 需要通過 VMT(Virtual Method Table)。這個VMT存儲的是該class對象中所有的Virtual Method，程序運行的時候首先加載實例對象，然後通過實例對象找到VMT，通過VMT再找到對應的方法地址，再執行代碼。所以比 Classic Call 更慢。
Java 中除瞭 static 方法，private 方法以及構造器是 Classic Call 之外，基本都是 Virtual Call。
為瞭優化，JVM 運行時，JVM使用混合模式來從字節碼轉換成機器可以運行的機器碼，混合模式包括解釋器和JIT：
解釋器工作機制：
在編譯時，主要是將java源代碼文件編譯為java統一的字節碼，但是編譯成的字節碼並不能直接運行，而是通過JVM讀取運行。JVM中的解釋器就是將.class文件一行一行翻譯之後再運行，翻譯就是轉換成當前機器可以運行的機器碼，它不會一次性把整個文件都翻譯過來，而是翻譯一句，執行一句，再翻譯，再執行，所以解釋器的程序運行起來會比較慢，每次都要解釋之後再執行。所以，有些時候，我們想是否可以把解釋之後的內容緩存起來，這樣不就可以直接運行瞭？但是，如果每段代碼都要緩存起來，例如僅僅執行一次的代碼也緩存起來，這樣太浪費內存瞭。所以，引入一個新的運行時編譯器，JIT來解決這些問題，加速熱點代碼的執行。
JIT運行時編譯器工作機制：
JIT針對熱點代碼，進行編譯與深度優化，優化後的機器碼會被緩存起來，存入CodeCache(代碼高速緩存)中。對於非熱點代碼，例如隻運行一次的代碼（類構造器等等），直接解釋執行，更加快速。JIT不僅花更多時間去編譯優化，而且還多耗費瞭很多內存。字節碼轉換為可執行的機器碼，大小會大很多很多倍。這也是為啥，解釋器每次都要翻譯並且執行，JIT隻針對熱點代碼進行編譯優化的原因。JIT編譯器執行的一些常見優化操作包括數據分析，從堆棧操作到寄存器操作的轉換，通過寄存器分配減少內存訪問，消除常見子表達式等。JIT編譯器進行的優化程度越高，在執行階段花費的時間越多。因此，JIT編譯器無法承擔所有靜態編譯器所做的優化，這不僅是因為增加瞭執行時間的開銷，而且還因為它隻對程序進行瞭限制。這也就解釋瞭為什麼有些JVM會選擇不總是做JIT編譯，而是選擇用解釋器+JIT編譯器的混合執行引擎。
JIT其中一項很重要的優化就是內聯: 內聯是將較小方法的樹合並或“內聯”到其調用者的樹中的過程。這樣可以加速頻繁執行的方法調用。不同分層優化階段，使用的算法不同。主要包括：
- Trivial方法內聯
- 調用圖內聯
- 尾部遞歸消除
- 虛擬調用優化
這樣省略瞭 calling method。但是，如果將所有方法都內聯的話，編譯出來的機器碼會很大很大，內存占用會急劇增高，效率低下。所以，需要 JIT 把握好這個優化的度
總結起來就是：JIT 是即時優化並編譯代碼，優化代碼包括內聯，編譯後的代碼保存在內存中，也就是代碼高速緩存，編譯後的代碼是很大的，所以不能所有代碼都編譯，需要是熱點代碼。並且，內聯也會將這個方法變得更大。代碼高速緩存也是需要清理的，代碼高速緩存占用過高，也會增加清理概率，因為你可能幾個方法都是高頻執行，但是編譯之後占用過大導致超過代碼高速緩存限制，那麼會發生代碼高速緩存清理，就是代碼緩存中的編譯代碼一直在換。清理代碼高速緩存，會讓所有線程進入 Safepoint，然後才能清理，也就是 stop the world。內聯過多，方法變大，這種清理頻率也會變大。
以上就是Java為何需要平衡方法調用與內聯的詳細內容，更多關於Java 平衡方法調用與內聯的資料請關註WalkonNet其它相關文章！