Java JVM編譯策略案例詳解
解釋器
當(dāng)虛擬機(jī)啟動(dòng)時(shí)，解釋器可以首先發(fā)揮作用，而不必等待編譯器全部編譯完成再執(zhí)行，這樣可以省去許多不必要的編譯時(shí)間。并且隨著程序運(yùn)行時(shí)間的推移，編譯器逐漸發(fā)揮作用，根據(jù)熱點(diǎn)探測(cè)功能，，將有價(jià)值的字節(jié)碼編譯為本地機(jī)器指令，以換取更高的程序執(zhí)行效率。
hotspot中內(nèi)嵌有2個(gè)JIT編譯器，分別為Client Compiler，Server Compiler，但大多數(shù)情況下我們稱之為C1編譯器和C2編譯器。
C1編譯器
client compiler，又稱C1編譯器，較為輕量，只做少量性能開銷比較高的優(yōu)化，它占用內(nèi)存較少，適合于桌面交互式應(yīng)用。在寄存器分配策略上，JDK6以后采用的為線性掃描寄存器分配算法，其他方面的優(yōu)化，主要有方法內(nèi)聯(lián)、去虛擬化、冗余消除等。
A、方法內(nèi)聯(lián)
多個(gè)方法調(diào)用，執(zhí)行時(shí)要經(jīng)歷多次參數(shù)傳遞，返回值傳遞及跳轉(zhuǎn)等，C1采用方法內(nèi)聯(lián)，把調(diào)用到的方法的指令直接植入當(dāng)前方法中。-XX:+PringInlining來查看方法內(nèi)聯(lián)信息，-XX:MaxInlineSize=35控制編譯后文件大小。
B、去虛擬化
是指在裝載class文件后，進(jìn)行類層次的分析，如果發(fā)現(xiàn)類中的方法只提供一個(gè)實(shí)現(xiàn)類，那么對(duì)于調(diào)用了此方法的代碼，也可以進(jìn)行方法內(nèi)聯(lián)，從而提升執(zhí)行的性能。
C、冗余消除
在編譯時(shí)根據(jù)運(yùn)行時(shí)狀況進(jìn)行代碼折疊或消除。
C2編譯器
Server compiler，稱為C2編譯器，較為重量，采用了大量傳統(tǒng)編譯優(yōu)化的技巧來進(jìn)行優(yōu)化，占用內(nèi)存相對(duì)多一些，適合服務(wù)器端的應(yīng)用。和C1的不同主要在于寄存器分配策略及優(yōu)化范圍，寄存器分配策略上C2采用的為傳統(tǒng)的圖著色寄存器分配算法，由于C2會(huì)收集程序運(yùn)行信息，因此其優(yōu)化范圍更多在于全局優(yōu)化，不僅僅是一個(gè)方塊的優(yōu)化。收集的信息主要有：分支的跳轉(zhuǎn)/不跳轉(zhuǎn)的頻率、某條指令上出現(xiàn)過的類型、是否出現(xiàn)過空值、是否出現(xiàn)過異常等。
逃逸分析是C2進(jìn)行很多優(yōu)化的基礎(chǔ)，它根據(jù)運(yùn)行狀態(tài)來判斷方法中的變量是否會(huì)被外部讀取，如不會(huì)則認(rèn)為此變量是不會(huì)逃逸的，那么在編譯時(shí)會(huì)做標(biāo)量替換、棧上分配和同步消除等優(yōu)化。
（1）標(biāo)量替換
簡(jiǎn)單地說，就是用標(biāo)量替換聚合量。這樣做的好處是如果創(chuàng)建的對(duì)象并未用到其中的全部變量，則可以節(jié)省一定的內(nèi)存。對(duì)于代碼執(zhí)行而言，無需去找對(duì)象的引用，也會(huì)更快一些。
（2）棧上分配
如果point沒有逃逸，那么C2會(huì)選擇在棧上直接創(chuàng)建Point對(duì)象的實(shí)例，而不是在JVM堆上。在棧上分配的好處一方面是加快速度，另一方面是回收時(shí)隨著方法的結(jié)束，對(duì)象被回收了。
（3）同步消除
如果發(fā)現(xiàn)同步的對(duì)象未逃逸，那也就沒有必要進(jìn)行同步了，C2編譯時(shí)會(huì)直接去掉同步。
C2還會(huì)基于擁有的運(yùn)行信息來做其他優(yōu)化，比如編譯分支頻率執(zhí)行高的代碼等。
運(yùn)行后C1、C2編譯出來的機(jī)器碼如果不再符合優(yōu)化條件，則會(huì)進(jìn)行逆優(yōu)化，也就是回到解釋執(zhí)行的方式，例如基于類層次分析編譯的代碼，當(dāng)有新的相應(yīng)的接口來實(shí)現(xiàn)類加入時(shí)，就執(zhí)行逆優(yōu)化。
OSR編譯
除了C1、C2外，還有OSR（On Stack Replace）編譯，只替換循環(huán)代碼體的入口，C1、C2替換的是方法調(diào)用的入口。因此OSR編譯后會(huì)出現(xiàn)的現(xiàn)象是方法的整段代碼被編譯了，但是只有循環(huán)體部分才執(zhí)行編譯后的機(jī)器碼，其他部分仍是解釋執(zhí)行。
當(dāng)機(jī)器配置CPU超過2核且內(nèi)存超過2G，默認(rèn)為server模式，32位的windows始終選擇的是client模式。
分層編譯
Java7默認(rèn)開啟分層編譯（tiered compilation）策略，由C1編譯器和C2編譯器相互協(xié)作共同來執(zhí)行編譯任務(wù)。C1編譯器會(huì)對(duì)字節(jié)碼進(jìn)行簡(jiǎn)單和可靠的優(yōu)化，以達(dá)到更快的編譯速度；C2編譯器會(huì)啟動(dòng)一些編譯耗時(shí)更長(zhǎng)的優(yōu)化，以獲取更好的編譯質(zhì)量。
- 解釋器不再收集運(yùn)行狀態(tài)信息，只用于啟動(dòng)并觸發(fā)C1編譯
- C1編譯后生成帶收集運(yùn)行信息的代碼
- C2編譯，基于C1編譯后代碼收集的運(yùn)行信息進(jìn)行激進(jìn)優(yōu)化，當(dāng)激進(jìn)優(yōu)化的假設(shè)不成立時(shí)，再退回使用C1編譯的代碼
程序在未編譯期間解釋執(zhí)行有個(gè)閾值，SunJDK主要依據(jù)方法上的兩個(gè)計(jì)數(shù)器是否超過閾值來判斷：
-
A、調(diào)用計(jì)數(shù)器，即方法被調(diào)用的次數(shù)，CompileThreshold，該值是指當(dāng)方法被調(diào)用多少次后，就編譯為機(jī)器碼，client模式默認(rèn)為1500次，server模式默認(rèn)為1萬次，可以在啟動(dòng)時(shí)添加-XX:CompileThreshold=10000來設(shè)置該值。
-
B、回邊計(jì)數(shù)器，即方法中循環(huán)執(zhí)行部分代碼的執(zhí)行次數(shù)，OnStackReplacePercentage，該值用于/參與計(jì)算是否觸發(fā)OSR編譯的閾值，client默認(rèn)為933，sever默認(rèn)為140，可以通過-XX: OnStackReplacePercentage=140來設(shè)置。
client模式下的計(jì)算規(guī)則為CompileThreshold*OnStackReplacePercentage/100，
server模式下計(jì)算規(guī)則為CompileThreshold*（OnStackReplacePercentage-InterpreterProfilePercentage）/100。InterpreterProfilePercentage，默認(rèn)為33。
當(dāng)方法上的回邊計(jì)數(shù)器到達(dá)這個(gè)值時(shí)，觸發(fā)后臺(tái)的OSR編譯，并將方法上累積的調(diào)用計(jì)數(shù)器設(shè)置為CompileThreshold 的值，同時(shí)將回邊計(jì)數(shù)器設(shè)置為CompileThreshold/2的值。這樣做一方面是為了避免OSR編譯頻繁被觸發(fā)，另一方面是以便當(dāng)方法被再次調(diào)用時(shí)即觸發(fā)正常的編譯，當(dāng)累積的回邊計(jì)數(shù)器的值再次達(dá)到該值時(shí)先檢查OSR編譯是否完成，如果已完成，則在執(zhí)行循環(huán)體的代碼時(shí)進(jìn)入編譯后的代碼，如果未完成，繼續(xù)把當(dāng)前回邊計(jì)數(shù)器的累計(jì)值再減掉一些，默認(rèn)情況下，對(duì)于回邊的情況，server模式下只要回邊次數(shù)達(dá)到10700次（10000*（140-33）），就會(huì)觸發(fā)OSR編譯。
解釋器與編譯器并存
如果選用完全解釋策略，那么編譯器將停止所有的工作，字節(jié)碼將完全依靠解釋器逐行解釋執(zhí)行。
如果選用完全編譯策略，那么解釋器仍然會(huì)在編譯器無法進(jìn)行的特殊情況下介入運(yùn)行，這主要是確保程序能夠最終順序執(zhí)行。
SunJDK之所以未選擇在啟動(dòng)時(shí)即編譯成機(jī)器碼的原因如下：
- 靜態(tài)編譯并不能根據(jù)程序的運(yùn)行狀態(tài)來優(yōu)化執(zhí)行的代碼，C2這種方式是根據(jù)運(yùn)行狀態(tài)來進(jìn)行動(dòng)態(tài)編譯的，例如分支判斷、逃逸分析等，這些措施會(huì)對(duì)提升程序執(zhí)行的性能起到很大的幫助，在靜態(tài)編譯的情況下是無法實(shí)現(xiàn)的，給C2收集運(yùn)行數(shù)據(jù)越長(zhǎng)的時(shí)間，編譯出來的代碼會(huì)越優(yōu)。
- 解釋執(zhí)行比編譯執(zhí)行更節(jié)省內(nèi)存
- 啟動(dòng)時(shí)解釋執(zhí)行的啟動(dòng)速度比編譯再啟動(dòng)更快。
到此這篇關(guān)于Java JVM編譯策略案例詳解的文章就介紹到這了,更多相關(guān)Java JVM編譯策略內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
相關(guān)文章
詳解Springboot2.3集成Spring security 框架(原生集成)
這篇文章主要介紹了詳解Springboot2.3集成Spring security 框架(原生集成)，文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2020-08-08
java中讀取配置文件中數(shù)據(jù)的具體方法，需要的朋友可以參考一下2013-06-06
這篇文章主要介紹了springboot中的RestTemplate使用詳解,RestTemplate繼承自InterceptingHttpAccessor并且實(shí)現(xiàn)了RestOperations接口,其中RestOperations接口定義了基本的RESTful操作,這些操作在RestTemplate中都得到了實(shí)現(xiàn),需要的朋友可以參考下2023-09-09
SpringMVC利用dropzone組件實(shí)現(xiàn)圖片上傳
這篇文章主要介紹了SpringMVC利用dropzone組件實(shí)現(xiàn)圖片上傳，文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2020-02-02
這篇文章主要介紹了java多線程volatile內(nèi)存語義解析,文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下2020-01-01
Java實(shí)現(xiàn)的二叉樹常用操作【前序建樹，前中后遞歸非遞歸遍歷及層序遍歷】
這篇文章主要介紹了Java實(shí)現(xiàn)的二叉樹常用操作,包括二叉樹的前序建樹，前中后遞歸非遞歸遍歷及層序遍歷等相關(guān)操作技巧,需要的朋友可以參考下2018-01-01
本文主要介紹了Java稀疏數(shù)組的應(yīng)用實(shí)踐，文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2023-06-06
Java?Stream?流中?Collectors.toMap?的用法詳解
這篇文章主要介紹了Stream?流中?Collectors.toMap?的用法,Collectors.toMap()方法是把List轉(zhuǎn)Map的操作，本文通過實(shí)例代碼給大家介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值，需要的朋友可以參考下2024-01-01
這篇文章主要介紹了java中的hashCode方法小例子，有需要的朋友可以參考一下2013-12-12
如何用Java將數(shù)據(jù)庫的數(shù)據(jù)生成pdf返回給前端用戶下載
本文詳細(xì)介紹了使用SpringBoot、iText庫、MyBatis等技術(shù)從數(shù)據(jù)庫中選取數(shù)據(jù)并生成PDF文件的后端處理流程,文中通過代碼介紹的非常詳細(xì),需要的朋友可以參考下2024-09-09