深入淺出逃逸分析：提升程序性能的利器
逃逸分析技術算是在JVM面試題偶有提及的一個考察點，當然如果你能夠講解JVM工作原理的時候提及這一點，這一定會增加面試官對你的好感，本文主題內容如下:
- 什么是逃逸分析技術？
- 逃逸分析技術解決什么問題？帶來什么好處？
- 如何更好的理解或者運用逃逸分析技術？
一、什么是逃逸分析
逃逸分析技術是JVM用于提高性能以及節省內存的手段，在JVM編譯語境下也就是我們常說的JIT階段，逃逸分析技術通過以下兩個條件判斷該對象是否是逃逸:
- 該對象是否分配在堆上(static關鍵字或者成員變量)。
- 該對象是否會傳給未知代碼，比如return到外部給別的類使用。
只要編譯階段判定當前對象并沒有發生逃逸，那么它就會采用棧上分配、標量替換、同步鎖消除等手段提升程序執行性能和節省內存開銷。
那么我們又該如何判斷對象是否逃逸呢？我們不妨基于上述的判斷條件來看看這個示例，假設我們現在有一個user類:
@Data
public class User {
private int id;
private String name;
}我們通過UserService進行初始化，那么請問這段代碼是否發生逃逸呢？
public class UserService {
private User user;
public void init() {
user = new User();
user.setId(RandomUtil.randomInt(10));
user.setName(RandomUtil.randomString(3));
}
}答案當然是肯定的，因為這段代碼會被外部的其他任意線程操作。
再來看看這段代碼，典型的return語句，很明顯的外部線程可以直接操作這個對象，所以這個對象也發生了逃逸，所以針對這幾種情況JIT都無法對其進行優化。
public User createUser() {
User user = new User();
user.setId(RandomUtil.randomInt(10));
user.setName(RandomUtil.randomString(3));
return user;
}二、如何運用到逃逸分析技術
1.棧上分配
一般來說，JIT即時編譯技術中的棧上分配和標量替換基本都是同時出現的，按照上文所述，假如上述代碼所返回的user對象僅僅是獲取當前用戶的年齡，那么我們就可以直接在方法內完成邏輯計算并直接返回，這樣對象就沒有發生逃逸，如此對象便可直接在棧幀上進行分配，有效減小JVM垃圾回收的壓力。
Map<Integer, User> userMap = new HashMap<>();
public int getUserAgeById(int id) {
User user = new User();
user.setId(RandomUtil.randomInt(10));
user.setName(RandomUtil.randomString(3));
//打印用戶信息
printUserInfo(user);
}2.分離對象或標量替換
如果僅僅是操作未逃逸對象的某些簡單運算，我們同樣可以只在棧幀內使用這個對象，如此JVM就會將這個對象打散，將對象打散為無數個小的局部變量，實現標量替換，如下所示，這段代碼沒有發生逃逸，則JVM會避免創建Point 。
public static void main(String args[]) {
alloc();
}
class Point {
private int x;
private int y;
}
private static void alloc() {
Point point = new Point(1,2);
System.out.println("point.x" + point.x + ";point.y" + point.y);
}進而直接標量替換，直接在棧上分配x和y的值，完成輸出打印。
private static void alloc() {
int x = 1;
int y = 2;
System.out.println("point.x = " + x + "; point.y=" + y);
}3.同步鎖消除
這一點就比較有趣了，我們都知道使用StringBuffer可以保證線程安全，因為其操作函數都有帶synchronized關鍵字，那么請問這段代碼會上鎖嗎？
public void appendStr(int count) {
StringBuffer sb = new StringBuffer();
for (int i = 0; i < count; i++) {
sb.append("no: " + i + " ");
}
}答案是不會，因為我們當前操作的StringBuffer 對象并沒有發生逃逸，它僅僅是根據外部傳入的count完成拼接并打印結果而已，于是JIT就會進行鎖消除的優化操作。如下字節碼所示，優化后的StringBuffer被替換為StringBuilder。
三、逃逸分析更進一步
了解了逃逸分析止之后，我們不妨基于下面這些題目進行一下自測，如下代碼，請問實例方法調用靜態方法，StringBuffer作為變量傳入，是否發生逃逸，最終執行代碼是StringBuffer 還是StringBuilder？
public void appendStr(int count) {
StringBuffer sb = new StringBuffer();
loop(count, sb);
}
private static void loop(int count, StringBuffer sb) {
for (int i = 0; i < count; i++) {
sb.append("no: " + i + " ");
}
}答案是未發生逃逸，因為對象并沒有被外部線程操作，JIT感知到未發生逃逸，所以將StringBuffer 轉為StringBuilder。
再來看看這段代碼，請問發生逃逸了嗎？
public void appendStr(int count) {
StringBuffer sb = new StringBuffer();
loop(count, sb);
}
private static String loop(int count, StringBuffer sb) {
for (int i = 0; i < count; i++) {
sb.append("no: " + i + " ");
}
return sb.toString();
}答案還是沒有，返回的字符串還是沒有被外部線程操作，所以最終還是被轉為StringBuilder:
四、小結
合理的在棧幀上解決問題可以避免對象逃逸，從而讓JIT盡可能的去進行優化，這一點我想應該是一個Java程序員對于代碼的極致追求了。
