您好,登錄后才能下訂單哦!
這篇文章將為大家詳細講解有關什么是JVM逃逸,小編覺得挺實用的,因此分享給大家做個參考,希望大家閱讀完這篇文章后可以有所收獲。
我們先不看概念,我們先來看一段代碼,如下:
首先,我告訴你,這段代碼發送了逃逸!為什么?切看我來分析!
我們都知道 Java 中的對象默認是分配到堆上的,垃圾回收機制也會回收堆中不再使用的對象。但在此之前需要篩選可回收的對象,因此會造成,回收對象還有整理內存,都比較耗時間,開銷也是非常之大。而這也是 Java 語言最被瘋狂吐槽的一地方。實際上呢,就是Java 不支持棧上分配對象。
像上面的這個函數被返回的 StringBuilder 對象本是方法的一個內部變量,而此時將它直接返回,這樣 StringBuilder 就有可能被其他地方的方法或變量改變,這樣它的作用域就不只是 escapeXttblog 方法了,雖然它是一個局部變量,但其發生了“逃逸事故”。
既然有 JVM 逃逸事件發生,那么我們就應該有機制分析哪些代碼可能會發生“逃逸事故”。于是一門新的學問就誕生了,這就是 JVM 逃逸分析。
逃逸分析(Escape Analysis),是一種可以有效減少Java 程序中同步負載和內存堆分配壓力的跨函數全局數據流分析算法。通過逃逸分析,Java Hotspot編譯器能夠分析出一個新的對象的引用的使用范圍從而決定是否要將這個對象分配到堆上。 逃逸分析算是目前Java虛擬機中比較前沿的優化技術了,但至于適不適合,需要據實際情況而定了。
逃逸分析是指分析指針動態范圍的方法,它同編譯器優化原理的指針分析和外形分析相關聯。當變量(或者對象)在方法中分配后,其指針有可能被返回或者被全局引用,這樣就會被其他方法或者線程所引用,這種現象稱作指針(或者引用)的逃逸(Escape)。通俗點講,如果一個對象的指針被多個方法或者線程引用時,那么我們就稱這個對象的指針發生了逃逸。
如何避免 JVM 逃逸?
像上面的“逃逸事故”,我們想要避免,只需要改一下 escapeXttblog 方法的返回值即可。
將返回的 StringBuilder,改為 String 后 StringBuilder 沒有從方法中脫離,將不會發生逃逸。
結合上面的例子和概念,我整理了 3 種常見的逃逸代碼,具體如下:
發生逃逸的根本原因是因為 Java 本身的限制(對象只能分配到堆中)。為了減少臨時對象在堆內分配的數量,我會在一個方法體內定義一個局部變量,并且該變量在方法執行過程中未發生逃逸,按照JVM調優機制,首先會在堆內存創建類的實例,然后將此對象的引用壓入調用棧,繼續執行,這是JVM優化前的方式。然后,我采用逃逸分析對JVM進行優化。即針對棧的重新分配方式,首先找出未逃逸的變量,將該變量直接存到棧里,無需進入堆,分配完成后,繼續調用棧內執行,最后線程執行結束,棧空間被回收,局部變量也被回收了。如此操作,是優化前在堆中,優化后在棧中,從而減少了堆中對象的分配和銷毀,從而優化性能。
但是逃逸分析會有時間消耗,所以性能不一定會有提升,并且由于逃逸分析比較耗時,目前的實現都是采用不那么準確但是時間壓力相對較小的算法來完成逃逸分析,這就有可能導致效果不穩定,所以,要根據實際情況,酌情處理。
一項技術的好壞,不是憑嘴說說,適合自己的才是最好的。
關于“什么是JVM逃逸”這篇文章就分享到這里了,希望以上內容可以對大家有一定的幫助,使各位可以學到更多知識,如果覺得文章不錯,請把它分享出去讓更多的人看到。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。