前段時間，給星球的球友們專門碼了一篇文章《深入分析Java的編譯原理》，其中深入的介紹了Java中的javac編譯和JIT編譯的區別及原理。並在文中提到：JIT編譯除了具有快取的功能外，還會對程式碼做各種優化，比如：逃逸分析、 鎖消除、 鎖膨脹、 方法內聯、 空值檢查消除、 型別檢測消除、 公共子表示式消除等。
有球友閱讀完這部分內容後，對JVM產生了濃厚的興趣，自己回去專門學習了一下，在學習過程中遇到一個小問題，關於Java記憶體分配的。所以和我在微信上做過簡單的交流。主要涉及到Java中的堆和棧、陣列記憶體分配、逃逸分析、編譯優化等技術及原理。本文也是關於這部分知識點的分享。
JVM記憶體分配策略
關於JVM的記憶體結構及記憶體分配方式，不是本文的重點，這裡只做簡單回顧。以下是我們知道的一些常識：
1、根據Java虛擬機器規範，Java虛擬機器所管理的記憶體包括方法區、虛擬機器棧、本地方法棧、堆、程式計數器等。
2、我們通常認為JVM中執行時資料儲存包括堆和棧。這裡所提到的棧其實指的是虛擬機器棧，或者說是虛擬棧中的區域性變數表。
3、棧中存放一些基本型別的變數資料（int/short/long/byte/float/double/Boolean/char）和物件引用。
4、堆中主要存放物件，即通過new關鍵字建立的物件。
5、陣列引用變數是存放在棧記憶體中，陣列元素是存放在堆記憶體中。
在《深入理解Java虛擬機器中》關於Java堆記憶體有這樣一段描述：
但是，隨著JIT編譯期的發展與逃逸分析技術逐漸成熟，棧上分配、標量替換優化技術將會導致一些微妙的變化，所有的物件都分配到堆上也漸漸變得不那麼“絕對”了。
這裡只是簡單提了一句，並沒有深入分析，很多人看到這裡由於對JIT、逃逸分析等技術不瞭解，所以也無法真正理解上面這段話的含義。
PS：這裡預設大家都瞭解什麼是JIT，不瞭解的朋友可以先自行Google瞭解下，或者加入我的知識星球，閱讀那篇球友專享文章。
其實，在編譯期間，JIT會對程式碼做很多優化。其中有一部分優化的目的就是減少記憶體堆分配壓力，其中一種重要的技術叫做逃逸分析。
逃逸分析
逃逸分析(Escape Analysis)是目前Java虛擬機器中比較前沿的優化技術。這是一種可以有效減少Java 程式中同步負載和記憶體堆分配壓力的跨函式全域性資料流分析演算法。通過逃逸分析，Java Hotspot編譯器能夠分析出一個新的物件的引用的使用範圍從而決定是否要將這個物件分配到堆上。
逃逸分析的基本行為就是分析物件動態作用域：當一個物件在方法中被定義後，它可能被外部方法所引用，例如作為呼叫引數傳遞到其他地方中，稱為方法逃逸。
例如：
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 String createStringBuffer(String s1, String s2) {
StringBuffer sb = new StringBuffer();
sb.append(s1);
sb.append(s2);
return sb.toString();
}
複製程式碼不直接返回 StringBuffer，那麼StringBuffer將不會逃逸出方法。
使用逃逸分析，編譯器可以對程式碼做如下優化：
一、同步省略。如果一個物件被發現只能從一個執行緒被訪問到，那麼對於這個物件的操作可以不考慮同步。
二、將堆分配轉化為棧分配。如果一個物件在子程式中被分配，要使指向該物件的指標永遠不會逃逸，物件可能是棧分配的候選，而不是堆分配。
三、分離物件或標量替換。有的物件可能不需要作為一個連續的記憶體結構存在也可以被訪問到，那麼物件的部分（或全部）可以不儲存在記憶體，而是儲存在CPU暫存器中。
上面的關於同步省略的內容，我在《深入理解多執行緒（五）—— Java虛擬機器的鎖優化技術》中有介紹過，即鎖優化中的鎖消除技術，依賴的也是逃逸分析技術。
本文，主要來介紹逃逸分析的第二個用途：將堆分配轉化為棧分配。
其實，以上三種優化中，棧上記憶體分配其實是依靠標量替換來實現的。由於不是本文重點，這裡就不展開介紹了。如果大家感興趣，我後面專門出一篇文章，全面介紹下逃逸分析。
在Java程式碼執行時，通過JVM引數可指定是否開啟逃逸分析， -XX:+DoEscapeAnalysis ： 表示開啟逃逸分析 -XX:-DoEscapeAnalysis ： 表示關閉逃逸分析 從jdk 1.7開始已經預設開始逃逸分析，如需關閉，需要指定-XX:-DoEscapeAnalysis
物件的棧上記憶體分配
我們知道，在一般情況下，物件和陣列元素的記憶體分配是在堆記憶體上進行的。但是隨著JIT編譯器的日漸成熟，很多優化使這種分配策略並不絕對。JIT編譯器就可以在編譯期間根據逃逸分析的結果，來決定是否可以將物件的記憶體分配從堆轉化為棧。
我們來看以下程式碼：
public static void main(String[] args) {
long a1 = System.currentTimeMillis();
for (int i = 0; i < 1000000; i++) {
alloc();
}
// 檢視執行時間
long a2 = System.currentTimeMillis();
System.out.println("cost " + (a2 - a1) + " ms");
// 為了方便檢視堆記憶體中物件個數，執行緒sleep
try {
Thread.sleep(100000);
} catch (InterruptedException e1) {
e1.printStackTrace();
}
}
private static void alloc() {
User user = new User();
}
static class User {
}
複製程式碼其實程式碼內容很簡單，就是使用for迴圈，在程式碼中建立100萬個User物件。
我們在alloc方法中定義了User物件，但是並沒有在方法外部引用他。也就是說，這個物件並不會逃逸到alloc外部。經過JIT的逃逸分析之後，就可以對其記憶體分配進行優化。
我們指定以下JVM引數並執行：
-Xmx4G -Xms4G -XX:-DoEscapeAnalysis -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError
複製程式碼在程式列印出 cost XX ms 後，程式碼執行結束之前，我們使用[jmap][1]命令，來檢視下當前堆記憶體中有多少個User物件：
➜ ~ jps
2809 StackAllocTest
2810 Jps
➜ ~ jmap -histo 2809
num #instances #bytes class name
----------------------------------------------
1: 524 87282184 [I
2: 1000000 16000000 StackAllocTest$User
3: 6806 2093136 [B
4: 8006 1320872 [C
5: 4188 100512 java.lang.String
6: 581 66304 java.lang.Class
複製程式碼從上面的jmap執行結果中我們可以看到，堆中共建立了100萬個StackAllocTest$User例項。
在關閉逃避分析的情況下（-XX:-DoEscapeAnalysis），雖然在alloc方法中建立的User物件並沒有逃逸到方法外部，但是還是被分配在堆記憶體中。也就說，如果沒有JIT編譯器優化，沒有逃逸分析技術，正常情況下就應該是這樣的。即所有物件都分配到堆記憶體中。
接下來，我們開啟逃逸分析，再來執行下以上程式碼。
-Xmx4G -Xms4G -XX:+DoEscapeAnalysis -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError
複製程式碼在程式列印出 cost XX ms 後，程式碼執行結束之前，我們使用jmap命令，來檢視下當前堆記憶體中有多少個User物件：
➜ ~ jps
709
2858 Launcher
2859 StackAllocTest
2860 Jps
➜ ~ jmap -histo 2859
num #instances #bytes class name
----------------------------------------------
1: 524 101944280 [I
2: 6806 2093136 [B
3: 83619 1337904 StackAllocTest$User
4: 8006 1320872 [C
5: 4188 100512 java.lang.String
6: 581 66304 java.lang.Class
複製程式碼從以上列印結果中可以發現，開啟了逃逸分析之後（-XX:+DoEscapeAnalysis），在堆記憶體中只有8萬多個StackAllocTest$User物件。也就是說在經過JIT優化之後，堆記憶體中分配的物件數量，從100萬降到了8萬。
除了以上通過jmap驗證物件個數的方法以外，讀者還可以嘗試將堆記憶體調小，然後執行以上程式碼，根據GC的次數來分析，也能發現，開啟了逃逸分析之後，在執行期間，GC次數會明顯減少。正是因為很多堆上分配被優化成了棧上分配，所以GC次數有了明顯的減少。
總結
所以，如果以後再有人問你：是不是所有的物件和陣列都會在堆記憶體分配空間？
那麼你可以告訴他：不一定，隨著JIT編譯器的發展，在編譯期間，如果JIT經過逃逸分析，發現有些物件沒有逃逸出方法，那麼有可能堆記憶體分配會被優化成棧記憶體分配。但是這也並不是絕對的。就像我們前面看到的一樣，在開啟逃逸分析之後，也並不是所有User物件都沒有在堆上分配。