Java JVM編譯策略案例詳解
解釋器
當(dāng)虛擬機(jī)啟動(dòng)時(shí)，解釋器可以首先發(fā)揮作用，而不必等待編譯器全部編譯完成再執(zhí)行，這樣可以省去許多不必要的編譯時(shí)間。并且隨著程序運(yùn)行時(shí)間的推移，編譯器逐漸發(fā)揮作用，根據(jù)熱點(diǎn)探測功能，，將有價(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)類，那么對于調(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)存相對多一些，適合服務(wù)器端的應(yīng)用。和C1的不同主要在于寄存器分配策略及優(yōu)化范圍，寄存器分配策略上C2采用的為傳統(tǒng)的圖著色寄存器分配算法，由于C2會收集程序運(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)來判斷方法中的變量是否會被外部讀取，如不會則認(rèn)為此變量是不會逃逸的，那么在編譯時(shí)會做標(biāo)量替換、棧上分配和同步消除等優(yōu)化。
（1）標(biāo)量替換
簡單地說，就是用標(biāo)量替換聚合量。這樣做的好處是如果創(chuàng)建的對象并未用到其中的全部變量，則可以節(jié)省一定的內(nèi)存。對于代碼執(zhí)行而言，無需去找對象的引用，也會更快一些。
（2）棧上分配
如果point沒有逃逸，那么C2會選擇在棧上直接創(chuàng)建Point對象的實(shí)例，而不是在JVM堆上。在棧上分配的好處一方面是加快速度，另一方面是回收時(shí)隨著方法的結(jié)束，對象被回收了。
（3）同步消除
如果發(fā)現(xiàn)同步的對象未逃逸，那也就沒有必要進(jìn)行同步了，C2編譯時(shí)會直接去掉同步。
C2還會基于擁有的運(yùn)行信息來做其他優(yōu)化，比如編譯分支頻率執(zhí)行高的代碼等。
運(yùn)行后C1、C2編譯出來的機(jī)器碼如果不再符合優(yōu)化條件，則會進(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編譯后會出現(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編譯器會對字節(jié)碼進(jìn)行簡單和可靠的優(yōu)化，以達(dá)到更快的編譯速度；C2編譯器會啟動(dòng)一些編譯耗時(shí)更長的優(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ā)后臺的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)情況下，對于回邊的情況，server模式下只要回邊次數(shù)達(dá)到10700次（10000*（140-33）），就會觸發(fā)OSR編譯。
解釋器與編譯器并存
如果選用完全解釋策略，那么編譯器將停止所有的工作，字節(jié)碼將完全依靠解釋器逐行解釋執(zhí)行。
如果選用完全編譯策略，那么解釋器仍然會在編譯器無法進(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)編譯的，例如分支判斷、逃逸分析等，這些措施會對提升程序執(zhí)行的性能起到很大的幫助，在靜態(tài)編譯的情況下是無法實(shí)現(xiàn)的，給C2收集運(yùn)行數(shù)據(jù)越長的時(shí)間，編譯出來的代碼會越優(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)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
相關(guān)文章
Spring Boot集成Swagger接口分類與各元素排序問題
這篇文章主要介紹了Spring Boot集成Swagger接口分類與各元素排序問題,首先我們需要對Swagger中的接口也就是以Controller 層作為第一級梯度進(jìn)行組織的,Controller在我們實(shí)際開發(fā)中,與其他具體接口之間是存在一對多的關(guān)系,本文給大家介紹的非常詳細(xì),需要的朋友參考下吧2023-10-10
這篇文章主要介紹了java中重寫equals和重寫hashCode()的相關(guān)資料,需要的朋友可以參考下2017-04-04
這篇文章主要介紹了分享JVM 的四種引用方式，文章圍繞主題展開詳細(xì)的內(nèi)容介紹，具有一定的參考價(jià)值，需要的小伙伴可以參考一下2022-07-07
解決get請求入?yún)NotNull驗(yàn)證不生效問題
這篇文章主要介紹了解決get請求入?yún)NotNull驗(yàn)證不生效問題，具有很好的參考價(jià)值，希望對大家有所幫助。如有錯(cuò)誤或未考慮完全的地方，望不吝賜教2021-09-09
這篇文章主要介紹了java反射獲取一個(gè)object屬性值代碼解析，具有一定借鑒價(jià)值，需要的朋友可以參考下。2017-12-12
SpringBoot重啟后,第一次請求接口請求慢的問題及解決
這篇文章主要介紹了SpringBoot重啟后,第一次請求接口請求慢的問題及解決,具有很好的參考價(jià)值,希望對大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2024-05-05
SpringMVC加載控制與Postmand的使用和Rest風(fēng)格的引入及RestFul開發(fā)全面詳解
SpringMVC是一種基于Java，實(shí)現(xiàn)了Web MVC設(shè)計(jì)模式，請求驅(qū)動(dòng)類型的輕量級Web框架，即使用了MVC架構(gòu)模式的思想，將Web層進(jìn)行職責(zé)解耦。基于請求驅(qū)動(dòng)指的就是使用請求-響應(yīng)模型，框架的目的就是幫助我們簡化開發(fā)，SpringMVC也是要簡化我們?nèi)粘eb開發(fā)2022-10-10
這篇文章主要介紹了Java跳過https的ssl證書驗(yàn)證的解決思路，文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，下面我們來深入學(xué)習(xí)下吧2019-06-06
這篇文章主要為大家詳細(xì)介紹了java實(shí)現(xiàn)登錄窗口，含驗(yàn)證碼驗(yàn)證、賬戶注冊等，文中示例代碼介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2022-04-04
Mybatis學(xué)習(xí)筆記之動(dòng)態(tài)SQL揭秘
這篇文章主要給大家介紹了關(guān)于Mybatis學(xué)習(xí)筆記之動(dòng)態(tài)SQL的相關(guān)資料，小編覺得挺不錯(cuò)的，對大家學(xué)習(xí)或者使用Mybatis會有一定的幫助，現(xiàn)在分享給大家，也給大家做個(gè)參考。一起跟隨小編過來看看吧2018-11-11