JAVA JIT編譯優化

什麼是JIT

JIT的全稱是Just in time compilation，中文稱之爲即時編譯，可以加速 Java 程序的執行速度。JIT是JVM最強大的武器之一。

JVM client模式和Server模式區別

JVM Server模式與client模式啓動，最主要的差異在於：-Server模式啓動時，速度較慢，可是一旦運行起來後，性能將會有很大的提高。

JVM工做在Server模式下能夠大大提升性能，Server模式下應用的啓動速度會比client模式慢大概10%，但運行速度比Client VM要快至少有10倍

當不指定運行模式參數時，虛擬機啓動檢測主機是否爲服務器，若是是，則以Server模式啓動，不然以client模式啓動，J2SE5.0檢測的根據是至少2個CPU和最低2GB內存。

因爲服務器的CPU、內存和硬盤都比客戶端機器強大，因此程序部署後，都應該以server模式啓動，獲取較好的性能；

JVM在client模式默認-Xms是1M，-Xmx是64M；JVM在Server模式默認-Xms是128M，-Xmx是1024M；

server:啓動慢，編譯更徹底，編譯器是自適應編譯器，效率高，針對服務端應用優化，在服務器環境中最大化程序執行速度而設計。

client:快速啓動，內存佔用少，編譯快，針對桌面應用程序優化，爲在客戶端環境中減小啓動時間而優化；

當JVM用於啓動GUI界面的交互應用時適合於使用client模式，當JVM用於運行服務器後臺程序時建議用Server模式。

咱們能夠經過運行:java -version來查看jvm默認工做在什麼模式。

clien模式下，新生代選擇的是串行gc，舊生代選擇的是串行gc

 server模式下，新生代選擇的是並行回收gc，舊生代選擇的是並行gc

通常來講咱們系統應用選擇有兩種方式：吞吐量優先和暫停時間優先，對於吞吐量優先的採用server默認的並行gc方式，對於暫停時間優先的選用併發gc（CMS）方式。

其它延伸知識點

JDK有兩種VM,VM客戶端，VM服務器應用程序。這兩種解決方案分享java運行環境的熱點代碼庫，但使用不一樣的編譯器，適用於客戶機和服務器的獨特的性能特色，這些差別包括編寫內聯政策和堆的默認值。

雖然服務器和客戶端虛擬機相似，服務器VM已專門調整最大峯值操做速度。它的目的是執行長時間運行的服務器應用程序，它須要最快的運行速度超過一個快速啓動時間或較小的運行時內存佔用。

客戶VM編譯器是經典的虛擬機和實時升級（JIT）經過JDK的先前版本使用的編譯器。客戶端虛擬機提供了改進的運行應用程序和小程序的性能。java虛擬機的熱點客戶已減小應用程序的啓動時間和內存佔用特別調整，使其特別適合客戶環境。在通常狀況下，客戶端系統更好的圖形用戶界面。

所以，真正的區別也在編譯器級別上：

客戶端虛擬機編譯器不嘗試執行由編譯器在服務器虛擬機上執行的更復雜的優化，但在交換過程當中，它須要較少的時間來分析和編譯一段代碼。這意味着客戶端虛擬機能夠更快地啓動，並須要一個較小的內存佔用。

服務器虛擬機包含一個先進的自適應編譯器支持許多C++編譯器的優化進行優化，一樣的類型，以及一些優化，不能用傳統的編譯器完成的，好比積極的內聯在虛擬方法調用。這是一個競爭和性能優點，靜態編譯器。自適應優化技術在它的方法是很是靈活的，一般優於甚至先進的靜態分析和編譯技術。

-Server模式啓動時，速度較慢，可是一旦運行起來後，性能將會有很大的提高，緣由是：當虛擬機在-Client模式的時候，使用的是一個代號爲C1的輕量級編譯器，而-Server模式啓動的虛擬機採用相對重量級代號爲C2的編譯器，C2比C1編譯器編譯的相對完全，服務起來以後，性能高。

通常只要變動-server KNOWN與-client KNOWN兩個配置的前後順序便可，前提是JAVA_HOME/jre/bin目錄下同時存在server和client兩個文件夾，分別對應各自的jvm

說了這麼多其實總結成一句話就是：

JVM Server模式下應用啓動慢但運行速度快，JVM Client模式下應用啓動快但運行速度要慢些

推薦：服務器上請以Server模式運行，面客戶端或GUI模式下就以Client模式運行

 

參考：https://www.jb51.net/article/129592.htm

 

JIT

即時編譯（Just-in-time Compilation，JIT）是一種經過在運行時將字節碼翻譯爲機器碼，從而改善字節碼編譯語言性能的技術。在HotSpot實現中有多種選擇：C一、C2和C1+C2，分別對應JVM 的client模式、server模式和分層編譯。

1. C1編譯速度快，優化方式比較保守；
2. C2編譯速度慢，優化方式比較激進，這也是爲何 -server 模式啓動比較慢的緣由；
3. C1+C2在開始階段採用C1編譯，當代碼運行到必定熱度以後採用G2從新編譯；

在1.8以前，分層編譯默認是關閉的，能夠添加-server -XX:+TieredCompilation參數進行開啓。

一般JIT的有如下幾種手段來優化JVM的性能：

1. 針對特定CPU型號的編譯優化，JVM會利用不一樣CPU支持的SIMD指令集來編譯熱點代碼，提高性能。像intel支持的SSE2指令集在特定狀況下能夠提高近40倍的性能。
2. 減小查表次數。好比調用Object.equals()方法，若是運行時發現一直是String對象的equals，編譯後的代碼能夠直接調用String.equals方法，跳過查找該調用哪一個方法的步驟。
3. 逃逸分析。JAVA變量默認是分配在主存的堆上，可是若是方法中的變量未逃出使用的生命週期，不會被外部方法或者線程引用，能夠考慮在棧上分配內存，減小GC壓力。另外逃逸分析能夠實現鎖優化等提高性能方法。
4. 寄存器分配，部分變量能夠分配在寄存器中，相對於主存讀取，更大的提高讀取性能。
5. 針對熱點代碼編譯好的機器碼進行緩存。代碼緩存具備固定的大小，而且一旦它被填滿，JVM 則不能再編譯更多的代碼。
6. 方法內聯，也是JIT實現的很是有用的優化能力，同時是開發者可以簡單參與JIT性能調優的地方。

接下來咱們將對上面的集中優化方式進行詳細學習

1.方法內聯

什麼是方法內聯

1. 編譯過程遇到方法調用，把目標方法體歸入編譯範圍且取代原方法優化手段
2. 是編譯優化最重要的

函數的調用過程

要搞清楚爲何方法內聯有用，首先要知道當一個函數被調用的時候發生了什麼

1. 首先會有個執行棧，存儲目前全部活躍的方法，以及它們的本地變量和參數
2. 當一個新的方法被調用了，一個新的棧幀會被加到棧頂，分配的本地變量和參數會存儲在這個棧幀
3. 跳到目標方法代碼執行
4. 方法返回的時候，本地方法和參數會被銷燬，棧頂被移除
5. 返回原來地址執行

這種轉移操做要求在轉去前要保護現場並記憶執行的地址，轉回後先要恢復現場，並按原來保存地址繼續執行。也就是一般說的壓棧和出棧。

這就是一般說的函數調用的壓棧和出棧過程，所以，函數調用須要有必定的時間開銷和空間開銷，當一個方法體不大，但又頻繁被調用時，這個時間和空間開銷會相對變得很大，變得很是不划算，同時下降了程序的性能。根據二八原則，80%的性能消耗實際上是發生在20%的代碼上，對熱點代碼的針對性優化能夠提高總體系統的性能。

那怎麼解決這個性能消耗問題呢，這個時候須要引入內聯函數了。內聯函數就是在程序編譯時，編譯器將程序中出現的內聯函數的調用表達式用內聯函數的函數體來直接進行替換。顯然，這樣就不會產生轉去轉回的問題，可是因爲在編譯時將函數體中的代碼被替代到程序中，所以會增長目標程序代碼量，進而增長空間開銷，而在時間代銷上不象函數調用時那麼大，可見它是以目標代碼的增長爲代價來換取時間的節省。

JVM內聯函數

舉例：getter/setter 

1. 若是沒有方法內聯，調用時須要建立並壓入用於getter/setter的棧幀，訪問字段，彈出棧幀，最後再到當前方法執行
2. 內聯後，就僅剩字段訪問

C++是否爲內聯函數由本身決定，Java由編譯器決定。Java不支持直接聲明爲內聯函數的，若是想讓他內聯，你只可以向編譯器提出請求: 關鍵字final修飾 用來指明那個函數是但願被JVM內聯的，例：

public final void doSomething() {  

        // to do something  

}  

總的來講，通常的函數都不會被當作內聯函數，只有聲明瞭final後，編譯器纔會考慮是否是要把你的函數變成內聯函數。

JVM內建有許多運行時優化。首先短方法更利於JVM推斷。流程更明顯，做用域更短，反作用也更明顯。若是是長方法JVM可能直接就跪了。第二個緣由則更重要：方法內聯

若是JVM監測到一些小方法被頻繁的執行，它會把方法的調用替換成方法體自己。好比說下面這個：
 

private int add4(int x1, int x2, int x3, int x4) {  

        return add2(x1, x2) + add2(x3, x4);  

}  

private int add2(int x1, int x2) {  

        return x1 + x2;  

}  

運行一段時間後JVM會把add2方法去掉，並把你的代碼翻譯成：

private int add4(int x1, int x2, int x3, int x4) {  

        return x1 + x2 + x3 + x4;  

}

方法內聯的條件

1. 內聯越多執行效率越高，可是編譯時間會延長
2. 內聯越多，機器碼越長容易使java內存溢出

JVM會自動的識別熱點方法，並對它們使用方法內聯優化。那麼一段代碼須要執行多少次纔會觸發JIT優化呢？一般這個值由-XX:CompileThreshold參數進行設置：

1. 使用client編譯器時，默認爲1500；
2. 使用server編譯器時，默認爲10000；

可是一個方法就算被JVM標註成爲熱點方法，JVM仍然不必定會對它作方法內聯優化。其中有個比較常見的緣由就是這個方法體太大了，分爲兩種狀況。

若是方法是常常執行的，默認狀況下，方法大小小於325字節的都會進行內聯（能夠經過-XX:MaxFreqInlineSize=N來設置這個大小）

若是方法不是常常執行的，默認狀況下，方法大小小於35字節纔會進行內聯（能夠經過-XX:MaxInlineSize=N來設置這個大小）

咱們能夠經過增長這個大小，以便更多的方法能夠進行內聯；可是除非可以顯著提高性能，不然不推薦修改這個參數。由於更大的方法體會致使代碼內存佔用更多，更少的熱點方法會被緩存，最終的效果不必定好。

 

若是想要知道方法被內聯的狀況，可使用下面的JVM參數來配置：

-XX:+PrintCompilation //在控制檯打印編譯過程信息

-XX:+UnlockDiagnosticVMOptions //解鎖對JVM進行診斷的選項參數。默認是關閉的，開啓後支持一些特定參數對JVM進行診斷

-XX:+PrintInlining //將內聯方法打印出來

方法內聯的其餘隱含條件

雖然JIT號稱能夠針對代碼全局的運行狀況而優化，可是JIT對一個方法內聯以後，仍是可能由於方法被繼承，致使須要類型檢查而沒有達到性能的效果

想要對熱點的方法使用上內聯的優化方法，最好儘可能使用final、private、static這些修飾符修飾方法，避免方法由於繼承，致使須要額外的類型檢查，而出現效果很差狀況。

這就是JVM中簡單的方法內聯，固然方法內聯還有不少限制，執行規則以下表所示：

 

參考：

https://blog.csdn.net/u012834750/article/details/79488572

https://blog.csdn.net/dachaoa/article/details/82594996

 

2.逃逸分析

逃逸分析(Escape Analysis)是目前Java虛擬機中比較前沿的優化技術。

逃逸分析的基本行爲就是分析對象動態做用域：當一個對象在方法中被定義後，它可能被外部方法所引用，例如做爲調用參數傳遞到其餘地方中，稱爲方法逃逸。

例如：

public static StringBuffer craeteStringBuffer(String s1, String s2) {

        StringBuffer sb = new StringBuffer();
        sb.append(s1);
        sb.append(s2);
        return sb;
}

StringBuffer sb是一個方法內部變量，上述代碼中直接將sb返回，這樣這個StringBuffer有可能被其餘方法所改變，這樣它的做用域就不僅是在方法內部，雖然它是一個局部變量，稱其逃逸到了方法外部。

甚至還有可能被外部線程訪問到，譬如賦值給類變量或能夠在其餘線程中訪問的實例變量，稱爲線程逃逸。

上述代碼若是想要StringBuffer sb不逃出方法，能夠這樣寫：

public static StringBuffer craeteStringBuffer(String s1, String s2) {

        StringBuffer sb = new StringBuffer();
        sb.append(s1);
        sb.append(s2);
        return sb;
}

不直接返回 StringBuffer，那麼StringBuffer將不會逃逸出方法。

若是能證實一個對象不會逃逸到方法或線程外，則可能爲這個變量進行一些高效的優化。

方法逃逸的幾種方式以下：

public class EscapeTest {

    public static Object obj;

    public void globalVariableEscape() {  // 給全局變量賦值，發生逃逸

        obj = new Object();

    }

    public Object methodEscape() {  // 方法返回值，發生逃逸

        return new Object();

    }

    public void instanceEscape() {  // 實例引用發生逃逸

        test(this);

    }

}

標量替換

Java虛擬機中的原始數據類型（int，long等數值類型以及reference類型等）都不能再進一步分解，它們就能夠稱爲標量。相對的，若是一個數據能夠繼續分解，那它稱爲聚合量，Java中最典型的聚合量是對象。若是逃逸分析證實一個對象不會被外部訪問，而且這個對象是可分解的，那程序真正執行的時候將可能不建立這個對象，而改成直接建立它的若干個被這個方法使用到的成員變量來代替。拆散後的變量即可以被單獨分析與優化，能夠各自分別在棧幀或寄存器上分配空間，本來的對象就無需總體分配空間了。

經過-XX:+EliminateAllocations能夠開啓標量替換， -XX:+PrintEliminateAllocations查看標量替換狀況。

棧上分配

咱們都知道Java中的對象都是在堆上分配的，而垃圾回收機制會回收堆中再也不使用的對象，可是篩選可回收對象，回收對象還有整理內存都須要消耗時間。若是可以經過逃逸分析肯定某些對象不會逃出方法以外，那就可讓這個對象在棧上分配內存，這樣該對象所佔用的內存空間就能夠隨棧幀出棧而銷燬，就減輕了垃圾回收的壓力。

在通常應用中，若是不會逃逸的局部對象所佔的比例很大，若是能使用棧上分配，那大量的對象就會隨着方法的結束而自動銷燬了。

故名思議就是在棧上分配對象，其實目前Hotspot並無實現真正意義上的棧上分配，其實是標量替換。 

 private static int fn(int age) {

        User user = new User(age);
        int i = user.getAge();
        return i;
}

User對象的做用域侷限在方法fn中，可使用標量替換的優化手段在棧上分配對象的成員變量，這樣就不會生成User對象，大大減輕GC的壓力，下面經過例子看看逃逸分析的影響。

public class JVM {

    public static void main(String[] args) throws Exception {

        int sum = 0;

        int count = 1000000;

        //warm up

        for (int i = 0; i < count ; i++) {

            sum += fn(i);

        }
        Thread.sleep(500);

        for (int i = 0; i < count ; i++) {

            sum += fn(i);

        }

        System.out.println(sum);

        System.in.read();

    }


    private static int fn(int age) {

        User user = new User(age);

        int i = user.getAge();

        return i;

    }

}

class User {

    private final int age;

    public User(int age) {

        this.age = age;

    }

    public int getAge() {

        return age;

    }

}

分層編譯和逃逸分析在1.8中是默認是開啓的，例子中fn方法被執行了200w次，按理說應該在Java堆生成200w個User對象。

一、經過java -cp . -Xmx3G -Xmn2G -server -XX:-DoEscapeAnalysis JVM運行代碼，-XX:-DoEscapeAnalysis關閉逃逸分析，經過jps查看java進程的PID，接着經過jmap -histo [pid]查看java堆上的對象分佈狀況，結果以下：

能夠發現：關閉逃逸分析以後，User對象一個很多的都在堆上進行分配。

二、經過java -cp . -Xmx3G -Xmn2G -server JVM運行代碼，結果以下：

能夠發現：開啓逃逸分析以後，只有41w左右的User對象在Java堆上分配，其他的對象已經經過標量替換優化了。

三、經過java -cp . -Xmx3G -Xmn2G -server -XX:-TieredCompilation運行代碼，關閉分層編譯，結果以下：

能夠發現：關閉了分層編譯以後，在Java堆上分配的User對象下降到1w多個，分層編譯對逃逸分析仍是有影響的。

編譯閾值

即時編譯JIT只在代碼段執行足夠次數纔會進行優化，在執行過程當中不斷收集各類數據，做爲優化的決策，因此在優化完成以前，例子中的User對象仍是在堆上進行分配。

那麼一段代碼須要執行多少次纔會觸發JIT優化呢？一般這個值由-XX:CompileThreshold參數進行設置：

一、使用client編譯器時，默認爲1500；

二、使用server編譯器時，默認爲10000；

意味着若是方法調用次數或循環次數達到這個閾值就會觸發標準編譯，更改CompileThreshold標誌的值，將使編譯器提前（或延遲）編譯。

除了標準編譯，還有一個叫作OSR（On Stack Replacement）棧上替換的編譯，如上述例子中的main方法，只執行一次，遠遠達不到閾值，可是方法體中執行了屢次循環，OSR編譯就是隻編譯該循環代碼，而後將其替換，下次循環時就執行編譯好的代碼，不過觸發OSR編譯也須要一個閾值，能夠經過如下公式獲得。

-XX:CompileThreshold = 10000

-XX:OnStackReplacePercentage = 140

-XX:InterpreterProfilePercentage = 33

OSR trigger = (CompileThreshold * (OnStackReplacePercentage - InterpreterProfilePercentage)) / 100 = 10700

其中trigger即爲OSR編譯的閾值。

那麼若是把CompileThreshold設置適當小一點，是否是能夠提前觸發編譯行爲，減小在堆上生成User對象？咱們能夠進行經過不一樣參數驗證一下：

1.-XX:CompileThreshold = 5000，結果以下：

2.-XX:CompileThreshold = 2500，結果以下：

3.-XX:CompileThreshold = 2000，結果以下：

4.-XX:CompileThreshold = 1500，結果以下：

在個人機器中，當設置到1500時，在堆上生成的User對象反而升到4w個，目前還不清楚緣由是啥...

JIT編譯在默認狀況是異步進行的，當觸發某方法或某代碼塊的優化時，先將其放入編譯隊列，而後由編譯線程進行編譯，編譯以後的代碼放在CodeCache中，CodeCache的大小也是有限的，經過-XX:-BackgroundCompilation參數能夠關閉異步編譯，咱們能夠經過執行java -cp . -Xmx3G -Xmn2G -server -XX:CompileThreshold=1 -XX:-TieredCompilation -XX:-BackgroundCompilation JVM命令看看同步編譯的效果：在java堆上只生成了2個對象。

同步消除

線程同步的代價是至關高的，同步的後果是下降併發性和性能。逃逸分析能夠判斷出某個對象是否始終只被一個線程訪問，若是隻被一個線程訪問，那麼對該對象的同步操做就能夠轉化成沒有同步保護的操做，這樣就能大大提升併發程度和性能，經過-XX:+EliminateLocks能夠開啓同步消除。

劣勢  

1.熱點代碼的編譯過程是有成本的，若是邏輯複雜，編程成本更高；

2.編譯後的代碼會被存放在有大小限制的CodeCache中，若是CompileThreshold設置的過低，JIT會將一大堆執行不那麼頻繁的代碼進行編譯，並放入CodeCache，致使以後真正執行頻繁的代碼沒有足夠的空間存放；

3.棧上分配受限於棧的空間大小，通常自我迭代類的需求以及大的對象空間需求操做，將致使棧的內存溢出；故只適用於必定範圍以內的內存範圍請求。

測試代碼

測試代碼：

public class Test {

    public static void alloc() {

        byte[] b = new byte[2];

        b[0] = 1;

    }



    public static void main(String[] args) {

        long b = System.currentTimeMillis();

        for (int i = 0; i < 100000000; i++) {

            alloc();

        }

        long e = System.currentTimeMillis();

        System.out.println(e - b);

    }

}

開啓逃逸分析

執行：java  -server  -Xmx10m  -Xms10m  -XX:+DoEscapeAnalysis  -XX:+PrintGC  Test

打印：

[GC (Allocation Failure)  2048K->672K(9728K), 0.0012560 secs]

[GC (Allocation Failure)  2720K->744K(9728K), 0.0009568 secs]

[GC (Allocation Failure)  2792K->752K(9728K), 0.0013591 secs]

8

 

關閉逃逸分析

執行：java  -server  -Xmx10m  -Xms10m  -XX:-DoEscapeAnalysis  -XX:+PrintGC  Test

打印：

......省略

[GC (Allocation Failure)  2736K->688K(9728K), 0.0005100 secs]

[GC (Allocation Failure)  2736K->688K(9728K), 0.0004587 secs]

[GC (Allocation Failure)  2736K->688K(9728K), 0.0005108 secs]

[GC (Allocation Failure)  2736K->688K(9728K), 0.0005064 secs]

[GC (Allocation Failure)  2736K->688K(9728K), 0.0004930 secs]

[GC (Allocation Failure)  2736K->688K(9728K), 0.0004780 secs]

[GC (Allocation Failure)  2736K->688K(9728K), 0.0004464 secs]

[GC (Allocation Failure)  2736K->688K(9728K), 0.0008060 secs]

[GC (Allocation Failure)  2736K->688K(9728K), 0.0011400 secs]

[GC (Allocation Failure)  2736K->688K(9728K), 0.0008325 secs]

......省略

[GC (Allocation Failure)  2736K->688K(9728K), 0.0004733 secs]

[GC (Allocation Failure)  2736K->688K(9728K), 0.0004299 secs]

[GC (Allocation Failure)  2736K->688K(9728K), 0.0004180 secs]

[GC (Allocation Failure)  2736K->688K(9728K), 0.0003703 secs]

1315

擴展

在上一小節，當咱們開啓了逃逸分析，若是內存足夠大，打印的日誌就只有程序執行的時間，若是咱們調小啓動參數中年輕代的內存，就會發現日誌中存在GC日誌。

爲啥會有GC呢？？咱們明明開啓的逃逸分析，按理來講，應該會在棧上分配對象的啊。下面將回答這個問題

我使用的是JDK1.8,默認使用混合模式，你能夠會問：什麼是混合模式？

在Hotspot中採用的是解釋器和編譯器並行的架構，所謂的混合模式就是解釋器和編譯器搭配使用，當程序啓動初期，採用解釋器執行（同時會記錄相關的數據，好比函數的調用次數，循環語句執行次數），節省編譯的時間。在使用解釋器執行期間，記錄的函數運行的數據，經過這些數據發現某些代碼是熱點代碼，採用編譯器對熱點代碼進行編譯，以及優化（逃逸分析就是其中一種優化技術）

如今咱們知道了什麼是混合模式，可是咱們怎麼知道咱們的JDK採用了混合模式呢？

在windows系統中，咱們經過cmd命令進行命令行窗口，執行命令

java -verion

執行結果：

java version "1.8.0_144"

Java(TM) SE Runtime Environment (build 1.8.0_144-b01)

Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)

//mixed mode 表示用的混合模式，interpreted mode 表示使用解釋器， compiled mode 表示採用編譯器

爲何會有GC日誌？

在程序啓動初期，咱們使用的解釋器執行，使用解釋器執行沒有逃逸分析的技術，所以對象在年輕代進行分配，關於對象的分配和咱們上面的分析流程一致，當年輕代空間不足，就會觸發GC，關於對象的建立以及GC的觸發能夠參考個人文章：http://www.jianshu.com/p/941fe93d21c2

使用解釋器執行，積累的程序執行的相關數據，使用編譯器對熱點代碼進行編譯，而且採用逃逸分析技術進行優化。對象將在棧上分配，隨着棧幀的出棧而消亡。

只使用編譯器執行上面的代碼會是什麼效果？

啓動參數：

-server -Xcomp -verbose:gc -XX:+DoEscapeAnalysis  -XX:-UseTLAB  -Xmx20m -Xms20m -Xmn3m

程序打印的日誌：

Time cost is 144426438

對比上面的日誌，咱們發現使用的時間多了兩個數量級，並且沒有GC日誌，爲何呢？

沒有GC日誌是由於程序使用編譯器來執行程序，並進行了逃逸分析的優化操做；時間多了兩個數量級是由於編譯器編譯的過程緩慢，今天先來點開胃小菜，接下來將寫其餘的文章來說解編譯器和解釋器的混合。

總結

雖然概念上的JVM老是在Java堆上爲對象分配空間，但並非說徹底依照概念的描述去實現；只要最後實現處理的「可見效果」與概念中描述的一直就沒問題了。因此說，「you can cheat as long as you don’t get caught」。Java對象在實際的JVM實現中可能在GC堆上分配空間，也可能在棧上分配空間，也可能徹底就消失了。這種行爲從Java源碼中看不出來，也沒法顯式指定，只是聰明的JVM自動作的優化而已。

可是逃逸分析會有時間消耗，因此性能未必提高多少，而且因爲逃逸分析比較耗時，目前的實現都是採用不那麼準確可是時間壓力相對較小的算法來完成逃逸分析，這就可能致使效果不穩定，要慎用。

參考：

https://www.jianshu.com/p/20bd2e9b1f03

https://www.jianshu.com/p/3835450d49d0