對象並不必定都是在堆上分配內存的

JVM內存分配策略

關於JVM的內存結構及內存分配方式，不是本文的重點，這裏只作簡單回顧。如下是咱們知道的一些常識：

一、根據Java虛擬機規範，Java虛擬機所管理的內存包括方法區、虛擬機棧、本地方法棧、堆、程序計數器等。

二、咱們一般認爲JVM中運行時數據存儲包括堆和棧。這裏所提到的棧其實指的是虛擬機棧，或者說是虛擬棧中的局部變量表。

三、棧中存放一些基本類型的變量數據（int/short/long/byte/float/double/Boolean/char）和對象引用。

四、堆中主要存放對象，即經過new關鍵字建立的對象。

五、數組引用變量是存放在棧內存中，數組元素是存放在堆內存中。

在《深刻理解Java虛擬機中》關於Java堆內存有這樣一段描述：

可是，隨着JIT編譯期的發展與逃逸分析技術逐漸成熟，棧上分配、標量替換優化技術將會致使一些微妙的變化，全部的對象都分配到堆上也漸漸變得不那麼「絕對」了。

這裏只是簡單提了一句，並無深刻分析，不少人看到這裏因爲對JIT、逃逸分析等技術不瞭解，因此也沒法真正理解上面這段話的含義。

PS：這裏默認你們都瞭解什麼是JIT，不瞭解的朋友能夠先自行Google瞭解下

其實，在編譯期間，JIT會對代碼作不少優化。其中有一部分優化的目的就是減小內存堆分配壓力，其中一種重要的技術叫作逃逸分析。

逃逸分析

逃逸分析(Escape Analysis)是目前Java虛擬機中比較前沿的優化技術。這是一種能夠有效減小Java 程序中同步負載和內存堆分配壓力的跨函數全局數據流分析算法。經過逃逸分析，Java Hotspot編譯器可以分析出一個新的對象的引用的使用範圍從而決定是否要將這個對象分配到堆上。

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

例如：

 1  
 2 public static StringBuffer craeteStringBuffer(String s1, String s2) {
 3  
 4    StringBuffer sb = new StringBuffer();
 5  
 6    sb.append(s1);
 7  
 8    sb.append(s2);
 9  
10    return sb;
11  
12 }

 

StringBuffer sb是一個方法內部變量，上述代碼中直接將sb返回，這樣這個StringBuffer有可能被其餘方法所改變，這樣它的做用域就不僅是在方法內部，雖然它是一個局部變量，稱其逃逸到了方法外部。甚至還有可能被外部線程訪問到，譬如賦值給類變量或能夠在其餘線程中訪問的實例變量，稱爲線程逃逸。

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

 1  
 2 public static String createStringBuffer(String s1, String s2) {
 3  
 4    StringBuffer sb = new StringBuffer();
 5  
 6    sb.append(s1);
 7  
 8    sb.append(s2);
 9  
10    return sb.toString();
11  
12 }

 

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

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

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

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

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

上面的關於同步省略的內容，我在《深刻理解多線程（五）—— Java虛擬機的鎖優化技術》中有介紹過，即鎖優化中的鎖消除技術，依賴的也是逃逸分析技術。

本文，主要來介紹逃逸分析的第二個用途：將堆分配轉化爲棧分配。

其實，以上三種優化中，棧上內存分配實際上是依靠標量替換來實現的。因爲不是本文重點，這裏就不展開介紹了。若是你們感興趣，我後面專門出一篇文章，全面介紹下逃逸分析。

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

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

 -XX:-DoEscapeAnalysis ： 表示關閉逃逸分析 

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

對象的棧上內存分配

咱們知道，在通常狀況下，對象和數組元素的內存分配是在堆內存上進行的。可是隨着JIT編譯器的日漸成熟，不少優化使這種分配策略並不絕對。JIT編譯器就能夠在編譯期間根據逃逸分析的結果，來決定是否能夠將對象的內存分配從堆轉化爲棧。

咱們來看如下代碼

 1 public static void main(String[] args) {
 2  
 3    long a1 = System.currentTimeMillis();
 4  
 5    for (int i = 0; i < 1000000; i++) {
 6  
 7        alloc();
 8  
 9    }
10  
11    // 查看執行時間
12  
13    long a2 = System.currentTimeMillis();
14  
15    System.out.println("cost " + (a2 - a1) + " ms");
16  
17    // 爲了方便查看堆內存中對象個數，線程sleep
18  
19    try {
20  
21        Thread.sleep(100000);
22  
23    } catch (InterruptedException e1) {
24  
25        e1.printStackTrace();
26  
27    }
28  
29 }
30  
31  
32  
33 private static void alloc() {
34  
35    User user = new User();
36  
37 }
38  
39  
40  
41 static class User {
42  
43  
44  
45 }

 

其實代碼內容很簡單，就是使用for循環，在代碼中建立100萬個User對象。

咱們在alloc方法中定義了User對象，可是並無在方法外部引用他。也就是說，這個對象並不會逃逸到alloc外部。通過JIT的逃逸分析以後，就能夠對其內存分配進行優化。

咱們指定如下JVM參數並運行：

-Xmx4G -Xms4G -XX:-DoEscapeAnalysis -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError

在程序打印出 cost XX ms 後，代碼運行結束以前，咱們使用[jmap][1]命令，來查看下當前堆內存中有多少個User對象：

 jmap的使用：https://www.jianshu.com/p/a4ad53179df3

 1  
 2 ➜  ~ jps
 3  
 4 2809 StackAllocTest
 5  
 6 2810 Jps
 7  
 8 ➜  ~ jmap -histo 2809
 9  
10  
11  
12 num     #instances         #bytes  class name
13  
14 ----------------------------------------------
15  
16   1:           524       87282184  [I
17  
18   2:       1000000       16000000  StackAllocTest$User
19  
20   3:          6806        2093136  [B
21  
22   4:          8006        1320872  [C
23  
24   5:          4188         100512  java.lang.String
25  
26   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對象：

 1  
 2 ➜  ~ jps
 3  
 4 709
 5  
 6 2858 Launcher
 7  
 8 2859 StackAllocTest
 9  
10 2860 Jps
11  
12 ➜  ~ jmap -histo 2859
13  
14  
15  
16 num     #instances         #bytes  class name
17  
18 ----------------------------------------------
19  
20   1:           524      101944280  [I
21  
22   2:          6806        2093136  [B
23  
24   3:         83619        1337904  StackAllocTest$User
25  
26   4:          8006        1320872  [C
27  
28   5:          4188         100512  java.lang.String
29  
30   6:           581          66304  java.lang.Class

從以上打印結果中能夠發現，開啓了逃逸分析以後（-XX:+DoEscapeAnalysis），在堆內存中只有8萬多個StackAllocTest$User對象。也就是說在通過JIT優化以後，堆內存中分配的對象數量，從100萬降到了8萬。

除了以上經過jmap驗證對象個數的方法之外，讀者還能夠嘗試將堆內存調小，而後執行以上代碼，根據GC的次數來分析，也能發現，開啓了逃逸分析以後，在運行期間，GC次數會明顯減小。正是由於不少堆上分配被優化成了棧上分配，因此GC次數有了明顯的減小。

總結

因此，若是之後再有人問你：是否是全部的對象和數組都會在堆內存分配空間？

那麼你能夠告訴他：不必定，隨着JIT編譯器的發展，在編譯期間，若是JIT通過逃逸分析，發現有些對象沒有逃逸出方法，那麼有可能堆內存分配會被優化成棧內存分配。可是這也並非絕對的。就像咱們前面看到的同樣，在開啓逃逸分析以後，也並非全部User對象都沒有在堆上分配。

轉自Hollis https://blog.csdn.net/w372426096/article/details/80333657