前言：最近在H大的公眾號(hào)學(xué)習(xí)了很多關(guān)于JVM相關(guān)的知識(shí)睡蟋，本文為學(xué)習(xí)總結(jié)啸驯，參考于公眾號(hào)：Hollis跪妥，原文標(biāo)題如下：
深入理解Java中的逃逸分析 | 文末送書

在Java的編譯體系中岳枷，一個(gè)Java的源代碼文件變成計(jì)算機(jī)可執(zhí)行的機(jī)器指令的過程中，需要經(jīng)過兩段編譯其馏，第一段是把.java文件轉(zhuǎn)換成.class文件凤跑。第二段編譯是把.class轉(zhuǎn)換成機(jī)器指令的過程。

第一段編譯就是javac命令叛复。

在第二編譯階段仔引，JVM 通過解釋字節(jié)碼將其翻譯成對(duì)應(yīng)的機(jī)器指令，逐條讀入褐奥，逐條解釋翻譯咖耘。很顯然，經(jīng)過解釋執(zhí)行撬码，其執(zhí)行速度必然會(huì)比可執(zhí)行的二進(jìn)制字節(jié)碼程序慢很多儿倒。這就是傳統(tǒng)的JVM的解釋器（Interpreter）的功能。為了解決這種效率問題，引入了 JIT（即時(shí)編譯） 技術(shù)夫否。

引入了 JIT 技術(shù)后彻犁，Java程序還是通過解釋器進(jìn)行解釋執(zhí)行，當(dāng)JVM發(fā)現(xiàn)某個(gè)方法或代碼塊運(yùn)行特別頻繁的時(shí)候凰慈，就會(huì)認(rèn)為這是“熱點(diǎn)代碼”（Hot Spot Code)汞幢。然后JIT會(huì)把部分“熱點(diǎn)代碼”翻譯成本地機(jī)器相關(guān)的機(jī)器碼，并進(jìn)行優(yōu)化微谓，然后再把翻譯后的機(jī)器碼緩存起來森篷，以備下次使用。

本文主要來介紹下JIT中的優(yōu)化豺型。JIT優(yōu)化中最重要的一個(gè)就是逃逸分析仲智。

逃逸分析

什么是逃逸分析？

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

例如以下代碼：

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對(duì)象作參數(shù)返回岩馍，傳遞到其他作用域)碉咆，而第二段代碼中的sb就沒有逃逸（返回的是sb.toString()抖韩，sb對(duì)象作用域沒有發(fā)生改變）。

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

一茂浮、同步省略。如果一個(gè)對(duì)象被發(fā)現(xiàn)只能從一個(gè)線程被訪問到壳咕，那么對(duì)于這個(gè)對(duì)象的操作可以不考慮同步席揽。

二、將堆分配轉(zhuǎn)化為棧分配谓厘。如果一個(gè)對(duì)象在子程序中被分配幌羞，要使指向該對(duì)象的指針永遠(yuǎn)不會(huì)逃逸，對(duì)象可能是棧分配的候選竟稳，而不是堆分配属桦。

三、分離對(duì)象或標(biāo)量替換他爸。有的對(duì)象可能不需要作為一個(gè)連續(xù)的內(nèi)存結(jié)構(gòu)存在也可以被訪問到聂宾，那么對(duì)象的部分（或全部）可以不存儲(chǔ)在內(nèi)存，而是存儲(chǔ)在CPU寄存器中诊笤。

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

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

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

同步省略

在動(dòng)態(tài)編譯同步塊的時(shí)候鄙煤，JIT編譯器可以借助逃逸分析來判斷同步塊所使用的鎖對(duì)象是否只能夠被一個(gè)線程訪問而沒有被發(fā)布到其他線程。

如果同步塊所使用的鎖對(duì)象通過這種分析被證實(shí)只能夠被一個(gè)線程訪問茶袒，那么JIT編譯器在編譯這個(gè)同步塊的時(shí)候就會(huì)取消對(duì)這部分代碼的同步馆类。這個(gè)取消同步的過程就叫同步省略，也叫鎖消除弹谁。

如下代碼：

public void f() {
    Object obj = new Object();
    synchronized(obj) {
        System.out.println(obj);
    }
}

代碼中對(duì)obj這個(gè)對(duì)象進(jìn)行加鎖乾巧，但是obj對(duì)象的生命周期只在f()方法中，并不會(huì)被其他線程所訪問到预愤，所以在JIT編譯階段就會(huì)被優(yōu)化掉沟于。優(yōu)化成：

public void f() {
    Object obj = new Object();
    System.out.println(hollis);
}

所以，在使用synchronized的時(shí)候植康，如果JIT經(jīng)過逃逸分析之后發(fā)現(xiàn)并無線程安全問題的話旷太，就會(huì)做鎖消除。

標(biāo)量替換

標(biāo)量（Scalar）是指一個(gè)無法再分解成更小的數(shù)據(jù)的數(shù)據(jù)销睁。Java中的原始數(shù)據(jù)類型就是標(biāo)量供璧。相對(duì)的，那些還可以分解的數(shù)據(jù)叫做聚合量（Aggregate）冻记，Java中的對(duì)象就是聚合量睡毒，因?yàn)樗梢苑纸獬善渌酆狭亢蜆?biāo)量。

在JIT階段冗栗，如果經(jīng)過逃逸分析演顾，發(fā)現(xiàn)一個(gè)對(duì)象不會(huì)被外界訪問的話，那么經(jīng)過JIT優(yōu)化隅居，就會(huì)把這個(gè)對(duì)象拆解成若干個(gè)其中包含的若干個(gè)成員變量來代替钠至。這個(gè)過程就是標(biāo)量替換。

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對(duì)象并沒有逃逸出alloc方法棉钧，并且point對(duì)象是可以拆解成標(biāo)量的。那么涕蚤，JIT就會(huì)不會(huì)直接創(chuàng)建Point對(duì)象宪卿，而是直接使用兩個(gè)標(biāo)量int x ，int y來替代Point對(duì)象赞季。

以上代碼愧捕，經(jīng)過標(biāo)量替換后，就會(huì)變成：

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

可以看到申钩，Point這個(gè)聚合量經(jīng)過逃逸分析后次绘，發(fā)現(xiàn)他并沒有逃逸，就被替換成兩個(gè)聚合量了。那么標(biāo)量替換有什么好處呢邮偎？就是可以大大減少堆內(nèi)存的占用管跺。因?yàn)橐坏┎恍枰獎(jiǎng)?chuàng)建對(duì)象了，那么就不再需要分配堆內(nèi)存了禾进。

標(biāo)量替換為棧上分配提供了很好的基礎(chǔ)豁跑。

棧上分配

在Java虛擬機(jī)中，對(duì)象是在Java堆中分配內(nèi)存的泻云，這是一個(gè)普遍的常識(shí)艇拍。但是，有一種特殊情況宠纯，那就是如果經(jīng)過逃逸分析后發(fā)現(xiàn)卸夕，一個(gè)對(duì)象并沒有逃逸出方法的話，那么就可能被優(yōu)化成棧上分配婆瓜。這樣就無需在堆上分配內(nèi)存快集，也無須進(jìn)行垃圾回收了(對(duì)象生命期跟隨著線程的生命期，線程結(jié)束后對(duì)象自動(dòng)回收)

關(guān)于逃逸分析

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

其根本原因就是無法保證逃逸分析的性能消耗一定能高于他的消耗猴蹂。雖然經(jīng)過逃逸分析可以做標(biāo)量替換院溺、棧上分配、和鎖消除晕讲。但是逃逸分析自身也是需要進(jìn)行一系列復(fù)雜的分析的覆获，這其實(shí)也是一個(gè)相對(duì)耗時(shí)的過程。

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

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

感謝你的閱讀~ O(∩_∩)O~