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

創(chuàng)新互聯(lián)公司專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù),包含不限于成都做網(wǎng)站、成都網(wǎng)站設(shè)計(jì)、成都外貿(mào)網(wǎng)站建設(shè)、嵩縣網(wǎng)絡(luò)推廣、重慶小程序開發(fā)、嵩縣網(wǎng)絡(luò)營銷、嵩縣企業(yè)策劃、嵩縣品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運(yùn)營等,從售前售中售后,我們都將竭誠為您服務(wù),您的肯定,是我們最大的嘉獎(jiǎng);創(chuàng)新互聯(lián)公司為所有大學(xué)生創(chuàng)業(yè)者提供嵩縣建站搭建服務(wù),24小時(shí)服務(wù)熱線:028-86922220,官方網(wǎng)址:www.cdcxhl.com
***段編譯就是javac命令。
在第二編譯階段,JVM 通過解釋字節(jié)碼將其翻譯成對應(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ī)器碼緩存起來,以備下次使用。
由于關(guān)于JIT編譯和熱點(diǎn)檢測的內(nèi)容,我在深入分析Java的編譯原理中已經(jīng)介紹過了,這里就不在贅述,本文主要來介紹下JIT中的優(yōu)化。JIT優(yōu)化中最重要的一個(gè)就是逃逸分析。
逃逸分析
關(guān)于逃逸分析的概念,可以參考對象并不一定都是在堆上分配內(nèi)存的一文,這里簡單回顧一下:
逃逸分析的基本行為就是分析對象動(dòng)態(tài)作用域:當(dāng)一個(gè)對象在方法中被定義后,它可能被外部方法所引用,例如作為調(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就沒有逃逸。
使用逃逸分析,編譯器可以對代碼做如下優(yōu)化:
一、同步省略。如果一個(gè)對象被發(fā)現(xiàn)只能從一個(gè)線程被訪問到,那么對于這個(gè)對象的操作可以不考慮同步。
二、將堆分配轉(zhuǎn)化為棧分配。如果一個(gè)對象在子程序中被分配,要使指向該對象的指針永遠(yuǎn)不會(huì)逃逸,對象可能是棧分配的候選,而不是堆分配。
三、分離對象或標(biāo)量替換。有的對象可能不需要作為一個(gè)連續(xù)的內(nèi)存結(jié)構(gòu)存在也可以被訪問到,那么對象的部分(或全部)可以不存儲(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編譯器可以借助逃逸分析來判斷同步塊所使用的鎖對象是否只能夠被一個(gè)線程訪問而沒有被發(fā)布到其他線程。
如果同步塊所使用的鎖對象通過這種分析被證實(shí)只能夠被一個(gè)線程訪問,那么JIT編譯器在編譯這個(gè)同步塊的時(shí)候就會(huì)取消對這部分代碼的同步。這個(gè)取消同步的過程就叫同步省略,也叫鎖消除。
如以下代碼:
- public void f() {
- Object hollis = new Object();
- synchronized(hollis) {
- System.out.println(hollis);
- }
- }
代碼中對hollis這個(gè)對象進(jìn)行加鎖,但是hollis對象的生命周期只在f()方法中,并不會(huì)被其他線程所訪問到,所以在JIT編譯階段就會(huì)被優(yōu)化掉。優(yōu)化成:
- public void f() {
- Object hollis = 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)量。相對的,那些還可以分解的數(shù)據(jù)叫做聚合量(Aggregate),Java中的對象就是聚合量,因?yàn)樗梢苑纸獬善渌酆狭亢蜆?biāo)量。
在JIT階段,如果經(jīng)過逃逸分析,發(fā)現(xiàn)一個(gè)對象不會(huì)被外界訪問的話,那么經(jīng)過JIT優(yōu)化,就會(huì)把這個(gè)對象拆解成若干個(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對象并沒有逃逸出alloc方法,并且point對象是可以拆解成標(biāo)量的。那么,JIT就會(huì)不會(huì)直接創(chuàng)建Point對象,而是直接使用兩個(gè)標(biāo)量int x ,int y來替代Point對象。
以上代碼,經(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)建對象了,那么就不再需要分配堆內(nèi)存了。
標(biāo)量替換為棧上分配提供了很好的基礎(chǔ)。
棧上分配
在Java虛擬機(jī)中,對象是在Java堆中分配內(nèi)存的,這是一個(gè)普遍的常識(shí)。但是,有一種特殊情況,那就是如果經(jīng)過逃逸分析后發(fā)現(xiàn),一個(gè)對象并沒有逃逸出方法的話,那么就可能被優(yōu)化成棧上分配。這樣就無需在堆上分配內(nèi)存,也無須進(jìn)行垃圾回收了。
關(guān)于棧上分配的詳細(xì)介紹,可以參考對象并不一定都是在堆上分配內(nèi)存的
這里,還是要簡單說一下,其實(shí)在現(xiàn)有的虛擬機(jī)中,并沒有真正的實(shí)現(xiàn)棧上分配,在對象并不一定都是在堆上分配內(nèi)存的中我們的例子中,對象沒有在堆上分配,其實(shí)是標(biāo)量替換實(shí)現(xià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è)相對耗時(shí)的過程。
一個(gè)極端的例子,就是經(jīng)過逃逸分析之后,發(fā)現(xiàn)沒有一個(gè)對象是不逃逸的。那這個(gè)逃逸分析的過程就白白浪費(fèi)掉了。
雖然這項(xiàng)技術(shù)并不十分成熟,但是他也是即時(shí)編譯器優(yōu)化技術(shù)中一個(gè)十分重要的手段。
【本文是專欄作者Hollis的原創(chuàng)文章,作者微信公眾號(hào)Hollis(ID:hollischuang)】
戳這里,看該作者更多好文
當(dāng)前文章:深入理解Java中的逃逸分析
標(biāo)題URL:http://www.dlmjj.cn/article/dhgijso.html


咨詢
建站咨詢
