JVM逃逸分析(同步省略、标量替换、栈上分配)
在Java的編譯體系中,一個Java的源代碼文件變成計算機可執行的機器指令的過程中,需要經過兩段編譯,第一段是把.java文件轉換成.class文件。第二段編譯是把.class轉換成機器指令的過程。
- 第一段編譯就是javac命令。
- 在第二編譯階段,JVM 通過解釋字節碼將其翻譯成對應的機器指令,逐條讀入,逐條解釋翻譯。很顯然,經過解釋執行,其執行速度必然會比可執行的二進制字節碼程序慢很多。這就是傳統的JVM的解釋器(Interpreter)的功能。為了解決這種效率問題,引入了 JIT(即時編譯) 技術。引入了 JIT 技術后,Java程序還是通過解釋器進行解釋執行,當JVM發現某個方法或代碼塊運行特別頻繁的時候,就會認為這是“熱點代碼”(Hot Spot Code)。然后JIT會把部分“熱點代碼”翻譯成本地機器相關的機器碼,并進行優化,然后再把翻譯后的機器碼緩存起來,以備下次使用。而JIT優化中最重要的一個就是逃逸分析。
一、逃逸分析
關于逃逸分析的概念,我們知道:對象和數組并不是都在堆上分配內存的。這里簡單回顧一下:逃逸分析的基本行為就是分析對象動態作用域:當一個對象在方法中被定義后,它可能被外部方法所引用,例如作為調用參數傳遞到其他地方中,稱為方法逃逸。
例如以下代碼:
第一段代碼中的sb就逃逸了,而第二段代碼中的sb就沒有逃逸。
使用逃逸分析,編譯器可以對代碼做如下優化:
- 同步省略。如果一個對象被發現只能從一個線程被訪問到,那么對于這個對象的操作可以不考慮同步。
- 將堆分配轉化為棧分配。如果一個對象在子程序中被分配,要使指向該對象的指針永遠不會逃逸,對象可能是棧分配的候選,而不是堆分配。
- 分離對象或標量替換。有的對象可能不需要作為一個連續的內存結構存在也可以被訪問到,那么對象的部分(或全部)可以不存儲在內存,而是存儲在CPU寄存器中。
在Java代碼運行時,通過JVM參數可指定是否開啟逃逸分析,
- -XX:+DoEscapeAnalysis : 表示開啟逃逸分析
- -XX:-DoEscapeAnalysis : 表示關閉逃逸分析 從jdk 1.7開始已經默認開始逃逸分析,如需關閉,需要指定-XX:-DoEscapeAnalysis
二、同步省略
在動態編譯同步塊的時候,JIT編譯器可以借助逃逸分析來判斷同步塊所使用的鎖對象是否只能夠被一個線程訪問而沒有被發布到其他線程。如果同步塊所使用的鎖對象通過這種分析被證實只能夠被一個線程訪問,那么JIT編譯器在編譯這個同步塊的時候就會取消對這部分代碼的同步
。這個取消同步的過程就叫同步省略,也叫鎖消除。
public void f() {Object hollis = new Object();synchronized(hollis) {System.out.println(hollis);} }代碼中對hollis這個對象進行加鎖,但是hollis對象的生命周期只在f()方法中,并不會被其他線程所訪問到,所以在JIT編譯階段就會被優化掉。優化成:
public void f() {Object hollis = new Object();System.out.println(hollis); }所以,在使用synchronized的時候,如果JIT經過逃逸分析之后發現并無線程安全問題的話,就會做鎖消除。
三、標量替換
標量(Scalar)是指一個無法再分解成更小的數據的數據。Java中的原始數據類型就是標量。相對的,那些還可以分解的數據叫做聚合量(Aggregate),Java中的對象就是聚合量,因為他可以分解成其他聚合量和標量。在JIT階段,如果經過逃逸分析,發現一個對象不會被外界訪問的話,那么經過JIT優化,就會把這個對象拆解成若干個其中包含的若干個成員變量來代替。這個過程就是標量替換。
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就會不會直接創建Point對象,而是直接使用兩個標量int x ,int y來替代Point對象。
以上代碼,經過標量替換后,就會變成:
可以看到,Point這個聚合量經過逃逸分析后,發現他并沒有逃逸,就被替換成兩個聚合量了。那么標量替換有什么好處呢?就是可以大大減少堆內存的占用。因為一旦不需要創建對象了,那么就不再需要分配堆內存了。標量替換為棧上分配提供了很好的基礎。
四、棧上分配
在Java虛擬機中,對象是在Java堆中分配內存的,這是一個普遍的常識。但是,有一種特殊情況,那就是如果經過逃逸分析后發現,一個對象并沒有逃逸出方法的話,那么就可能被優化成棧上分配。這樣就無需在堆上分配內存,也無須進行垃圾回收了。這里,要簡單說一下,其實在現有的虛擬機中,并沒有真正的實現棧上分配,在對象和數組并不是都在堆上分配內存的中我們的例子中,對象沒有在堆上分配,其實是標量替換實現的。
五、逃逸分析并不成熟
關于逃逸分析的論文在1999年就已經發表了,但直到JDK 1.6才有實現,而且這項技術到如今也并不是十分成熟的。其根本原因就是無法保證逃逸分析的性能消耗一定能高于他的消耗。雖然經過逃逸分析可以做標量替換、棧上分配、和鎖消除。但是逃逸分析自身也是需要進行一系列復雜的分析的,這其實也是一個相對耗時的過程。一個極端的例子,就是經過逃逸分析之后,發現沒有一個對象是不逃逸的。那這個逃逸分析的過程就白白浪費掉了。雖然這項技術并不十分成熟,但是他也是即時編譯器優化技術中一個十分重要的手段。
六、使用代碼體驗進行逃逸分析的效率
public class StackAllocation {public static void main(String[] args) {long start = System.currentTimeMillis();for (int i = 0; i < 1000000; i++) {alloc();}//查看執行時間long end = System.currentTimeMillis();System.out.println("花費的時間為: " + (end - start) + "ms");//為了方便查看堆內存中的對象個數,線程sleeptry {Thread.sleep(1000000);} catch (InterruptedException e) {e.printStackTrace();}}private static void alloc() {User user = new User(); //未發生逃逸,如果開啟逃逸分析的話,則會棧上分配}static class User {} }不開啟棧上分析:
使用jvisual進行監控:
借助插件可以看到:
花費了17ms,同時在堆上也有1000000個User對象
然后配置,我們配置VM 參數,開啟棧上分析
可以看到:
只花費了8ms,同時堆上也只有不到11萬的User實例
七、對象真的有一些不是分配在堆上嗎
那么,為何上面的代碼,開啟了棧上分配后,速度明顯更快,堆上對象也更少了?其實真正的底層原因,是因為標量替換
八、注意同步省略、標量替換、棧上分配只有在JVM的Server的模式下才生效,具體了解C2編譯器
文章部分轉自
總結
以上是生活随笔為你收集整理的JVM逃逸分析(同步省略、标量替换、栈上分配)的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 微笑的市场——2021新品线上消费报告
- 下一篇: 2021消费者数智化运营白皮书