深刻理解Java中的逃逸分析

在Java的編譯體系中，一個Java的源代碼文件變成計算機可執行的機器指令的過程當中，須要通過兩段編譯，第一段是把.java文件轉換成.class文件。第二段編譯是把.class轉換成機器指令的過程。

第一段編譯就是javac命令。

在第二編譯階段，JVM 經過解釋字節碼將其翻譯成對應的機器指令，逐條讀入，逐條解釋翻譯。很顯然，通過解釋執行，其執行速度必然會比可執行的二進制字節碼程序慢不少。這就是傳統的JVM的解釋器（Interpreter）的功能。爲了解決這種效率問題，引入了 JIT（即時編譯） 技術。

引入了 JIT 技術後，Java程序仍是經過解釋器進行解釋執行，當JVM發現某個方法或代碼塊運行特別頻繁的時候，就會認爲這是「熱點代碼」（Hot Spot Code)。而後JIT會把部分「熱點代碼」翻譯成本地機器相關的機器碼，並進行優化，而後再把翻譯後的機器碼緩存起來，以備下次使用。

因爲關於JIT編譯和熱點檢測的內容，我在深刻分析Java的編譯原理中已經介紹過了，這裏就不在贅述，本文主要來介紹下JIT中的優化。JIT優化中最重要的一個就是逃逸分析。

逃逸分析

關於逃逸分析的概念，能夠參考對象和數組並非都在堆上分配內存的。一文，這裏簡單回顧一下：

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

例如如下代碼：

public static StringBuffer craeteStringBuffer(String s1, String s2) {
    StringBuffer sb = new StringBuffer();
    sb.append(s1);
    sb.append(s2);
    return sb;
}

public static String createStringBuffer(String s1, String s2) {
    StringBuffer sb = new StringBuffer();
    sb.append(s1);
    sb.append(s2);
    return sb.toString();
}
複製代碼

第一段代碼中的sb就逃逸了，而第二段代碼中的sb就沒有逃逸。

使用逃逸分析，編譯器能夠對代碼作以下優化：

1、同步省略。若是一個對象被發現只能從一個線程被訪問到，那麼對於這個對象的操做能夠不考慮同步。

2、將堆分配轉化爲棧分配。若是一個對象在子程序中被分配，要使指向該對象的指針永遠不會逃逸，對象多是棧分配的候選，而不是堆分配。

3、分離對象或標量替換。有的對象可能不須要做爲一個連續的內存結構存在也能夠被訪問到，那麼對象的部分（或所有）能夠不存儲在內存，而是存儲在CPU寄存器中。

在Java代碼運行時，經過JVM參數可指定是否開啓逃逸分析，

-XX:+DoEscapeAnalysis ： 表示開啓逃逸分析

-XX:-DoEscapeAnalysis ： 表示關閉逃逸分析 從jdk 1.7開始已經默認開始逃逸分析，如需關閉，須要指定-XX:-DoEscapeAnalysis

同步省略

在動態編譯同步塊的時候，JIT編譯器能夠藉助逃逸分析來判斷同步塊所使用的鎖對象是否只可以被一個線程訪問而沒有被髮布到其餘線程。

若是同步塊所使用的鎖對象經過這種分析被證明只可以被一個線程訪問，那麼JIT編譯器在編譯這個同步塊的時候就會取消對這部分代碼的同步。這個取消同步的過程就叫同步省略，也叫鎖消除。

如如下代碼：

public void f() {
    Object hollis = new Object();
    synchronized(hollis) {
        System.out.println(hollis);
    }
}
複製代碼

代碼中對hollis這個對象進行加鎖，可是hollis對象的生命週期只在f()方法中，並不會被其餘線程所訪問到，因此在JIT編譯階段就會被優化掉。優化成：

public void f() {
    Object hollis = new Object();
    System.out.println(hollis);
}
複製代碼

因此，在使用synchronized的時候，若是JIT通過逃逸分析以後發現並沒有線程安全問題的話，就會作鎖消除。

標量替換

標量（Scalar）是指一個沒法再分解成更小的數據的數據。Java中的原始數據類型就是標量。相對的，那些還能夠分解的數據叫作聚合量（Aggregate），Java中的對象就是聚合量，由於他能夠分解成其餘聚合量和標量。

在JIT階段，若是通過逃逸分析，發現一個對象不會被外界訪問的話，那麼通過JIT優化，就會把這個對象拆解成若干個其中包含的若干個成員變量來代替。這個過程就是標量替換。

public static void main(String[] args) {
   alloc();
}

private static void alloc() {
   Point point = new Point（1,2）;
   System.out.println("point.x="+point.x+"; point.y="+point.y);
}
class Point{
    private int x;
    private int y;
}
複製代碼

以上代碼中，point對象並無逃逸出alloc方法，而且point對象是能夠拆解成標量的。那麼，JIT就會不會直接建立Point對象，而是直接使用兩個標量int x ，int y來替代Point對象。

以上代碼，通過標量替換後，就會變成：

private static void alloc() {
   int x = 1;
   int y = 2;
   System.out.println("point.x="+x+"; point.y="+y);
}
複製代碼

能夠看到，Point這個聚合量通過逃逸分析後，發現他並無逃逸，就被替換成兩個聚合量了。那麼標量替換有什麼好處呢？就是能夠大大減小堆內存的佔用。由於一旦不須要建立對象了，那麼就再也不須要分配堆內存了。

標量替換爲棧上分配提供了很好的基礎。

棧上分配

在Java虛擬機中，對象是在Java堆中分配內存的，這是一個廣泛的常識。可是，有一種特殊狀況，那就是若是通過逃逸分析後發現，一個對象並無逃逸出方法的話，那麼就可能被優化成棧上分配。這樣就無需在堆上分配內存，也無須進行垃圾回收了。

關於棧上分配的詳細介紹，能夠參考對象和數組並非都在堆上分配內存的。。

這裏，仍是要簡單說一下，其實在現有的虛擬機中，並無真正的實現棧上分配，在對象和數組並非都在堆上分配內存的。中咱們的例子中，對象沒有在堆上分配，實際上是標量替換實現的。

逃逸分析並不成熟

關於逃逸分析的論文在1999年就已經發表了，但直到JDK 1.6纔有實現，並且這項技術到現在也並非十分紅熟的。

其根本緣由就是沒法保證逃逸分析的性能消耗必定能高於他的消耗。雖然通過逃逸分析能夠作標量替換、棧上分配、和鎖消除。可是逃逸分析自身也是須要進行一系列複雜的分析的，這其實也是一個相對耗時的過程。

一個極端的例子，就是通過逃逸分析以後，發現沒有一個對象是不逃逸的。那這個逃逸分析的過程就白白浪費掉了。

雖然這項技術並不十分紅熟，可是他也是即時編譯器優化技術中一個十分重要的手段。

參考資料

《深刻理解Java虛擬機》

維基百科