一、JVM程序執(zhí)行流程

上一章我們介紹過程序執(zhí)行通常分為解釋執(zhí)行和編譯執(zhí)行，而Java兩種方式都采用了，下面是Java編譯成字節(jié)碼、動態(tài)編譯和解釋為機器碼的過程分析：

編譯器和解釋器的協(xié)調(diào)工作流程：

• 判斷是否是熱點代碼，不是則逐行解釋每條代碼，翻譯成機器碼執(zhí)行，否則一次性編譯成機器碼存到方法區(qū)，以后每次直接運行機器碼

• JIT優(yōu)化，可以控制判斷是否是熱點代碼的條件，默認(rèn)一段代碼（方法、或循環(huán)體）被調(diào)用10000次以上被認(rèn)為是熱點代碼

• JIT編譯的Hot熱點代碼通常是以方法為單位的，最小單位可能是for循環(huán)的一段代碼

在部分商用虛擬機中（如HotSpot），Java程序最初是通過解釋器（Interpreter）進行解釋執(zhí)行的，當(dāng)虛擬機發(fā)現(xiàn)某個方法或代碼塊的運行特別頻繁時，就會把這些代碼認(rèn)定為“熱點代碼”。為了提高熱點代碼的執(zhí)行效率，在運行時，虛擬機將會把這些代碼編譯成與本地平臺相關(guān)的機器碼，并進行各種層次的優(yōu)化，完成這個任務(wù)的編譯器稱為即時編譯器（Just In Time Compiler，下文統(tǒng)稱JIT編譯器）。

解釋執(zhí)行：一段代碼，解釋一行執(zhí)行一行
編譯執(zhí)行：事先已經(jīng)編譯成機器碼，直接執(zhí)行即可，不用解釋

由于Java虛擬機規(guī)范并沒有具體的約束規(guī)則去限制即時編譯器應(yīng)該如何實現(xiàn)，所以這部分功能完全是與虛擬機具體實現(xiàn)相關(guān)的內(nèi)容，如無特殊說明，我們提到的編譯器、即時編譯器都是指Hotspot虛擬機內(nèi)的即時編譯器，虛擬機也是特指HotSpot虛擬機。

我們的JIT是屬于動態(tài)編譯方式的，動態(tài)編譯（dynamic compilation）指的是“在運行時進行編譯”；與之相對的是事前編譯（ahead-of-time compilation，簡稱AOT），也叫靜態(tài)編譯（static compilation）。

JIT編譯（just-in-time compilation）狹義來說是當(dāng)某段代碼即將第一次被執(zhí)行時進行編譯，因而叫“即時編譯”。JIT編譯是動態(tài)編譯的一種特例。JIT編譯一詞后來被泛化，時常與動態(tài)編譯等價；但要注意廣義與狹義的JIT編譯所指的區(qū)別。

JIT動態(tài)編譯，只是在運行時把某一部分代碼進行動態(tài)編譯，不是把所有代碼全部編譯成機器碼，哪些代碼進行動態(tài)編譯有一個衡量標(biāo)準(zhǔn)

熱點代碼編譯成機器碼后會保存到方法區(qū)

1.1 哪些程序代碼會被即時編譯

程序中的代碼只有是熱點代碼時，才會編譯為本地代碼，那么什么是熱點代碼呢？

運行過程中會被即時編譯器編譯的“熱點代碼”有兩類：

被多次調(diào)用的方法。

被多次執(zhí)行的循環(huán)體。

兩種情況，編譯器都是以整個方法作為編譯對象。 這種編譯方法因為編譯發(fā)生在方法執(zhí)行過程之中，因此形象的稱之為棧上替換（On Stack Replacement，OSR），即方法棧幀還在棧上，方法就被替換了。

1.2 如何判斷熱點代碼呢

要知道方法或一段代碼是不是熱點代碼，是不是需要觸發(fā)即時編譯，需要進行Hot Spot Detection（熱點探測）。

目前主要的熱點探測方式有以下兩種：

• 基于采樣的熱點探測
  采用這種方法的虛擬機會周期性地檢查各個線程的棧頂，如果發(fā)現(xiàn)某些方法經(jīng)常出現(xiàn)在棧頂，那這個方法就是“熱點方法”。這種探測方法的好處是實現(xiàn)簡單高效，還可以很容易地獲取方法調(diào)用關(guān)系（將調(diào)用堆棧展開即可），缺點是很難精確地確認(rèn)一個方法的熱度，容易因為受到線程阻塞或別的外界因素的影響而擾亂熱點探測。
• 基于計數(shù)器的熱點探測
  采用這種方法的虛擬機會為每個方法（甚至是代碼塊）建立計數(shù)器，統(tǒng)計方法的執(zhí)行次數(shù)，如果執(zhí)行次數(shù)超過一定的閥值，就認(rèn)為它是“熱點方法”。這種統(tǒng)計方法實現(xiàn)復(fù)雜一些，需要為每個方法建立并維護計數(shù)器，而且不能直接獲取到方法的調(diào)用關(guān)系，但是它的統(tǒng)計結(jié)果相對更加精確嚴(yán)謹(jǐn)。

1.3 熱點檢測方式

在HotSpot虛擬機中使用的是第二種——基于計數(shù)器的熱點探測方法，因此它為每個方法準(zhǔn)備了兩個計數(shù)器：方法調(diào)用計數(shù)器和回邊計數(shù)器。在確定虛擬機運行參數(shù)的前提下，這兩個計數(shù)器都有一個確定的閾值，當(dāng)計數(shù)器超過閾值溢出了，就會觸發(fā)JIT編譯。

1.3.1 方法調(diào)用計數(shù)器

顧名思義，這個計數(shù)器用于統(tǒng)計方法被調(diào)用的次數(shù)。

• 在JVM client模式下的閥值是1500次，Server是10 000次。可以通過虛擬機參數(shù)： -XX：CompileThreshold設(shè)置。
• 但是JVM還存在熱度衰減，時間段內(nèi)調(diào)用方法的次數(shù)較少，計數(shù)器就減小。
• 半衰期：如果計數(shù)器在一定時間范圍內(nèi)始終沒有達到閾值，下一次周期計數(shù)開始，計數(shù)起始值直接為閾值一半
• 向編譯器提交編譯請求是異步并行方式

1.3.2 回邊計數(shù)器

它的作用就是統(tǒng)計一個方法中循環(huán)體代碼執(zhí)行的次數(shù)，在字節(jié)碼中遇到控制流向后跳轉(zhuǎn)的指令稱為“回邊”。

二、理解JIT編譯器

通過以下問題來了解JIT編譯器

• 為何HotSpot需要使用解釋器和編譯器并存的架構(gòu)？
• JVM為什么要實現(xiàn)兩個不同的即時編譯器？
• 程序何時會使用解釋器執(zhí)行？何時會使用編譯器執(zhí)行？
• 哪些程序代碼會被編譯成為本地代碼？如何編譯？
• JAVA代碼的執(zhí)行效率就一定比C，C++靜態(tài)執(zhí)行的執(zhí)行差？JAVA代碼解析執(zhí)行有何優(yōu)勢？

2.1 為什么要使用解釋器與編譯器并存的架構(gòu)

盡管并不是所有的Java虛擬機都采用解釋器與編譯器并存的架構(gòu)，但許多主流的商用虛擬機（如HotSpot），都同時包含解釋器和編譯器。

解釋器沒有編譯成本，編譯需要花時間和空間，雖然只需要編譯一次
解釋器不需要占用空間，缺點在于，相對于直接執(zhí)行機器碼需要消耗更多的時間
空間換時間的思想

2.1.1 解釋器與編譯器特點

• 當(dāng)程序需要迅速啟動和執(zhí)行的時候，解釋器可以首先發(fā)揮作用，省去編譯的時間，立即執(zhí)行。在程序運行后，隨著時間的推移，編譯器逐漸發(fā)揮作用，把越來越多的代碼編譯成本地代碼之后，可以獲取更高的執(zhí)行效率。
• 當(dāng)程序運行環(huán)境中內(nèi)存資源限制較大（如部分嵌入式系統(tǒng)中，安卓），可以使用解釋器執(zhí)行節(jié)約內(nèi)存，反之可以使用編譯執(zhí)行來提升效率。

2.1.2 編譯的時間開銷

解釋器的執(zhí)行，抽象的看是這樣的：
輸入的代碼 -> [ 解釋器 解釋執(zhí)行 ] -> 執(zhí)行結(jié)果

而要JIT編譯然后再執(zhí)行的話，抽象的看則是：
輸入的代碼 -> [ 編譯器 編譯 ] -> 編譯后的代碼 -> [ 執(zhí)行 ] -> 執(zhí)行結(jié)果

說JIT比解釋快，其實說的是“執(zhí)行編譯后的代碼”比“解釋器解釋執(zhí)行”要快，并不是說“編譯”這個動作比“解釋”這個動作快。JIT編譯再怎么快，至少也比解釋執(zhí)行一次略慢一些，而要得到最后的執(zhí)行結(jié)果還得再經(jīng)過一個“執(zhí)行編譯后的代碼”的過程。所以，對“只執(zhí)行一次”的代碼而言，解釋執(zhí)行其實總是比JIT編譯執(zhí)行要快。

怎么算是“只執(zhí)行一次的代碼”呢？粗略說，下面兩個條件同時滿足時就是嚴(yán)格的“只執(zhí)行一次”

• 1、只被調(diào)用一次，例如類的構(gòu)造器（class initializer()）
• 2、沒有循環(huán)

對只執(zhí)行一次的代碼做JIT編譯再執(zhí)行，可以說是得不償失。
對只執(zhí)行少量次數(shù)的代碼，JIT編譯帶來的執(zhí)行速度的提升也未必能抵消掉最初編譯帶來的開銷。
只有對頻繁執(zhí)行的代碼，JIT編譯才能保證有正面的收益。

2.1.3 編譯的空間開銷

對一般的Java方法而言，編譯后代碼的大小相對于字節(jié)碼的大小，膨脹比達到10x是很正常的。同上面說的時間開銷一樣，這里的空間開銷也是，只有對執(zhí)行頻繁的代碼才值得編譯，如果把所有代碼都編譯則會顯著增加代碼所占空間，導(dǎo)致“代碼爆炸”。

這也就解釋了為什么有些JVM會選擇不總是做JIT編譯，而是選擇用解釋器+JIT編譯器的混合執(zhí)行引擎。

2.2 為何要實現(xiàn)兩個不同的即時編譯器

HotSpot虛擬機中內(nèi)置了兩個即時編譯器：Client Complier和Server Complier，簡稱為C1、C2編譯器，分別用在客戶端和服務(wù)端。

目前主流的HotSpot虛擬機中默認(rèn)是采用解釋器與其中一個編譯器直接配合的方式工作。程序使用哪個編譯器，取決于虛擬機運行的模式。HotSpot虛擬機會根據(jù)自身版本與宿主機器的硬件性能自動選擇運行模式，用戶也可以使用“-client”或“-server”參數(shù)去強制指定虛擬機運行在Client模式或Server模式。

用Client Complier獲取更高的編譯速度，用Server Complier 來獲取更好的編譯質(zhì)量（例如 JIT優(yōu)化）。為什么提供多個即時編譯器與為什么提供多個垃圾收集器類似，都是為了適應(yīng)不同的應(yīng)用場景。

編譯質(zhì)量的意思就是在編譯過程中會進行優(yōu)化，Client Complier優(yōu)化的少，Server Complier優(yōu)化的多，優(yōu)化多則啟動慢

2.3 如何編譯為本地代碼？

Server Compiler和Client Compiler兩個編譯器的編譯過程是不一樣的。

對Client Compiler來說，它是一個簡單快速的編譯器，主要關(guān)注點在于局部優(yōu)化，而放棄許多耗時較長的全局優(yōu)化手段。

而Server Compiler則是專門面向服務(wù)器端的，并為服務(wù)端的性能配置特別調(diào)整過的編譯器，是一個充分優(yōu)化過的高級編譯器。

三、JIT優(yōu)化

HotSpot 虛擬機使用了很多種優(yōu)化技術(shù)，這里只簡單介紹其中的幾種，完整的優(yōu)化技術(shù)介紹可以參考官網(wǎng)內(nèi)容。

JIT編譯優(yōu)化，不是在javac命令編譯優(yōu)化，是在jvm運行期間的優(yōu)化策略

3.1 公共子表達式的消除

公共子表達式消除是一個普遍應(yīng)用于各種編譯器的經(jīng)典優(yōu)化技術(shù)，他的含義是：如果一個表達式E已經(jīng)計算過了，并且從先前的計算到現(xiàn)在E中所有變量的值都沒有發(fā)生變化，那么E的這次出現(xiàn)就成為了公共子表達式。對于這種表達式，沒有必要花時間再對他進行計算，只需要直接用前面計算過的表達式結(jié)果代替E就可以了。

• 如果這種優(yōu)化僅限于程序的基本塊內(nèi)，便稱為局部公共子表達式消除（Local Common Subexpression Elimination）
• 如果這種優(yōu)化范圍涵蓋了多個基本塊，那就稱為全局公共子表達式消除（Global Common Subexpression Elimination）。

舉個簡單的例子來說明他的優(yōu)化過程，假設(shè)存在如下代碼：

int d = (c*b)*12+a+(a+b*c);

注意只有多次調(diào)用發(fā)現(xiàn)c和b都是一個值才會把b*c的結(jié)果緩存

如果這段代碼交給Javac編譯器則不會進行任何優(yōu)化，那生成的代碼如下所示，是完全遵照J(rèn)ava源碼的寫法直譯而成的。

iload_2 // b imul // 計算b*c bipush 12 // 推入12 imul // 計算(c*b)*12 iload_1 // a iadd // 計算(c*b)*12+a iload_1 // a iload_2 // b iload_3 // c imul // 計算b*c iadd // 計算a+b*c iadd // 計算(c*b)*12+a+(a+b*c) istore 4

當(dāng)這段代碼進入到虛擬機即時編譯器后，他將進行如下優(yōu)化：編譯器檢測到”cb“與”bc“是一樣的表達式，而且在計算期間b與c的值是不變的。因此，這條表達式就可能被視為：

int d = E*12+a+(a+E);

這時，編譯器還可能（取決于哪種虛擬機的編譯器以及具體的上下文而定）進行另外一種優(yōu)化：代數(shù)化簡（Algebraic Simplification），把表達式變?yōu)?#xff1a;

int d = E*13+a*2;

表達式進行變換之后，再計算起來就可以節(jié)省一些時間了。

由于E已經(jīng)是被計算之后的結(jié)果，因此可以直接替換成一個常量值

變量和常量的操作不同，常量可以直接壓入到局部變量表，而變量先要取到操作棧，再從操作棧取出來存儲到局部變量表

3.2 方法內(nèi)聯(lián)

JVM中如何執(zhí)行方法：

• 結(jié)構(gòu)：方法區(qū)中class對象的方法在class文件加載到方法區(qū)時將符號引用解析為直接引用，指向method對象（Field對象類似），method對象除了有自己的地址外，有一個code區(qū)專門存放要執(zhí)行的字節(jié)碼指令
• 執(zhí)行流程：線程執(zhí)行方法的時候，會先讀取class對象信息，再從class信息獲取到要執(zhí)行的方法地址，然后把方法形成棧幀壓入到棧，方法執(zhí)行過程中內(nèi)部如果又調(diào)用其他方法以此類推將需要執(zhí)行的方法壓入棧里，棧頂?shù)姆椒ň褪钦趫?zhí)行的方法，一旦某一個方法執(zhí)行完了就會彈棧

如果方法調(diào)用很多的話，方法入棧出棧的操作也會很多，棧會很深，對應(yīng)性能損耗也很多

在使用JIT進行即時編譯時，將方法調(diào)用直接使用方法體中的代碼進行替換，這就是方法內(nèi)聯(lián)，減少了方法調(diào)用過程中壓棧與入棧的開銷。同時為之后的一些優(yōu)化手段提供條件。如果JVM監(jiān)測到一些小方法被頻繁的執(zhí)行，它會把方法的調(diào)用替換成方法體本身。

比如說下面這個：

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; }

可以有效防止棧溢出，以及方法調(diào)用過程中壓棧與入棧的開銷

3.3 逃逸分析

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

同步負(fù)載：指的是加鎖synchronized的壓力
內(nèi)存堆分配：堆里面分配對象

算法具體實現(xiàn)不用深究，只要知道逃逸分析能夠帶來的效果即可。

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

對象不能被外部訪問，則沒有逃逸，沒有逃逸可以進行一系列優(yōu)化，主要有三種優(yōu)化策略，即后面講的三種都是建立在逃逸分析之后的結(jié)論進行優(yōu)化的

逃逸分析包括：

• 全局變量賦值逃逸
• 方法返回值逃逸
• 實例引用發(fā)生逃逸
• 線程逃逸:賦值給類變量或可以在其他線程中訪問的實例變量

例如：

public class EscapeAnalysis {//全局變量public static Object object;public void globalVariableEscape(){//全局變量賦值逃逸,即全局變量能夠被外部訪問object = new Object();}public Object methodEscape(){ //方法返回值逃逸，即返回值能夠被外部訪問return new Object();}public void instancePassEscape(){ //實例引用發(fā)生逃逸，即實例引用能夠被外部訪問this.speak(this);}public void speak(EscapeAnalysis escapeAnalysis){System.out.println("Escape Hello");} }

只要一個方法里面的對象，它的生命周期沒有超過方法范圍，則稱為該對象沒有逃逸出這個方法

• 使用方法逃逸的案例進行分析：

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

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

  上述代碼如果想要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將不會逃逸出方法。

使用逃逸分析，編譯器可以對代碼做如下優(yōu)化：

• 一、同步省略。如果一個對象被發(fā)現(xiàn)只能從一個線程被訪問到，那么對于這個對象的操作可以不考慮同步。
• 二、將堆內(nèi)存分配轉(zhuǎn)化為棧內(nèi)存分配。如果一個對象在子程序中被分配，要使指向該對象的指針永遠不會逃逸，對象可能是棧分配的候選，而不是堆分配。
• 三、分離對象或標(biāo)量替換。有的對象可能不需要作為一個連續(xù)的內(nèi)存結(jié)構(gòu)存在也可以被訪問到，那么對象的部分（或全部）可以不存儲在內(nèi)存，而是存儲在CPU寄存器中。

在Java代碼運行時，通過JVM參數(shù)可指定是否開啟逃逸分析

-XX:+DoEscapeAnalysis ： 表示開啟逃逸分析
-XX:-DoEscapeAnalysis ： 表示關(guān)閉逃逸分析

從jdk 1.7開始已經(jīng)默認(rèn)開啟逃逸分析，如需關(guān)閉，需要指定 -XX:-DoEscapeAnalysis

3.4 對象的棧上內(nèi)存分配

我們知道，在一般情況下，對象和數(shù)組元素的內(nèi)存分配是在堆內(nèi)存上進行的。但是隨著JIT編譯器的日漸成熟，很多優(yōu)化使這種分配策略并不絕對。JIT編譯器就可以在編譯期間根據(jù)逃逸分析的結(jié)果，來決定是否可以將對象的內(nèi)存分配從堆轉(zhuǎn)化為棧。

我們來看以下代碼：

public class EscapeAnalysisTest {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ù)，線程sleeptry {Thread.sleep(100000);} catch (InterruptedException e1) {e1.printStackTrace();}}// 此方法內(nèi)的User對象，未發(fā)生逃逸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

在程序打印出 cost XX ms 后，代碼運行結(jié)束之前，我們使用jmap命令，來查看下當(dāng)前堆內(nèi)存中有多少個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執(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 命令，來查看下當(dāng)前堆內(nèi)存中有多少個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

• 從以上打印結(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ù)有了明顯的減少。

并不是完全都在棧上內(nèi)存分配，因為棧上內(nèi)存分配也有可能把棧內(nèi)存空間撐滿了

另外逃逸分析是建立在JIT編譯的時候，而JIT編譯只會針對熱點代碼，默認(rèn)執(zhí)行1W次以上的方法或循環(huán)體

總結(jié)
所以，如果以后再有人問你：是不是所有的對象和數(shù)組都會在堆內(nèi)存分配空間？

那么你可以告訴他：不一定，隨著JIT編譯器的發(fā)展，在編譯期間，如果JIT經(jīng)過逃逸分析，發(fā)現(xiàn)有些對象沒有逃逸出方法，那么有可能堆內(nèi)存分配會被優(yōu)化成棧內(nèi)存分配。但是這也并不是絕對的。就像我們前面看到的一樣，在開啟逃逸分析之后，也并不是所有User對象都沒有在堆上分配。

3.5 標(biāo)量替換

標(biāo)量（Scalar）是指一個無法再分解成更小的數(shù)據(jù)的數(shù)據(jù) 。

標(biāo)量就是 基本數(shù)據(jù)類型 和 引用類型，相反就是聚集量，指對象
標(biāo)量替換的意思就是將對象拆解成多個標(biāo)量進行存儲

好處，首先看下對象的布局，對象在堆里面有三塊布局區(qū)域：

• 對象頭
• 實例數(shù)據(jù)區(qū)域
• 對齊填充

我們可能真正需要的只有實例數(shù)據(jù)區(qū)域的數(shù)據(jù)，但是另外兩塊也占據(jù)內(nèi)存，但是都沒用到 對象用被標(biāo)量替換后，就相當(dāng)于只需有實例空間內(nèi)存區(qū)域就行了，而且這塊內(nèi)存區(qū)域也不在堆里面 而在棧里面，減輕gc回收壓力

在JIT階段，如果經(jīng)過逃逸分析，發(fā)現(xiàn)一個對象不會被外界訪問的話，那么經(jīng)過JIT優(yōu)化，就會把這個對象拆解成若干個其中包含的若干個成員變量來代替。

//有一個類A public class A{public int a=1;public int b=2 } //方法getAB使用類A里面的a，b private void getAB(){A x = new A();x.a;x.b; } //JVM在編譯的時候會直接編譯成 private void getAB(){a = 1;b = 2; }

這就是標(biāo)量替換

有效降低內(nèi)存消耗

3.6 同步鎖消除

同樣基于逃逸分析，當(dāng)加鎖的變量不會發(fā)生逃逸，是線程私有的完全沒有必要加鎖。在JIT編譯時期就可以將同步鎖去掉，以減少加鎖與解鎖造成的資源開銷。

public class TestLockEliminate {public static String getString(String s1， String s2) {StringBuffer sb = new StringBuffer();sb.append(s1);sb.append(s2);return sb.toString();}public static void main(String[] args) {long tsStart = System.currentTimeMillis();for (int i = 0; i < 100000000; i++) {getString("TestLockEliminate "， "Suffix");}System.out.println("一共耗費：" + (System.currentTimeMillis() - tsStart) + " ms");} }

getString()方法中的StringBuffer是函數(shù)內(nèi)部的局部變量，作用于方法內(nèi)部，不可能逃逸出該方法，因此他就不可能被多個線程同時訪問，也就沒有資源的競爭，但是StringBuffer的append操作卻需要執(zhí)行同步操作，代碼如下:

@Override public synchronized StringBuffer append(String str) {toStringCache = null;super.append(str);return this; }

逃逸分析和鎖消除分別可以使用參數(shù) -XX:+DoEscapeAnalysis 和 -XX:+EliminateLocks (鎖消除必須在-server模式下)開啟。使用如下參數(shù)運行上面的程序：

-XX:+DoEscapeAnalysis -XX:-EliminateLocks

得到如下結(jié)果：

使用如下命令運行程序：

-XX:+DoEscapeAnalysis -XX:+EliminateLocks

得到如下結(jié)果：

總結(jié)

以上是生活随笔為你收集整理的JVM原理（二）执行引擎篇（JVM程序执行流程、JIT编译器、JIT编译器优化）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。