點擊“開發(fā)者技術前線”，選擇“星標??”

讓一部分開發(fā)者看到未來

作者：被稱為L的男人

原文：http://www.jianshu.com/p/faefc5e3451d

說明：第二次讀周志明的《深入理解Java虛擬機》，感覺我原來的思維導圖筆記，在結構上有些問題。更新了思維導圖的結構，同時優(yōu)化了GC、虛擬機字節(jié)碼執(zhí)行引擎、Java編譯器與代碼優(yōu)化等內(nèi)容，閱讀下文前不防看看：如何用思維導圖學Java編程思想

走進Java

自動內(nèi)存管理機制
內(nèi)存區(qū)域
GC
JVM監(jiān)控工具

虛擬機字節(jié)碼執(zhí)行引擎
執(zhí)行引擎
字節(jié)碼
類加載

Java編譯器與代碼優(yōu)化
前端編譯器



JIT編譯器（Just In Time）


AOT編譯器（Ahead Of Time）
高效并發(fā)

Java 與 C/C++ 編譯器的比較？

這兩天重溫了周志明的《深入理解Java虛擬機》第2版，發(fā)現(xiàn)第11章第4節(jié)關于 Java 編譯器的內(nèi)容寫得太棒了~本文完全摘自《深入理解Java虛擬機》第2版 0_o

Java 與 C/C++ 編譯器

大多數(shù)程序員都認為C/C++會比Java語言快，甚至覺得從Java語言誕生以來“執(zhí)行速度緩慢”的帽子就應當扣在它的頭頂，這種觀點的出現(xiàn)是由于Java剛出現(xiàn)的時候即時編譯技術還不成熟，主要靠解釋器執(zhí)行的Java語言性能確實比較低下。但目前即時編譯技術已經(jīng)十分成熟，Java語言有可能在速度上與C/C++一爭高下嗎？要想知道這個問題的答案，讓我們從兩者的編譯器談起。

Java與C/C++的編譯器對比，實際上代表了最經(jīng)典的即時編譯器與靜態(tài)編譯器的對比，很大程度上也決定了Java與C/C++的性能對比結果，因為無論是C/C++還是Java代碼，最終編譯之后被機器執(zhí)行的都是本地機器碼，哪種語言的性能更高，除了它們自身的API庫實現(xiàn)地好壞之外，其余的比較就成了一場拼編譯器的游戲。當然，這種比較也是剔除了開發(fā)效率的片面對比，語言孰優(yōu)孰劣、誰快誰慢的問題都是很難有結果的爭論，下面我們就回到正題，看看這兩種語言的編譯器各有何優(yōu)勢。

Java 編譯器“劣勢”的原因

Java虛擬機的即時編譯器與C/C++的靜態(tài)優(yōu)化編譯器相比，可能會由于下列原因，而導致輸出的本地代碼有一些劣勢（下面列舉的也包括一些虛擬機執(zhí)行子系統(tǒng)的性能劣勢）：

第一，因為即時編譯器運行占用的是用戶程序的運行時間，具有很大的時間壓力，它能提供的優(yōu)化手段也嚴重受制于編譯成本。如果編譯速度達不到要求，那用戶將在啟動程序或程序的某部分察覺到重大延遲，這點使得即時編譯器不敢隨便引入大規(guī)模的優(yōu)化技術，而編譯的時間成本在靜態(tài)優(yōu)化編譯器中并不是主要的關注點。

第二，Java語言是動態(tài)的類型安全語言，這就意味著需要由虛擬機來確保程序不會違反語言語義或訪問非結構化內(nèi)存。從實現(xiàn)層面上看，這就意味著虛擬機必須頻繁地進行動態(tài)檢查，如實例方法訪問時檢查空指針、數(shù)組元素訪問時檢查上下界范圍、類型轉換時檢查繼承關系等。對于這類程序代碼沒有明確寫出的檢查行為，盡管編譯器會努力進行優(yōu)化，但是總體上仍然要消耗不少的運行時間。

第三，Java語言中雖然沒有virtual關鍵字，但是使用虛方法的頻率卻遠遠大于C/C++語言，這意味著運行時對方法接收者進行多態(tài)選擇的頻率要遠遠大于C/C++語言，也意味著即時編譯器在進行一些優(yōu)化（如方法內(nèi)聯(lián)）時的難度要遠遠大于C/C++的靜態(tài)優(yōu)化編譯器。

第四，Java語言是可以動態(tài)擴展的語言，運行時加載新的類可能改變程序類型的繼承關系，這使得很多全局的優(yōu)化難以進行，因為編譯器無法看清程序的全貌，許多全局的優(yōu)化都只能以激進優(yōu)化的方式來完成，編譯器不得不時刻注意并隨著類型的變化而在運行時撤銷或重新進行一些優(yōu)化。

第五，Java語言的對象內(nèi)存是在堆上，只有方法的局部變量才能在棧上分配，而C/C++的對象則有多重內(nèi)存分配方式，既可能在堆上分配，又可能在棧上分配，如果可以在棧上分配線程私有的對象，將減輕內(nèi)存回收的壓力。另外，C/C++中主要由用戶用程序代碼來回收分配的內(nèi)存，這就不存在無用對象篩選的過程，因此效率上（僅是運行效率，排除開發(fā)效率）也比Java的垃圾收集機制要高。

Java 編譯器的“優(yōu)勢”

上面所了一堆Java語言在性能上的劣勢，這些都是為了換取「開發(fā)效率」上的優(yōu)勢而付出的代價，動態(tài)安全、動態(tài)擴展、垃圾回收這些“拖后腿”的特性，都為Java語言的開發(fā)效率做出了很大貢獻。
何況，還有許多優(yōu)化是Java的即時編譯器能做，而C/C++的靜態(tài)優(yōu)化編譯器不能做或者不好做的。例如，在C/C++中，別名分析（Alias Analysis）的難度就要遠遠高于Java。Java的類型安全保證了在類似如下代碼中，只要ClassA和ClassB沒有繼承關系，那對象objA和objB就絕不可能是同一個對象，即不會是同一塊內(nèi)存兩個不同別名。

void foo(ClassA objA, ClassB objB) {
objA.x = 123;
objB.y = 456;
// 只要objB.y不是objA.x的別名，下面就可以保證輸出為123
print(objA.x);
}
確定了objA和objB并非

對方的別名后，許多與數(shù)據(jù)依賴相關的優(yōu)化才可以進行（重排序、變量替換）。具體到這個例子中，就是無需擔心objB.y與objA.x指向同一塊內(nèi)存，這樣就可以安全地確定打印語句中的objA.x為123。

Java編譯器另外一個紅利是由它的動態(tài)性所帶來的，由于C/C++編譯器所有優(yōu)化都在編譯期完成，以運行期性能監(jiān)控為基礎的優(yōu)化措施它都無法進行，如：

調(diào)用頻率預測：Call Frequency Prediction
分支頻率預測：Branch Frequency Prediction
裁剪未被選擇的分支：UNtaken Branch Pruning
這些都是Java語言獨有的性能優(yōu)勢。

總結

隨著Java JIT編譯技術的發(fā)展，Java的運行速度已經(jīng)足夠快。Java能夠在運行時動態(tài)加載類（可以從zip包、網(wǎng)絡、運行時計算、其他文件生成），C/C++則完全做不到這一點?？偟膩碚f，Java的動態(tài)安全、動態(tài)擴展、垃圾回收等特性，使得開發(fā)效率很高，并且足夠靈活；同時隨著編譯技術的不斷發(fā)展，性能的劣勢正在逐漸減小。

END