晚期（執行期）優化
摘自《深入理解 Java 虛擬機器：JVM 高階特性與最佳實踐》（第二版）
從計算機程式出現的第一天起，對效率的追求就是程式天生的堅定信仰，這個過程猶如一場沒有終點、永不停歇的 F1 方程式競賽，程式設計師是車手，技術平臺則是賽道上飛馳的賽車。
概述
在部分的商用虛擬機器（Sun HotSpot、IBM J9）中，Java 程式最初是通過直譯器（Interpreter）進行解釋執行的，當虛擬機發現某個方法或程式碼塊的執行特別頻繁時，就會把這些程式碼認定為“熱點程式碼” （Hot Spot Code）。為了提高熱點程式碼的執行效率，在執行時，虛擬機器將會把這些程式碼編譯成與本地平臺相關的機器碼，並進行各種層次的優化，完成這個任務的編譯器稱為即時編譯器（Just In Time Compiler，下文中簡稱 JIT 編譯器）。
即時編譯器並不是虛擬機器必需的部分，Java 虛擬機器規範並沒有規定 Java 虛擬機器內必需要有即時編譯器存在，更沒有限定或指導即時編譯器應該如何去實現。但是，即時編譯器編譯效能的好壞、程式碼優化程度的高低卻是衡量一款商用虛擬機器優秀與否的最關鍵指標之一，它也是虛擬機器內中最核心且最能體現虛擬機器技術水平的部分。在本章中，我們將走進虛擬機器的內部，探索即時編譯器的運作過程。
由於 Java 虛擬機器規範沒有具體的約束規則去限制即時編譯器應該如何實現，所以這部分功能完全是與虛擬機器具體實現（Implementation Specific）相關的內容，如無特殊說明，本章提及的編譯器、即時編譯器都是指 HotSpot 虛擬機器內部的即時編譯器，虛擬機器也是特指 HotSpot 虛擬機器。不過，本章的大部分內容是描述即時編譯器的行為，涉及編譯器實現層面的內容較少，而主流虛擬機器中即時編譯器的行為又有很多相似和想通之處，因此，對其他虛擬機器來說也具有較高的參考意義。
HotSpot 虛擬機器內的即時編譯器
在本節中，我們將要了解 HotSpot 虛擬機器內的即時編譯器的運作過程，同時，還要解決以下幾個問題：
- 為何 HotSpot 虛擬機器要使用直譯器與編譯器並存的架構？
- 為何 HotSpot 虛擬機器要實現兩個不同的即時編譯器？
- 程式何時使用直譯器執行？何時使用編譯器執行？
- 哪些程式程式碼會被編譯為原生代碼？如何編譯為原生代碼？
- 如何從外部觀察即時編譯器的編譯過程和編譯結果？
直譯器與編譯器
儘管並不是所有的 Java 虛擬機器都採用直譯器與編譯器並存的架構，但許多主流的商用虛擬機器，如 HotSpot、J9 等，都同時包含直譯器與編譯器。直譯器與編譯器兩者各有優勢：當程式需要迅速啟動和執行的時候，直譯器可以首先發揮作用，省去編譯的時間，立即執行。在程式執行後，隨著時間的推移，編譯器逐漸發揮作用，把越來越多的程式碼編譯成原生代碼之後，可以獲取更高的執行效率。當程式執行環境中記憶體資源限制較大（如部分嵌入式系統中），可以使用解釋執行節約記憶體，反之可以使用編譯執行來提升效率。同時，直譯器還可以作為編譯器激進優化時的一個
“逃生門”，讓編譯器根據概率選擇一些大多數時候都能提升執行速度的優化手段，當激進優化的假設不成立，如載入了新類後型別繼承結構出現變化、出現 “罕見陷阱”（Uncommon Trap）時可以通過逆優化（Deoptimization）退回到解釋狀態繼續執行（部分沒有直譯器的虛擬機器中也會採用不進行激進優化的 C1（注：
HotSpot 虛擬機器中內建了兩個即時編譯器、分別稱為 Client Compiler 和 Server Compiler 或者簡稱為 C1 編譯器和 C2 編譯器（也叫 Opto 編譯器）。目前主流的 HotSpot 虛擬機器（Sun 系列 JDK 1.7 及之前版本的虛擬機器）中，預設採用直譯器與其中一個編譯器直接配合的方式工作，程式使用哪個編譯器，取決於虛擬機器執行的模式，HotSpot 虛擬機器會根據自身版本與宿主機器的硬體效能自動選擇執行模式，使用者也可以使用 “-client” 或 “-server” 引數去強制指定虛擬機器執行在 Client 模式或 Server 模式。
無聊採用的編譯器是 Client Compiler 還是 Server Compiler，直譯器與編譯器搭配使用的方式在虛擬機器中成為 “混合模式” （Mixed Mode），使用者可以使用引數 “-Xint” 強制虛擬機器運行於 “解釋模式”（Interpreted Mode），這是編譯器完全不介入工作，全部程式碼都使用解釋方式執行。另外，也可以使用引數 “-Xcomp” 強制虛擬機器運行於 “編譯模式”（Compiled Mode），這時將優先採用編譯方式執行程式，但是直譯器仍然要在編譯無法進行的情況下介入執行過程，可以通過虛擬機器的 “-version” 命令的輸出結果顯示出這 3 種模式，如程式碼清單 11-1 所示，請注意黑體字部分。
C:\Users\mk>java -version
java version "1.7.0_60"
Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, <strong>mixed mode</strong>)
C:\Users\mk>java -Xint -version
java version "1.7.0_60"
Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, <strong>interpreted mode</strong>)
C:\Users\mk>java -Xcomp -version
java version "1.7.0_60"
Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, <strong>compiled mode</strong>)由於即時編譯器編譯原生代碼需要佔用程式執行時間，要編譯出優化程度更高的程式碼，所花費的時間可能更長：而且想要編譯出優化程度更高的程式碼，直譯器可能還要替編譯器收集效能監控資訊，這對解釋執行的速度也有影響。為了在程式啟動響應速度與執行效率之間達到最佳平衡，HotSpot 虛擬機器還會逐漸啟用分層編譯（Tiered Compilation）的策略，分層編譯的概念在 JDK 1.6 時期出現，後來一直處於改進階段，最終在 JDK 的 Server 模式虛擬機器中作為預設編譯策略被開啟。分層編譯根據編譯器編譯、優化的規模與耗時，劃分出不同的編譯層次，其中包括：
- 第 0 層，程式解釋執行，直譯器不開啟效能監控功能（Profiling），可觸發第 1 層編譯。
- 第 1 層，也稱為 C1 編譯，將位元組碼編譯為原生代碼，進行簡單、可靠的優化，如有必要將加入效能監控的邏輯。
- 第 2 層（或 2 層以上），一稱為 C2 編譯，也是將位元組碼編譯為原生代碼，但是會啟用一些編譯耗時較長的優化，甚至會根據效能監控資訊進行一些不可靠的激進優化。
實施分層編譯後，Client Compiler 和 Server Compiler 將會同時工作，許多程式碼都可能會被多次編譯，用 Client Compiler 獲取更高的編譯速度，用 Server Compiler 來獲取更高的編譯質量，在解釋執行的時候也無須再承擔收集效能監控資訊的任務。
編譯物件與觸發條件
上文中提到過，在執行過程中會被即時編譯器編譯的 “熱點程式碼” 有兩類，即：
- 被多次呼叫的方法。
- 被多次執行的迴圈體。
前者很好理解，一個方法被呼叫得多了，方法體內程式碼執行的次數自然就多，它成為 “熱點程式碼” 是理所當然的。而後者則為了解決一個方法只被呼叫過一次或少量的幾次，但是方法體內部存在迴圈次數較多的迴圈體內部存在迴圈次數較多的迴圈體的問題，這樣迴圈次數較多的迴圈體的問題，這樣迴圈體的程式碼也被重複執行多次，因此這些程式碼也應該認為是 “熱點程式碼”。
對於第一種情況，由於是由方法呼叫觸發的編譯，因此編譯器理所當然地會以整個方法作為編譯物件，這種編譯也是虛擬機器中標準的 JIT 編譯方式。而對於後一種情況，儘管編譯動作是由迴圈體所觸發的，但編譯器依然會以整個方法（而不是單獨的迴圈體）作為編譯物件。這種編譯方式因為編譯發生在方法執行過程之中，因此形象地稱之為棧上替換（On Stack Replacement，簡稱為 OSR 編譯，即方法棧幀還在棧上，方法就被替換了）。
讀者可能還會有疑問，在上面的文字描述中，無論是 “多次執行的方法”，還是 “多次執行的程式碼塊”，所謂 “多次” 都不是一個具體、嚴謹的用語，那到底多少次才算 “多次” 呢？還有一個問題，就是虛擬機器如何統計一個方法或一段程式碼被執行過多少次呢？解決了這兩個問題，也就回答了即時編譯被觸發的條件。
判斷一段程式碼是不是熱點程式碼，是不是需要觸發即時編譯，這樣的行為稱為熱點探測（Hot Spot Detection），其實進行熱點探測並不一定要知道方法具體被呼叫了多少次，目前主要的熱點探測判定方式有兩種（注：還有其他熱點程式碼的探測方式，如基於“蹤跡”（Trace）的熱點探測再最近相當流行，像 Firefox 中的 TraceMonkey 和 Dalvik 中新的 JIT 編譯器都用了這種熱點探測方式），分別如下。
- 基於取樣的熱點探測（Sample Based Hot Spot Detection）：採用這種方法的虛擬機器會週期性地檢查各個執行緒的棧頂，如果發現某個（或某些）方法經常出現在棧頂，那這個方法就是 “熱點方法”。基於取樣的熱點探測的好處是實現簡單、高效，還可以很容易地獲取方法呼叫關係（將呼叫堆疊展開即可），缺點是很難精確地確認一個方法的熱度，容易因為受到執行緒阻塞或別的外界因素的影響而擾亂熱點探測。
- 基於計數器的熱點探測（Counter Based Hot Spot Detection）：採用這種方法的虛擬機器會為每個方法（甚至是程式碼塊）建立計數器，統計方法的執行次數，如果執行次數超過一定的閾值就認為它是 “熱點方法”。這種統計方法實現起來麻煩一些，需要為每個方法建立並維護計數器，而且不能直接獲取到方法的呼叫關係，但是它的統計結果相對來說更加精確和嚴謹。
在 HotSpot 虛擬機器中使用的是第二種——基於計數器的熱點探測方法，因此它為每個方法準備了兩類計數器：方法呼叫計數器（Invocation Counter）和回邊計數器（Back Edge Counter）。
在確定虛擬機器執行引數的前提下，這兩個計數器都有一個確定的閾值，當計數器超過閾值溢位了，就會觸發 JIT 編譯。
我們首先來看看方法呼叫計數器。顧名思義，這個計數器就用於統計方法被呼叫的次數，它的預設閾值在 Client 模式下是 1500 此，在 Server 模式下是 10 000 次，這個閾值可以通過虛擬機器引數-XX：CompileThreshold來人為設定。當一個方法被呼叫時，會先檢查該方法是否存在被 JIT 編譯過的版本，如果存在，則優先使用編譯後的原生代碼來執行。如果不存在已被編譯過的版本，則將此方法的呼叫計數器值加 1，然後判斷方法呼叫計數器與回邊計數器值之和是否查過方法呼叫計數器的閾值。如果已超過閾值，那麼將會向即時編譯器提交一個該方法的程式碼編譯請求。
如果不做任何設定，執行引擎並不會同步等待編譯請求完成，而是繼續進入直譯器按照解釋方式執行位元組碼，直到提交的請求被編譯器編譯完成。當編譯工作完成之後，這個方法呼叫入口地址就會被系統自動改成新的，下一次呼叫該方法時就會使用已編譯的版本。整個 JIT 編譯的互動過程如圖 11-2 所示。
如果不做任何設定，方法呼叫計數器統計的並不是方法被呼叫的絕對次數，而是一個相對的執行頻率，即一段時間之內方法被呼叫的次數。當超過一定的時間限度，如果方法的呼叫次數仍然不足以讓它提交給即時編譯器編譯，那這個方法的呼叫計數器就會被減少一半，這個過程稱為方法呼叫計數器熱度的衰減（Counter Decay），而這段時間就稱為此方法統計的半衰週期（Counter Half Life Time）。進行熱度衰減的動作是在虛擬機器進行垃圾收集時順便進行的，可以使用虛擬機器引數 -XX: -UseCounterDecay 來關閉熱度衰減，讓方法計數器統計方法呼叫的絕對次數，這樣，只要系統執行時間足夠長，絕大部分方法都會被編譯成原生代碼。另外，可以使用 -XX: CounterHalfLifeTime 引數設定半衰週期的時間，單位是秒。
現在我們再來看看另一個計數器——回邊計數器，它的作用是統計一個方法中迴圈體程式碼執行的次數，在位元組碼中遇到控制流向後跳轉的指令稱為 “回邊”（Back Edge）。顯然，建立回邊計數器統計的目的就是為了觸發 OSR 編譯。
關於回邊計數器的閾值，雖然 HotSpot 虛擬機器也提供了一個類似於方法呼叫計數器閾值 -XX: CompileThreshold 的引數 -XX: BackEdgeThreashold 供使用者設定，但是當前的虛擬機器實際上並未使用此引數，因此我們需要設定另外一個引數-XX: OnStackReplacePercentage 來簡介調整回邊計數器的閾值，其計算公式如下。
- 虛擬機器執行在 Client 模式下，回邊計數器閾值計算公式為：
方法呼叫計數器閾值（CompileThreshold）× OSR 比率（OnStackReplacePercentage）/ 100
其中 OnStackReplacePercentage 預設值為 933，如果都取預設值，那 Client 模式虛擬機器的回邊計數器的閾值為 13995。
- 虛擬機器執行在 Server 模式下，回邊計數器閾值的計算公式為：
方法呼叫計數器閾值（CompileThreshold）× （OSR 比率（OnStackReplacePercentage）- 直譯器監控比率（InterpreterProfilePercentage）） / 100
其中 OnStackReplacePercentage 預設值為 140，InterpreterProfilePercentage 預設值為 33，如果都取預設值，那 Server 模式虛擬機器回邊計數器的閾值為 10700。
當直譯器遇到一條回邊指令時，會先查詢將要執行的程式碼片段是否有已經編譯好的版本，如果有，它將會有限執行已編譯的程式碼，否則就把回邊計數器的值加 1，然後判斷方法呼叫計數器與回邊計數器之和是否超過回邊計數器的閾值。當超過閾值的時候，將會提交一個 OSR 編譯請求，並且把回邊計數器的值降低一些，以便繼續在直譯器中執行迴圈，等待編譯器輸出編譯結果，整個執行過程如圖 11-3 所示。
與方法計數器不同，回邊計數器沒有計數熱度衰減的過程，因此這個計數器統計的就是該方法迴圈執行的絕對次數。當計數器溢位的時候，它還會把方法計數器的值也調整到溢位狀態，這樣下次再進入該方法的時候就會執行標準編譯過程。
最後需要提醒一點，圖 11-2 和 圖 11-3 都僅僅描述了 Client VM 的即時編譯方式，對於 Server VM 來說，執行情況會比上面的描述更復雜一些。從理論上了解過編譯物件和編譯觸發條件後，我們再從 HotSpot 虛擬機器的原始碼中觀察一下，在 MethodOop.hpp（一個 methodOop 物件代表了一個 Java 方法）中，定義了 Java 方法在虛擬機器中的記憶體佈局，如下所示：
// |------------------------------------------------------|
// | header |
// | klass |
// |------------------------------------------------------|
// | constMethodOop (oop) |
// |------------------------------------------------------|
// | methodData (oop) |
// | interp_invocation_count |
// |------------------------------------------------------|
// | access_flags |
// | vtable_index |
// |------------------------------------------------------|
// | result_index (C++ interpreter only) |
// |------------------------------------------------------|
// | method_size | max_stack |
// | max_locals | size_of_parameters |
// |------------------------------------------------------|
// |intrinsic_id| flags | throwout_count |
// |------------------------------------------------------|
// | num_breakpoints | (unused) |
// |------------------------------------------------------|
// | <strong>invocation_counter</strong> |
// | <strong>backedge_counter</strong> |
// |------------------------------------------------------|
// | prev_time (tiered only, 64 bit wide) |
// | |
// |------------------------------------------------------|
// | rate (tiered) |
// |------------------------------------------------------|
// | code (pointer) |
// | i2i (pointer) |
// | adapter (pointer) |
// | <strong>from_compiled_entry</strong> (pointer) |
// | <strong>from_interpreted_entry</strong> (pointer) |
// |------------------------------------------------------|
// | native_function (present only if native) |
// | signature_handler (present only if native) |
// |------------------------------------------------------|
在這個記憶體佈局中，一行長度為 32 bit，從中可以清楚地看到方法呼叫計數器和回邊計數器所在的位置和長度。還有 from_compiled_entry 和 from_interpreted_entry 這兩個方法的入口。
編譯過程
在預設設定下，無論是方法呼叫產生的即時編譯請求，還是 OSR 編譯請求，虛擬機器在程式碼編譯器還未完成之前，都仍然將按照解釋方式繼續執行，而編譯動作則在後臺的編譯執行緒中進行。使用者可以通過引數 -XX: -BackgroundCompilation 來禁止後臺編譯，在禁止後臺編譯後，一旦達到 JIT 的編譯條件，執行執行緒向虛擬機器提交編譯請求後將會一直等待，知道編譯過程完成後再開始執行編譯器輸出的原生代碼。
那麼在後臺執行編譯的過程中，編譯器做了什麼事情呢？Server Compiler 和 Client Compiler 兩個編譯器的編譯過程是不一樣的。對於 Client Compiler 來說，它是一個簡單快速的一段式編譯器，主要的關注點在於區域性性的優化，而放棄了許多耗時較長的全域性優化手段。
在第一個階段，一個平臺獨立的前端將位元組碼構造成一種高階中間程式碼表示（High-Level Intermediate Representation，HIR）。HIR 使用靜態單分配（Static Single Assignment，SSA）的形式來代表程式碼值，這可以使得一些在 HIR 的構造過程之中和之後進行的優化動作更容易實現。在此之前編譯器會在位元組碼上完成一部分基礎優化，如方法內聯、常量傳播等優化將會在位元組碼被構造成 HIR 之前完成。
在第二個階段，一個平臺相關的後端從 HIR 中產生低階中間程式碼表示（Low-Level Intermediate Representation，LIR），而在此之前會在 HIR 上完成另外一些優化，如空值檢查消除、範圍檢查消除等，以便讓 HIR 達到更高效的程式碼表示形式。
最後階段是在平臺相關的後端使用線性掃描演算法（Linear Scan Register Allocation）在 LIR 上分配暫存器，並在 LIR 上做窺孔（Peephole）優化，然後產生機器程式碼。Client Compiler 的大致執行過程如圖 11-4 所示。
而 Server Compiler 則是專門面向服務端的典型應用併為服務端的效能配置特別調整過的編譯器，也是一個充分優化過的高階編譯器，幾乎能達到 GNU C++ 編譯器使用 -O2 引數時的優化強度，它會執行所有經典的優化動作，如無用程式碼消除（Dead Code Elimination）、迴圈展開（Loop Unrolling）、迴圈表示式外提（Loop Expression Hoisting）、消除公共子表示式（Common Subexpression Elimination）、常量傳播（Constant Propagation）、基本塊重排序（Basic Block Reordering）等，還會實施一些與 Java 語言特性密切相關的優化技術，如範圍檢查消除（Range Check Elimination）、空值檢查消除（Null Check Elimination，不過並非所有的控制檢查消除都是依賴編譯器優化的，有一些是在程式碼執行過程中自動優化了）等。另外，還可能根據直譯器或 Client Compiler 提供的效能監控資訊，進行一些不穩定的激進優化，如守護內聯（Guarded Inlining）、分支頻率預測（Branch Frequency Prediction）等。本章的下半部分將會挑選上述的一部分優化手段進行分析和講解。
Server Compiler 的暫存器分配器是一個全域性圖著色分配器，它可以充分利用某些處理器架構（如 RISC）上的大暫存器集合。以即時編譯的標準來看，Server Compiler 無疑是比較緩慢的，但它的編譯速度依然遠遠超過傳統的靜態優化編譯器，而且它相對於 Client Compiler 編譯輸出的程式碼質量有所提高，可以減少原生代碼的執行時間，從而抵消了額外的編譯時間開銷，所以也有很多非服務端的應用選擇使用 Server 模式的虛擬機器執行。
在本節中，涉及了許多編譯原理和程式碼優化中的概念名詞，沒有這方面基礎的讀者，閱讀起來會感覺到抽象和理論化。有這種感覺並不奇怪，JIT 編譯過程本來就是一個虛擬機器中最體現技術水平也是醉複雜的部分，不可能一較短的篇幅就介紹得很詳細，另外，這個過程對 Java 開發來說是透明的，程式設計師平時無法感知它的存在，還好 HotSpot 虛擬機器提供了兩個視覺化的工具，讓我們可以 “看見” JIT 編譯器的優化過程，在稍後筆者將演示這個過程。
檢視及分析即時編譯結果
一般來說，虛擬機器的即時編譯過程對使用者程式是完成透明的，虛擬機器通過解釋執行程式碼還是編譯執行程式碼，對於使用者來說並沒有什麼影響（執行結果沒有影響，速度上會有很大差別）。在大多數情況下使用者也沒有必要知道。但是虛擬機器也提供了一些引數用來輸出即時編譯和某些優化手段（如方法內聯）的執行狀況，本節將介紹如何從外部觀察虛擬機器的即時編譯行為。
本節中提到的執行引數有一部分需要 Debug 或 FastDebug 版虛擬機器的支援，Product 版的虛擬機器無法使用這部分引數。如果讀者使用的是根據本書第 1 章的內容自己編譯的 JDK，注意將 SKIP_DEBUG_BUILD 或 SKIP_FASTDEBUG_BUILD 引數設定為 false，也可以在 OpenJDK 網站上直接下載 FastDebug 班的 JDK（從 JDK 6u25 之後 Oracle 官網就不再提供 FastDebug 的 JDK 下載了）。注意，本節中所有的測試都基於程式碼清單 11-2 所示的 Java 程式碼。
程式碼清單 11-2 測試程式碼
public static final int NUM = 15000;
public static int doubleValue(int i) {
// 這個空迴圈用於後面演示 JIT 程式碼優化過程
for (int j = 0; j < 100000; j++);
return i * 2;
}
public static long calcSum() {
long sum = 0;
for (int i = 1; i <= 100; i++) {
sum += doubleValue(i);
}
return sum;
}
public static void main(String[] args) {
for (int i = 0; i < NUM; i++) {
calcSum();
}
}首先執行這段程式碼，並且確認這段程式碼是否觸發了即時編譯，要知道某個方法是否被編譯過，可以使用引數 -XX: +PrintCompilation要求虛擬機器在即時編譯時將被編譯成原生代碼的方法名稱打印出來，如程式碼清單 11-3 所示（其中帶有 “%” 的輸出說明是由回邊計數器觸發的 OSR 編譯）。
程式碼清單 11-3 被即時編譯的程式碼
VM option'+PrintCompilation'
310 1 java.lang.String：charAt（33 bytes）
329 2 org.fenixsoft.jit.Test：calcSum（26 bytes）
329 3 org.fenixsoft.jit.Test：doubleValue（4 bytes）
332 1%org.fenixsoft.jit.Test：main@5（20 bytes）從程式碼清單 11-3 輸出的確認資訊中可以確認 main()、calcSum() 和 doubleValue() 方法已經被編譯，我們還可以加上引數 -XX: +PrintInlinint 要求虛擬機器輸出方法內聯資訊，如程式碼清單 11-4 所示。
程式碼清單 11-4 內聯資訊
VM option'+PrintCompilation'
VM option'+PrintInlining'
273 1 java.lang.String：charAt（33 bytes）
291 2 org.fenixsoft.jit.Test：calcSum（26 bytes）
@9 org.fenixsoft.jit.Test：doubleValue inline（hot）
294 3 org.fenixsoft.jit.Test：doubleValue（4 bytes）
295 1%org.fenixsoft.jit.Test：main@5（20 bytes）
@5 org.fenixsoft.jit.Test：calcSum inline（hot）
@9 org.fenixsoft.jit.Test：doubleValue inline（hot）從程式碼清單 11-4 的輸出中可以看到方法 doubleValue() 被內聯編譯到 calcSum() 中，而 calcSum() 又被內聯到方法 main() 中，所以虛擬機器再次執行 main() 方法的時候（舉例而已，main() 方法並不會執行兩次），calcSum() 和 doubleValue() 方法都不會再被呼叫，它們的程式碼邏輯都被直接內聯到 main() 方法中了。
編譯優化技術
Java 程式設計師有一個共識，以編譯方式執行原生代碼比解釋方式更快，之所以有這樣的共識，除去虛擬機器解釋執行位元組碼時額外消耗時間的原因外，還有一個很重要的原因就是虛擬機器設計團隊幾乎把對程式碼的所有優化措施都集中在了即時編譯器之中（在 JDK 1.3 之後，javac 就去除了 -O 選項，不會生成任何位元組碼級別的優化程式碼了）。因此一般來說，即時編譯器產生的原生代碼會比 javac 產生的位元組碼更加優秀。下面，筆者將介紹一些 HotSpot 虛擬機器的即時編譯器在生成程式碼時採用的程式碼優化技術。
優化技術概覽
在 Sun 官方的 Wiki 上，HotSpot 虛擬機器設計團隊列出了一個相對比較全面的、在即時編譯器中採用的優化技術列表（見表 11-1），其中有不少經典編譯器的優化手段，也有許多針對 Java 語言（準確地說是針對執行在 Java 虛擬機器上的所有語言）本身進行的優化技術，本節將對這些技術進行概括性的介紹，在後面幾節中，再挑選若干重要且典型的優化，與讀者一起看看優化前後的程式碼產生了怎樣的變化。
上述的優化技術看起來很多，而且從名字看都顯得有點 “高深莫測”，雖然實現這些優化也許確實有些難度，但大部分技術理解起來都並不困難。為了消除讀者對這些優化技術的陌生感，筆者舉一個簡單的例子，即通過大家熟悉的 Java 程式碼變化來展示其中幾種優化技術是如何發揮作用的（僅適用 Java 程式碼來表示而已）。首先從原始程式碼開始，如程式碼清單 11-6 所示。
程式碼清單 11-6 優化前的原始程式碼
static class B{
int value;
final int get() {
return value;
}
}
public void foo() {
y = b.get();
// ...do stuff...
z = b.get();
sum = y + z;
} 首先需要明確的是，這些程式碼優化變換是建立在程式碼的某種中間表示或機器碼之上的，絕不是建立在Java
原始碼之上的，為了展示方便，筆者使用了 Java 語言的語法來表示這些優化技術所發揮的作用。
程式碼清單11-6 的程式碼已經非常簡單了，但是仍然有許多優化的餘地。第一步進行方法內聯（Method Inlining），方法內聯的重要性要高於其他優化措施，它的主要目的有兩個，一是去除方法呼叫的成本（如建立棧幀等）。二是為其他優化建立良好的基礎，方法內聯膨脹之後可以便於在更大範圍上採取後續的優化手段，從而獲取更好的優化效果。因此，各種編譯器一般都會把內聯優化放在優化序列的最靠前位置。內聯後的程式碼如程式碼清單 11-7 所示。
程式碼清單 11-7 內聯後的程式碼
public void foo() {
y = b.value;
// ...do stuff...
z = b.value;
sum = y + z;
}第二步進行冗餘訪問消除（Redundant Loads Elimination），假設程式碼中間註釋掉的 “do stuff...” 所代表的操作不會改變 b.value 的值，那就可以把 “z = b.value” 替換為 “z = y”，因為上一句 “y = b.value” 已經保證了變數 y 與 b.value 是一致的，這樣就可以不再去訪問物件 b 的區域性變量了。如果把 b.value 看做是一個表示式，那也可以把這項優化看成是公共子表示式消除（Common Subexpression Elimination），優化後的程式碼如程式碼清單 11-8 所示。
程式碼清單 11-8 冗餘儲存消除的程式碼
public void foo() {
y = b.value;
// ...do stuff...
z = y;
sum = y + z;
}第三步我們進行複寫傳播（Copy Propagation），因為在這段程式的邏輯中並沒有必要使用一個額外的變數 “z”，它與變數 “y” 是完全相等的，因此可以使用 “y” 來代替 “z”。複寫傳播之後程式如程式碼清單 11-9 所示。
程式碼清單 11-9 複寫傳播的程式碼
public void foo() {
y = b.value;
// ...do stuff...
y = y;
sum = y + y;
}第四步我們進行無用程式碼消除（Dead Code Elimination）。無用程式碼可能是永遠不會被執行的程式碼，也可能是完全沒有意義的程式碼，因此，它又形象地稱為 “Dead Code”，在程式碼清單 11-9 中，“y = y” 是沒有意義的，把它消除後的程式如程式碼清單 11-10 所示。
程式碼清單 11-10 進行無用程式碼消除的程式碼
public void foo() {
y = b.value;
// ...do stuff...
sum = y + y;
}經過四次優化之後，程式碼清單 11-10 與程式碼清單 11-6 所達到的效果是一致的，但是前者比後者省略了許多語句（體現在位元組碼和機器碼指令上的差距會更大），執行效率也會更高。編譯器的這些優化技術實現起來也許比較複雜，但是要理解它們的行為對於一個普通的程式設計師來說是沒有困難的，接下來，我們將繼續檢視如下的幾項最有代表性的優化技術是如何運作的，它們分別是：
- 語言無關的經典優化技術之一：公共子表示式消除。
- 語言相關的經典優化技術之一：陣列範圍檢查消除。
- 最重要的優化技術之一：方法內聯。
- 最前沿的優化技術之一：逃逸分析。
公共子表示式消除
公共子表示式消除是一個普遍應用於各種編譯器的經典優化技術，它的含義是：如果一個表示式 E 已經計算過了，並且從先前的計算到現在 E 中所有變數的值都沒有發生變化，那麼 E 的這次出現就成為了公共子表示式。對於這種表示式，沒有必要花時間再對它進行計算，只需要直接用前面計算過的表示式結果代替 E 就可以了。如果這種優化僅限於程式的基本塊內，便稱為區域性公共子表示式消除（Local Common Subexpression Elimination），如果這種優化的範圍涵蓋了多個基本塊，那就稱為全域性公共子表示式消除（Global Common Subexpression Elimination）。舉個簡單的例子來說明它的優化過程，假設存在如下程式碼：
int d = (c * b) * 12 + a + (a + b * c);如果這段程式碼交給 Javac 編譯器則不會進行任何優化，那生成的程式碼將如程式碼清單 11-11 所示，是完全遵照 Java 原始碼的寫法直譯而成的。
程式碼清單 11-11 未做任何優化的位元組碼
iload_2 // b
imul // 計算b * c
bipush 12 // 推入12
imul // 計算（c * b）*12
iload_1 // a
iadd // 計算（c * b）*12+a
iload_1 // a
iload_2 // b
iload_3 // c
imul // 計算b * c
iadd // 計算a+b * c
iadd // 計算（c * b）*12+a+（a+b * c）
istore 4當這段程式碼進入到虛擬機器即時編譯器後，它將進行如下優化：編譯器檢測到 “c*b” 與 “b*c” 是一樣的表示式，而且在計算期間 b 與 c 的值是不變的。因此，這條表示式就可能被視為：
int d = E * 12 + a + (a + E);這時，編譯器還可能（取決於那種虛擬機器的編譯器以及具體的上下文而定）進行另外一種優化：代數化簡（Algebraic Simplification），把表示式變為：
int d = E * 13 + a * 2;表示式進行變換之後，再計算起來就可以節省一些時間了。如果讀者還對其他的經典編譯優化技術感興趣，可以參考《編譯原理》（俗稱 “龍書”，推薦使用 Java 的程式設計師閱讀 2006 年版的 “紫龍書”）中的相關章節。
陣列邊界檢查消除
陣列邊界檢查消除（Array Bounds Checking Elimination）是即時編譯器中的一項語言相關的經典優化技術。我們知道 Java 語言是一門動態安全的語言，對陣列的讀寫訪問也不像 C、C++ 那樣在本質上是裸指標操作。如果有一個數組 foo[]，在 Java 語言中訪問陣列元素 foo[i] 的時候系統將會自動進行上下界的範圍檢查，即檢查 i 必須滿足 i >= 0 && i < foo.length 這個條件，否則將會丟擲一個執行時異常：java.lang.ArrayIndexOutOfBoundsException。這對軟體開發者來說是一件很好的事情，即使程式設計師沒有專門編寫防禦程式碼，也可以避免大部分的溢位攻擊。但是對於虛擬機器的執行子系統來說，每次陣列元素的讀寫都帶有一次隱含的條件判定操作，對於擁有大量陣列訪問的程式程式碼，這無疑也是一種效能負擔。
無論如何，為了安全，陣列邊界檢查肯定是必須做的，但陣列邊界是不是必須在執行期間一次不漏地檢查則是可以 “商量” 的事情。例如下面這個簡單的情況：陣列下標是一個常量，如 foo[3]，只要在編譯期根據陣列流分析來確定 foo.length 的值，並判斷下標 “3” 沒有越界，執行的時候就無須判斷了。更加常見的情況是陣列訪問發生在迴圈之中，並且使用迴圈遍歷來進行陣列訪問，如果編譯器只要通過資料流分析就可以判定迴圈變數的取值範圍永遠在區間[0, foo.length)之內，那在整個迴圈中就可以把陣列的上下界檢查消除，這可以節省很多次的條件判斷操作。
將這個陣列邊界檢查的例子放在更高的角度來看，大量的安全檢查令編寫 Java 程式比編寫 C/C++ 程式容易很多，如陣列越界會得到 ArrayIndexOutOfBoundsException 異常，空指標訪問會得到 NullPointException，除數為零會得到 ArithmeticException 等，在 C/C++ 程式中出現類似的問題，一不小心就會出現 Segment Fault 訊號或者 Windows 程式設計中常見的 “xxx 記憶體不能為 Read/Wrie” 之類的提示，處理不好程式就和直接崩潰退出了。但這些安全檢查也導致了相同的程式，Java 要比 C/C++ 做更多的事情（各種檢查判斷），這些事情就成為一種隱式開銷，除了如陣列邊界檢查優化這種儘可能把執行期檢查提到編譯期完成的思路之外，另外還有一種避免思路——隱式異常處理，Java 中空指標檢查和算術運算中除數為零的檢查都採用了這種思路。舉個例子，例如程式中訪問一個物件（假設物件叫 foo）的某個屬性（假設屬性叫 value），那以 Java 虛擬碼來表示虛擬機器訪問 foo.value 的過程如下。
if (foo != null) {
return foo.value;
else {
throw new NullPointException();
}在使用隱式異常優化之後，虛擬機器會把上面虛擬碼所表示的訪問過程變為如下虛擬碼。
try {
return foo.value;
} catch (segment_fault) {
uncommon_trap();
}虛擬機器會註冊一個 Segment Fault 訊號的異常處理器（虛擬碼中的 uncommon_trap()），這樣當 foo 不為空的時候，對 value 的訪問是不會額外消耗一次對 foo 判空的開銷的。代價就是當 foo 真的為空時，必須轉入到異常處理器中恢復並丟擲 NullPointException 異常，這個過程必須從使用者態轉到核心態中處理，結束後再回到使用者態，速度遠比一次判空檢查慢。當 foo 極少為空的時候，隱式異常優化是值得的，但假如 foo 經常為空的話，這樣的優化反而會讓程式更慢，還好 HotSpot 虛擬機器足夠 “聰明”，它會根據執行期收集到的 Profile 資訊自動選擇最優方案。
與語言相關的其他消除操作還有不少，如自動裝箱消除（Autobox Elimination）、安全點消除（Safepoint Elimination）、消除反射（Dereflection）等，筆者就不再一一介紹了。
方法內聯
在前面的講解之中我們提到過方法內聯，它是編譯器最重要的優化手段之一，除了消除方法呼叫的成本之外，它更重要的意義是為其他優化手段建立良好的基礎，如程式碼清單 11-12 所示的簡單例子就揭示了內聯對其他優化手段的意義：事實上 testInline() 方法的內部全部都是無用的程式碼，如果不做內聯，後續即使進行了無用程式碼消除的優化，也無法發現任何 “Dead Code”，因為如果分開來看，foo() 和 testInline() 兩個方法裡面的操作都可能是有意義的。
程式碼清單 11-12 未做任何優化的位元組碼
public static void foo (Object obj) {
if (obj != null) {
System.out.println("do something");
}
}
public static void testInline(String[]args) {
Object obj = null;
foo (obj);
}方法內聯的優化行為看起來很簡單，不過是把目標方法的程式碼 “複製” 到發起呼叫的方法之中，避免發生真實的方法呼叫而已。但實際上 Java 虛擬機器中的內聯過程遠遠沒有那麼簡單，因為如果不是即時編譯器做了一些特別的努力，按照經典編譯原理的優化理論，大多數的 Java 方法都無法進行內聯。
無法內聯的原因其實在《虛擬機器位元組碼執行引擎》中講解 Java 方法解析和分派呼叫的時候就已經介紹過。只有使用 invokespecial 指令呼叫的私有方法、例項構造器、父類方法以及使用invokestatic 指令進行呼叫的靜態方法才是在編譯期進行解析的，除了上述 4 種方法之外，其他的 Java 方法呼叫都需要在執行時進行方法接收者的多型選擇，並且都可能存在多於一個版本的方法接收者（最多再除去被 final 修飾的方法這種特殊情況，儘管它使用 invokevirtual 指令呼叫，但也是非虛方法，Java 語言規範中明確說明了這點），簡而言之，Java 語言中預設的例項方法是虛方法。
對於一個虛方法，編譯期做內聯的時候根本就無法確定應該使用哪個方法版本，如果以程式碼清單 11-7 中把 “b.get()” 內聯為 “b.value” 為例的話，就是不依賴上下文就無法確定 b 的實際型別是什麼。假如有 ParentB 和 SubB 兩個具有繼承關係的類，並且子類重寫了父類的 get() 方法，那麼，是要執行父類的 get() 方法還是子類的 get() 方法，需要在執行期才能確定，編譯期無法得出結論。
由於 Java 語言提倡使用面向物件的程式設計方式進行程式設計，而 Java 物件的方法預設就是虛方法，因此 Java 間接鼓勵了程式設計師使用大量的虛方法來完成程式邏輯。根據上面的分析，如果內聯與虛方法之間產生 “矛盾”，那該怎麼辦呢？是不是為了提高執行效能，就要到處使用 final 關鍵字去修飾方法呢？
為了解決虛方法的內聯問題，Java 虛擬機器設計團隊想了很多辦法，首先是引入了一種名為 “型別繼承關係分析”（Class Hierarchy Analysis，CHA）的技術，這是一種基於整個應用程式的型別分析技術，它用於確定在目前已載入的類中，某個介面是否有多於一種的實現，某個類是否存在子類、子類是否為抽象類等資訊。
編譯器在進行內聯時，如果是非虛方法，那麼直接進行內聯就可以了，這時候的內聯是有穩定前提保障的。如果遇到虛方法，則會向 CHA 查詢此方法在當前程式下是否有多個目標版本可供選擇，如果查詢結果只有一個版本，那也可以進行內聯，不過這種內聯就屬於激進優化，需要預留一個 “逃生門”（Guard 條件不成立時的 Slow Path），稱為守護內聯（Guarded Inlining）。如果程式的後續執行過程中，虛擬機器一直沒有載入到會令這個方法的接收者的繼承關係發生變化的類，那這個內聯優化的程式碼就可以一直使用下去。但如果載入了導致繼承關係發生變化的新類，那就需要拋棄已經編譯的程式碼，退回到解釋狀態執行，或者重新進行編譯。
如果向 CHA 查詢出來的結果是多個版本的目標方法可供選擇，則編譯器還將會進行最後一次努力，使用內聯快取（Inline Cache）來完成方法內聯，這是一個建立在目標方法正常入口之前的快取，它的工作原理大致是：在未發生方法呼叫之前，內聯快取狀態為空，當第一次呼叫發生後，快取記錄下方法接收者的版本資訊，並且每次進行方法呼叫時都比較接收者版本，如果以後進來的每次呼叫的方法接收者版本都是一樣的，那這個內聯還可以一直用下去。如果發生了方法接收者不一致的情況，就說明程式真正使用了虛方法的多型特性，這時才會取消內聯，查詢虛方法表進行方法分派。
所以說，在許多情況下虛擬機器進行的內聯都是一種激進優化，激進優化的手段在高效能的商用虛擬機器中很常見，除了內聯之外，對於出現概率很小（通過經驗資料或直譯器收集到的效能監控資訊確定概率大小）的隱式異常、使用概率很小的分支等都可以被激進優化 “移除”，如果真的出現了小概率事件，這時才會從 “逃生門” 回到解釋狀態重新執行。
逃逸分析
逃逸分析（Escape Analysis）是目前 Java 虛擬機器中比較前沿的優化技術，它與型別繼承關係分析一樣，並不是直接優化程式碼的手段，而是為其他優化手段提供依據的分析技術。
逃逸分析的基本行為就是分析物件動態作用域：當一個物件在方法中被定義後，它可能被外部方法所引用，例如作為呼叫引數傳遞到其他方法中，稱為方法逃逸。甚至還有可能被外部執行緒訪問到，譬如賦值給類變數或可以在其他執行緒中訪問的例項變數，稱為執行緒逃逸。
如果能證明一個物件不會逃逸到方法或執行緒之外，也就是別的方法或執行緒無法通過任何途徑訪問到這個物件，則可能為這個變數進行一些高效的優化，如下所示。
- 棧上分配（Stack Allocation）：Java 虛擬機器中，在 Java 堆上分配建立物件的記憶體空間幾乎是 Java 程式設計師都清楚的常識了，Java 堆中的物件對於各個執行緒都是共享和可見的，只要持有這個物件的引用，就可以訪問堆中儲存的物件資料。虛擬機器的垃圾收集系統可以回收堆中不再使用的物件，但回收動作無論是篩選可回收物件，還是回收和整理記憶體都需要耗費時間。如果確定一個物件不會逃逸出方法之外，那讓這個物件在棧上分配記憶體將會是一個很不錯的注意，物件所佔用的記憶體空間就可以隨棧幀出棧而銷燬。在一般應用中，不會逃逸的區域性物件所佔的比例很大，如果能使用棧上分配，那大量的物件就會隨著方法的結束而自動銷燬了，垃圾收集系統的壓力將會小很多。
- 同步消除（Synchronized Elimination）：執行緒同步本身是一個相對耗時的過程，如果逃逸分析能夠確定一個變數不會逃逸出執行緒，無法被其他執行緒訪問，那這個變數的讀寫肯定就不會有競爭，對這個變數實施的同步措施也就可以消除掉。
- 標量替換（Scalar Replacement）：標量（Scalar）是指一個數據已經無法再分解成更小的資料來表示了，Java 虛擬機器中的原始資料型別（int、long 等數值型別以及 reference 型別等）都不能再進一步分解，它們就可以稱為標量。相對的，如果一個數據可以繼續分解，那它就稱作聚合量（Aggregate），Java 中的物件就是最典型的聚合量。如果把一個 Java 物件拆散，根據程式訪問的情況，將其使用到的成員變數恢復原始型別來訪問就叫做標量替換。如果逃逸分析證明一個物件不會被外部訪問，並且這個物件可以被拆散的話，那程式真正執行的時候將可能不建立這個物件，而改為直接建立它的若干個被這個方法使用到的成員變數來代替。將物件拆分後，除了可以讓物件的成員變數在棧上（棧上儲存的資料，有很大的概率會被虛擬機器分配至物理機器的告訴暫存器中儲存）分配和讀寫之外，還可以為後續進一步的優化手段建立條件。
關於逃逸分析的論文在 1999 年就已經發表，但直到 Sun JDK 1.6 才實現了逃逸分析，而且直到現在這項優化尚未足夠成熟，仍有很大的改進餘地。不成熟的原因主要是不能保證逃逸分析的效能收益必定高於它的消耗。如果要完全準確地判斷一個物件是否會逃逸，需要進行資料流敏感的一系列複雜分析，從而確定程式各個分支執行時對此物件的影響。這是一個相對高耗時的過程，如果分析完後發現沒有幾個不逃逸的物件，那這些執行期耗用的時間久白白浪費了，所以目前虛擬機器只能採用不那麼準確，但時間壓力相對較小的演算法來完成逃逸分析。還有一點是，基於逃逸分析的一些優化手段，如上面提到的 “棧上分配”，由於 HotSpot 虛擬機器目前的實現方式導致棧上分配實現起來比較複雜，因此在 HotSpot 中暫時還沒有做這項優化。
在測試結果中，實施逃逸分析後的程式在 MicroBenchmarks 中往往能執行出不錯的成績，但是在實際的應用程式，尤其是大型程式中反而發現實施逃逸分析可能出現效果不穩定的情況，或因分析過程耗時但卻無法有效判別出非逃逸物件而導致效能（即時編譯的收益）有所下降，所以在很長的一段時間裡，即時是 Server Compiler，也預設不開啟逃逸分析，甚至在某些版本（如 JDK 1.6 Update 18）中還曾經短暫地完全禁止了這項優化。
如果有需要，並且確認對程式執行有益，使用者可以使用引數 -XX: +DoEscapeAnalysis 來手動開啟逃逸分析，開啟之後可以通過引數 -XX: +PrintEscapeAnalysis 來檢視分析結果。有了逃逸分析支援之後，使用者可以使用引數 -XX: +EliminateAllocations 來開啟標量替換，使用+XX: +EliminateLocks 來開啟同步消除，使用引數-XX: +PrintEliminateAllocations 來檢視標量的替換情況。
儘管目前逃逸分析的技術仍不失十分成熟，但是它卻是即時編譯器優化技術的一個重要發展方向，在今後的虛擬機器中，逃逸分析技術肯定會支撐起一系列實用有效的優化技術。
Java 與 C/C++ 的編譯器對比
大多數程式設計師都認為 C/C++ 會比 Java 語言塊，甚至覺得從 Java 語言誕生以來 “執行速度緩慢” 的帽子就應當扣在它的頭頂，這種觀點的出現是由於 Java 剛出現的時候即時編譯技術還不成熟，主要靠直譯器執行的 Java 語言效能確實比較低下。但目前即時編譯技術已經十分成熟，Java 語言有可能在速度上與 C/C++ 一爭高下嗎？要想知道這個問題的答案，讓我們從兩者的編譯器談起。
Java 與 C/C++ 的編譯器對比實際上代表了最經典的即時編譯器與靜態編譯器的對比，很大程度上也決定了 Java 與 C/C++ 的效能對比的結果，因為無論是 C/C++ 還是 Java 程式碼，最終編譯之後被機器執行的都是本地機器碼，哪種語言的效能更高，除了它們自身的 API 庫實現得好壞以外，其餘的比較就成了一場 “拼編譯器” 和 “拼輸出程式碼質量” 的遊戲。當然，這種比較也是剔除了開發效率的片面對比，語言間孰優孰劣、誰塊誰慢的問題都是很難有結果的爭論，下面我們就回到正題，看看這兩種語言的編譯器各有何種優勢。
Java 虛擬機器的即時編譯器與 C/C++ 的靜態優化編譯器相比，可能會由於下列這些原因而導致輸出的原生代碼有一些劣勢（下面列舉的也包括一些虛擬機器執行子系統的效能劣勢）：
第一，因為即時編譯器執行佔用的是使用者程式的執行時間，具有很大的時間壓力，它能提供的優化手段也嚴重受制於編譯成本。如果編譯速度不能達到要求，那使用者將在啟動程式或程式的某部分察覺到重大延遲，這點使得即時編譯器不敢隨便引入大規模的優化技術，而編譯的時間成本在靜態優化編譯器中並不是主要的關注點。
第二，Java 語言是動態的型別安全語言，這就意味著需要由虛擬機器來確保程式不會違反語言語義或訪問非結構化記憶體。從實現層面上看，這就意味著虛擬機器必須頻繁地進行動態檢查，如例項方法訪問時檢測空指標、陣列元素訪問時檢測上下文範圍、型別轉換時檢測繼承關係等。對於這類程式程式碼沒有明確寫出的檢查行為，儘管編譯器會努力進行優化，但是總體上仍然要消耗不少的執行時間。
第三，Java 語言中雖然沒有 virtual 關鍵字，但是使用虛方法的頻率卻遠遠大於 C/C++ 語言，這意味著執行時對方法接收者進行多型選擇的頻率要遠遠大於 C/C++ 語言，也意味著即時編譯在進行一些優化（如前面提到的方法內聯）時的難度要遠大於 C/C++ 的靜態優化編譯器。
第四，Java 語言是可以動態擴充套件的語言，執行時載入新的類可能改變程式型別的繼承關係，這使得很多全域性的優化都難以進行，因為編譯器無法看見程式的全貌，許多全域性的優化措施都只能以激進優化的方式來完成，編譯器不得不時刻注意並隨著型別的變化而在執行時撤銷或重新進行一些優化。
第五，Java 語言中物件的記憶體分配都是堆上進行的，只有方法中的區域性變數才能在棧上分配。而 C/C++ 的物件則有多種記憶體分配方式，既可能在堆上分配，又可能在棧上分配，如果可以在棧上分配執行緒私有的物件，將減輕記憶體回收的壓力。另外，C/C++ 中主要由使用者程式程式碼來回收分配的記憶體，這就不存在無用物件篩選的過程，因此效率上（僅指執行效率，排除了開發效率）也比垃圾收集機制要高。
上面說了一大堆 Java 語言相對 C/C++ 的劣勢，不是說 Java 就真的不如 C/C++ 了，相信讀者也注意到了，Java 語言的這些效能上的劣勢都是為了換取開發效率上的優勢而付出的代價，動態安全、動態擴充套件、垃圾回收這些 “拖後腿” 的特性都是為 Java 語言的開發效率做出了很大貢獻。
何況，還有許多優化是 Java 的即時編譯器能做而 C/C++ 的靜態優化編譯器不能做或者不好做的。例如，在 C/C++ 中，別名分析（Alias Analysis）的難度就要遠高於 Java。Java 的型別安全保證了在類似如下程式碼中，只要 ClassA 和 ClassB 沒有繼承關係，那物件 objA 和 objB 就絕不可能是同一個物件，即不會是同一塊記憶體兩個不同別名。
void foo(ClassA objA, ClassB objB) {
objA.x = 123;
objB.y = 456;
// 只要 objB.y 不是 objA.x 的別名，下面就可以保證輸出為 123
print(objA.x);
}確定了 objA 和 objB 並非對方的別名後，許多與資料依賴相關的優化才可以進行（重排序、變數代換）。具體到這個例子中，就是無須擔心 objB.y 其實與 objA.x 指向同一塊記憶體，這樣就可以安全地確定列印語句中的 objA.x 為 123。
Java 編譯器另外一個紅利是由它的動態性所帶來的，由於 C/C++ 編譯器所有優化都在編譯期完成，以執行期效能監控為基礎的優化措施它都無法進行，如呼叫頻率預測（Call Frequency Prediction）、分支頻率預測（Branch Frequency Prediction）、裁剪未被選中的分支（Untaken Branch Pruning）等，這些都會成為 Java 語言都有的效能優勢。