求你了，別再說Java對象都是在堆內(nèi)存上分配空間的了！

Java作為一種面向?qū)ο蟮模缙脚_語言，其對象、內(nèi)存等一直是比較難的知識點，所以，即使是一個Java的初學者，也一定或多或少的對JVM有一些了解?？梢哉f，關(guān)于JVM的相關(guān)知識，基本是每個Java開發(fā)者必學的知識點，也是面試的時候必考的知識點。


在JVM的內(nèi)存結(jié)構(gòu)中，比較常見的兩個區(qū)域就是堆內(nèi)存和棧內(nèi)存（如無特指，本文提到的棧均指的是虛擬機棧），關(guān)于堆和棧的區(qū)別，很多開發(fā)者也是如數(shù)家珍，有很多書籍，或者網(wǎng)上的文章大概都是這樣介紹的：

1、堆是線程共享的內(nèi)存區(qū)域，棧是線程獨享的內(nèi)存區(qū)域。

2、堆中主要存放對象實例，棧中主要存放各種基本數(shù)據(jù)類型、對象的引用。

但是，作者可以很負責任的告訴大家，以上兩個結(jié)論均不是完全正確的。

在我之前的文章《Java堆內(nèi)存是線程共享的！面試官：你確定嗎？》中，介紹過了關(guān)于堆內(nèi)存并不是完完全全的線程共享有關(guān)的知識點，本文就第二個話題來探討一下。

對象內(nèi)存分配

在《Java虛擬機規(guī)范》中，關(guān)于堆有這樣的描述：

在Java虛擬機中，堆是可供各個線程共享的運行時內(nèi)存區(qū)域，也是供所有類實例和數(shù)組對象分配內(nèi)存的區(qū)域。


在《Java堆內(nèi)存是線程共享的！面試官：你確定嗎？》文章中，我們也介紹過，一個Java對象在堆上分配的時候，主要是在Eden區(qū)上，如果啟動了TLAB的話會優(yōu)先在TLAB上分配，少數(shù)情況下也可能會直接分配在老年代中，分配規(guī)則并不是百分之百固定的，這取決于當前使用的是哪一種垃圾收集器，還有虛擬機中與內(nèi)存有關(guān)的參數(shù)的設(shè)置。

但是一般情況下是遵循以下原則的：

* 對象優(yōu)先在Eden區(qū)分配
* 優(yōu)先在Eden分配，如果Eden沒有足夠空間，會觸發(fā)一次Monitor GC
* 大對象直接進入老年代
* 需要大量連續(xù)內(nèi)存空間的Java對象，當對象需要的內(nèi)存大于-XX：PretenureSizeThreshold參數(shù)的值時，對象會直接在老年代分配內(nèi)存。

但是，雖然虛擬機規(guī)范中是有著這樣的要求，但是各個虛擬機廠商在實現(xiàn)虛擬機的時候，可能會針對對象的內(nèi)存分配做一些優(yōu)化。這其中最典型的就是HotSpot虛擬機中的JIT技術(shù)的成熟，使得對象在堆上分配內(nèi)存并不是一定的。


其實在《深入理解Java虛擬機》中，作者也提出過類似的觀點，因為JIT技術(shù)的成熟使得"對象在堆上分配內(nèi)存"就不是那么絕對的了。但是書中并沒有展開介紹到底什么是JIT，也沒有介紹JIT優(yōu)化到底做了什么。那么接下來我們就來深入了解一下：

JIT 技術(shù)

我們大家都知道，通過 javac 將可以將Java程序源代碼編譯，轉(zhuǎn)換成 java 字節(jié)碼，JVM
通過解釋字節(jié)碼將其翻譯成對應(yīng)的機器指令，逐條讀入，逐條解釋翻譯。這就是傳統(tǒng)的JVM的解釋器（Interpreter）的功能。很顯然，
Java編譯器經(jīng)過解釋執(zhí)行，其執(zhí)行速度必然會比直接執(zhí)行可執(zhí)行的二進制字節(jié)碼慢很多。為了解決這種效率問題，引入了 JIT（Just In Time ，即時編譯）
技術(shù)。

有了JIT技術(shù)之后，Java程序還是通過解釋器進行解釋執(zhí)行，當JVM發(fā)現(xiàn)某個方法或代碼塊運行特別頻繁的時候，就會認為這是“熱點代碼”（Hot Spot
Code)。然后JIT會把部分“熱點代碼”翻譯成本地機器相關(guān)的機器碼，并進行優(yōu)化，然后再把翻譯后的機器碼緩存起來，以備下次使用。

熱點檢測

上面我們說過，要想觸發(fā)JIT，首先需要識別出熱點代碼。目前主要的熱點代碼識別方式是熱點探測（Hot Spot
Detection），HotSpot虛擬機中采用的主要是基于計數(shù)器的熱點探測

基于計數(shù)器的熱點探測（Counter Based Hot Spot
Detection)。采用這種方法的虛擬機會為每個方法，甚至是代碼塊建立計數(shù)器，統(tǒng)計方法的執(zhí)行次數(shù)，某個方法超過閥值就認為是熱點方法，觸發(fā)JIT編譯。

編譯優(yōu)化

JIT在做了熱點檢測識別出熱點代碼后，除了會對其字節(jié)碼進行緩存，還會對代碼做各種優(yōu)化。這些優(yōu)化中，比較重要的幾個有：逃逸分析、 鎖消除、 鎖膨脹、
方法內(nèi)聯(lián)、 空值檢查消除、 類型檢測消除、 公共子表達式消除等。

而這些優(yōu)化中的逃逸分析就和本文要介紹的內(nèi)容有關(guān)了。

逃逸分析

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

逃逸分析的基本行為就是分析對象動態(tài)作用域：當一個對象在方法中被定義后，它可能被外部方法所引用，例如作為調(diào)用參數(shù)傳遞到其他地方中，稱為方法逃逸。

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

sb是一個方法內(nèi)部變量，上述代碼中并沒有將他直接返回，這樣這個StringBuffer有不會被其他方法所改變，這樣它的作用域就只是在方法內(nèi)部。我們就可以說這個變量并沒有逃逸到方法外部。

有了逃逸分析，我們可以判斷出一個方法中的變量是否有可能被其他線程所訪問或者改變，那么基于這個特性，JIT就可以做一些優(yōu)化：

* 同步省略
* 標量替換
* 棧上分配
關(guān)于同步省略，大家可以參考我之前的《深入理解多線程（五）—— Java虛擬機的鎖優(yōu)化技術(shù)》中關(guān)于鎖消除技術(shù)的介紹。本文主要來分析下標量替換和棧上分配。

標量替換、棧上分配


我們說，JIT經(jīng)過逃逸分析之后，如果發(fā)現(xiàn)某個對象并沒有逃逸到方法體之外的話，就可能對其進行優(yōu)化，而這一優(yōu)化最大的結(jié)果就是可能改變Java對象都是在堆上分配內(nèi)存的這一原則。

對象要分配在堆上其實有很多原因，但是有一點比較關(guān)鍵的和本文有關(guān)的，那就是因為堆內(nèi)存在訪問上是線程共享的，這樣一個線程創(chuàng)建出來的對象，其他線程也能訪問到。

那么，試想下，如果我們在某一個方法體內(nèi)部創(chuàng)建了一個對象，并且對象并沒有逃逸到方法外的話，那還有必要一定要把對象分配到堆上嗎？

其實就沒有必要了，因為這個對象并不會被其他線程所訪問到，生命周期也只是在一個方法內(nèi)部，也就不用大費周折的在堆上分配內(nèi)存，也減少了內(nèi)存回收的必要。

那么，有了逃逸分析之后，發(fā)現(xiàn)一個對象并沒有逃逸到放法外的話，通過什么辦法可以進行優(yōu)化，減少對象在堆上分配可能呢？

這就是棧上分配。在HotSopt中，棧上分配并沒有正在的進行實現(xiàn)，而是通過標量替換來實現(xiàn)的。

所以我們重點介紹下，什么是標量替換，如何通過標量替換實現(xiàn)棧上分配。

標量替換


標量（Scalar）是指一個無法再分解成更小的數(shù)據(jù)的數(shù)據(jù)。Java中的原始數(shù)據(jù)類型就是標量。相對的，那些還可以分解的數(shù)據(jù)叫做聚合量（Aggregate），Java中的對象就是聚合量，因為他可以分解成其他聚合量和標量。


在JIT階段，如果經(jīng)過逃逸分析，發(fā)現(xiàn)一個對象不會被外界訪問的話，那么經(jīng)過JIT優(yōu)化，就會把這個對象拆解成若干個其中包含的若干個成員變量來代替。這個過程就是標量替換。
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就會不會直接創(chuàng)建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這個聚合量經(jīng)過逃逸分析后，發(fā)現(xiàn)他并沒有逃逸，就被替換成兩個聚合量了。

通過標量替換，原本的一個對象，被替換成了多個成員變量。而原本需要在堆上分配的內(nèi)存，也就不再需要了，完全可以在本地方法棧中完成對成員變量的內(nèi)存分配。

實驗證明

Talk Is Cheap, Show Me The Code

No Data, No BB；

接下來我們就來通過一個實驗，來看一下逃逸分析是否可以生效，生效后是否真的會發(fā)生棧上分配，而棧上分配又有什么好處呢？

我們來看以下代碼：
public static void main(String[] args) { long a1 = System.currentTimeMillis();
for (int i = 0; i < 1000000; i++) { alloc(); } // 查看執(zhí)行時間 long a2 =
System.currentTimeMillis(); System.out.println("cost " + (a2 - a1) + " ms"); //
為了方便查看堆內(nèi)存中對象個數(shù)，線程sleep try { Thread.sleep(100000); } catch
(InterruptedException e1) { e1.printStackTrace(); } } private static void
alloc() { User user = new User(); } static class User { }
其實代碼內(nèi)容很簡單，就是使用for循環(huán)，在代碼中創(chuàng)建100萬個User對象。


我們在alloc方法中定義了User對象，但是并沒有在方法外部引用他。也就是說，這個對象并不會逃逸到alloc外部。經(jīng)過JIT的逃逸分析之后，就可以對其內(nèi)存分配進行優(yōu)化。

我們指定以下JVM參數(shù)并運行：
-Xmx4G -Xms4G -XX:-DoEscapeAnalysis -XX:+PrintGCDetails
-XX:+HeapDumpOnOutOfMemoryError
其中-XX:-DoEscapeAnalysis表示關(guān)閉逃逸分析。

在程序打印出 cost XX ms 后，代碼運行結(jié)束之前，我們使用jmap命令，來查看下當前堆內(nèi)存中有多少個User對象：
? ~ 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執(zhí)行結(jié)果中我們可以看到，堆中共創(chuàng)建了100萬個StackAllocTest$User實例。


在關(guān)閉逃避分析的情況下（-XX:-DoEscapeAnalysis），雖然在alloc方法中創(chuàng)建的User對象并沒有逃逸到方法外部，但是還是被分配在堆內(nèi)存中。也就說，如果沒有JIT編譯器優(yōu)化，沒有逃逸分析技術(shù)，正常情況下就應(yīng)該是這樣的。即所有對象都分配到堆內(nèi)存中。

接下來，我們開啟逃逸分析，再來執(zhí)行下以上代碼。
-Xmx4G -Xms4G -XX:+DoEscapeAnalysis -XX:+PrintGCDetails
-XX:+HeapDumpOnOutOfMemoryError
在程序打印出 cost XX ms 后，代碼運行結(jié)束之前，我們使用jmap命令，來查看下當前堆內(nèi)存中有多少個User對象：
? ~ 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

從以上打印結(jié)果中可以發(fā)現(xiàn)，開啟了逃逸分析之后（-XX:+DoEscapeAnalysis），在堆內(nèi)存中只有8萬多個StackAllocTest$User對象。也就是說在經(jīng)過JIT優(yōu)化之后，堆內(nèi)存中分配的對象數(shù)量，從100萬降到了8萬。


除了以上通過jmap驗證對象個數(shù)的方法以外，讀者還可以嘗試將堆內(nèi)存調(diào)小，然后執(zhí)行以上代碼，根據(jù)GC的次數(shù)來分析，也能發(fā)現(xiàn)，開啟了逃逸分析之后，在運行期間，GC次數(shù)會明顯減少。正是因為很多堆上分配被優(yōu)化成了棧上分配，所以GC次數(shù)有了明顯的減少。

逃逸分析并不成熟

前面的例子中，開啟逃逸分析之后，對象數(shù)目從100萬變成了8萬，但是并不是0，說明JIT優(yōu)化并不會完完全全的所有情況都進行優(yōu)化。

關(guān)于逃逸分析的論文在1999年就已經(jīng)發(fā)表了，但直到JDK 1.6才有實現(xiàn)，而且這項技術(shù)到如今也并不是十分成熟的。


其根本原因就是無法保證逃逸分析的性能消耗一定能高于他的消耗。雖然經(jīng)過逃逸分析可以做標量替換、棧上分配、和鎖消除。但是逃逸分析自身也是需要進行一系列復(fù)雜的分析的，這其實也是一個相對耗時的過程。

一個極端的例子，就是經(jīng)過逃逸分析之后，發(fā)現(xiàn)沒有一個對象是不逃逸的。那這個逃逸分析的過程就白白浪費掉了。

雖然這項技術(shù)并不十分成熟，但是他也是即時編譯器優(yōu)化技術(shù)中一個十分重要的手段。

總結(jié)

正常情況下，對象是要在堆上進行內(nèi)存分配的，但是隨著編譯器優(yōu)化技術(shù)的成熟，雖然虛擬機規(guī)范是這樣要求的，但是具體實現(xiàn)上還是有些差別的。


如HotSpot虛擬機引入了JIT優(yōu)化之后，會對對象進行逃逸分析，如果發(fā)現(xiàn)某一個對象并沒有逃逸到方法外部，那么就可能通過標量替換來實現(xiàn)棧上分配，而避免堆上分配內(nèi)存。

所以，對象一定在堆上分配內(nèi)存，這是不對的。

最后，我們留一個思考題，我們之前討論過了TLAB，今天又介紹了棧上分配。大家覺得這兩個優(yōu)化有什么相同點和不同點嗎？

• ? 上一篇：不要再寫這樣的神級代碼了！
• ? 下一篇：Head First設(shè)計模式——裝飾者模式