public static StringBuffer craeteStringBuffer(String s1, String s2) {
StringBuffer sb = new StringBuffer();
sb.append(s1);
sb.append(s2);
return sb;
}
StringBuffer sb是一個方法內部變量,上述代碼中直接將sb返回,這樣這個StringBuffer有可能被其他方法所改變,這樣它的作用域就不只是在方法內部,雖然它是一個局部變量,稱其逃逸到了方法外部。甚至還有可能被外部線程訪問到,譬如賦值給類變量或可以在其他線程中訪問的實例變量,稱爲線程逃逸。
上述代碼如果想要StringBuffer sb不逃出方法,可以這樣寫:
public static String createStringBuffer(String s1, String s2) {
StringBuffer sb = new StringBuffer();
sb.append(s1);
sb.append(s2);
return sb.toString();
}
使用逃逸分析,編譯器可以對代碼做如下優化:
一、同步省略。如果一個對象被發現只能從一個線程被訪問到,那麼對於這個對象的操作可以不考慮同步。
二、將堆分配轉化爲棧分配。如果一個對象在子程序中被分配,要使指向該對象的指針永遠不會逃逸,對象可能是棧分配的候選,而不是堆分配。
三、分離對象或標量替換。有的對象可能不需要作爲一個連續的內存結構存在也可以被訪問到,那麼對象的部分(或全部)可以不存儲在內存,而是存儲在CPU寄存器中。
上面的關於同步省略的內容,我在《深入理解多線程(五)—— Java虛擬機的鎖優化技術》中有介紹過,即鎖優化中的鎖消除技術,依賴的也是逃逸分析技術。
本文,主要來介紹逃逸分析的第二個用途:將堆分配轉化爲棧分配。
其實,以上三種優化中,棧上內存分配其實是依靠標量替換來實現的。由於不是本文重點,這裏就不展開介紹了。如果大家感興趣,我後面專門出一篇文章,全面介紹下逃逸分析。
在Java代碼運行時,通過JVM參數可指定是否開啓逃逸分析,
-XX:+DoEscapeAnalysis
: 表示開啓逃逸分析
-XX:-DoEscapeAnalysis
: 表示關閉逃逸分析
從jdk 1.7開始已經默認開始逃逸分析,如需關閉,需要指定-XX:-DoEscapeAnalysis
對象的棧上內存分配
我們知道,在一般情況下,對象和數組元素的內存分配是在堆內存上進行的。但是隨着JIT編譯器的日漸成熟,很多優化使這種分配策略並不絕對。JIT編譯器就可以在編譯期間根據逃逸分析的結果,來決定是否可以將對象的內存分配從堆轉化爲棧。
我們來看以下代碼:
public static void main(String[] args) {
long a1 = System.currentTimeMillis();
for (int i = 0; i < 1000000; i++) {
alloc();
}
// 查看執行時間
long a2 = System.currentTimeMillis();
System.out.println("cost " + (a2 - a1) + " ms");
// 爲了方便查看堆內存中對象個數,線程sleep
try {
Thread.sleep(100000);
} catch (InterruptedException e1) {
e1.printStackTrace();
}
}
private static void alloc() {
User user = new User();
}
static class User {
}
其實代碼內容很簡單,就是使用for循環,在代碼中創建100萬個User對象。
我們在alloc方法中定義了User對象,但是並沒有在方法外部引用他。也就是說,這個對象並不會逃逸到alloc外部。經過JIT的逃逸分析之後,就可以對其內存分配進行優化。
-Xmx4G -Xms4G -XX:-DoEscapeAnalysis -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError
在程序打印出 cost XX ms
後,代碼運行結束之前,我們使用[jmap][1]
命令,來查看下當前堆內存中有多少個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
開啓逃逸分析後:
-Xmx4G -Xms4G -XX:+DoEscapeAnalysis -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError
➜ ~ 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
從以上打印結果中可以發現,開啓了逃逸分析之後(-XX:+DoEscapeAnalysis),在堆內存中只有8萬多個StackAllocTest$User
對象。也就是說在經過JIT優化之後,堆內存中分配的對象數量,從100萬降到了8萬。
除了以上通過jmap驗證對象個數的方法以外,讀者還可以嘗試將堆內存調小,然後執行以上代碼,根據GC的次數來分析,也能發現,開啓了逃逸分析之後,在運行期間,GC次數會明顯減少。正是因爲很多堆上分配被優化成了棧上分配,所以GC次數有了明顯的減少。
總結
所以,如果以後再有人問你:是不是所有的對象和數組都會在堆內存分配空間?
那麼你可以告訴他:不一定,隨着JIT編譯器的發展,在編譯期間,如果JIT經過逃逸分析,發現有些對象沒有逃逸出方法,那麼有可能堆內存分配會被優化成棧內存分配。但是這也並不是絕對的。就像我們前面看到的一樣,在開啓逃逸分析之後,也並不是所有User對象都沒有在堆上分配。
關於逃逸分析的論文在1999年就已經發表了,但直到JDK 1.6纔有實現,而且這項技術到如今也並不是十分成熟的。
其根本原因就是無法保證逃逸分析的性能消耗一定能高於他的消耗。雖然經過逃逸分析可以做標量替換、棧上分配、和鎖消除。但是逃逸分析自身也是需要進行一系列複雜的分析的,這其實也是一個相對耗時的過程。
一個極端的例子,就是經過逃逸分析之後,發現沒有一個對象是不逃逸的。那這個逃逸分析的過程就白白浪費掉了。
雖然這項技術並不十分成熟,但是他也是即時編譯器優化技術中一個十分重要的手段。
變量在內部創建在內部消失 就是線程安全的