Java編譯器優化方法簡介
你對Java編譯器優化的概念和方法是否熟悉，這里和大家分享一下，Java應用程序的編譯過程與靜態編譯語言（例如C或C++）不同。靜態編譯器直接把源代碼轉換成可以直接在目標平臺上執行的機器代碼，不同的硬件平臺要求不同的編譯器。Java編譯器把Java源代碼轉換成可移植的JVM字節碼。
兩條編碼準則與Java編譯器
我們在寫代碼時，常常會提到兩條原則：
1、方法要盡量短，大方法要分解成小方法；
2、不要重復發明輪子。
我們在強調這兩個原則的時候，往往只關注的是代碼簡潔、易維護等方便我們人的因素，其實這樣做還可以大大方便Java編譯器優化代碼。
Java編譯器優化簡介：
Java應用程序的編譯過程與靜態編譯語言（例如C或C++）不同。靜態編譯器直接把源代碼轉換成可以直接在目標平臺上執行的機器代碼，不同的硬件平臺要求不同的編譯器。Java編譯器把Java源代碼轉換成可移植的JVM字節碼。與靜態編譯器不同，Javac幾乎不做什么優化，在靜態編譯語言中應當由編譯器進行的優化工作，在Java中是在程序執行的時候，由運行時執行優化。
即時編譯
對于證實概念的實現來說，解釋是合適的，但是早期的JVM由于太慢。下一代JVM使用即時(JIT)編譯器來提高執行速度。按照嚴格的定義，基于JIT的虛擬機在執行之前，把所有字節碼轉換成機器碼，但是以惰性方式來做這項工作：JIT只有在確定某個代碼路徑將要執行的時候，才編譯這個代碼路徑（因此有了名稱“即時編譯”）。這個技術使程序能啟動得更快，因為在開始執行之前，不需要冗長的編譯階段。
JIT技術看起來很有前途，但是它有一些不足。
JIT消除了解釋的負擔（以額外的啟動成本為代價），但是由于若干原因，代碼的優化等級仍然是一般般。為了避免Java應用程序嚴重的啟動延遲，JIT編譯器必須非常迅速，這意味著它無法把大量時間花在優化上。所以，早期的JIT編譯器在進行內聯假設(inliningassumption)方面比較保守，因為它們不知道后面可能要裝入哪個類。
雖然從技術上講，基于JIT的虛擬機在執行字節碼之前，要先編譯字節碼，但是JIT這個術語通常被用來表示任何把字節碼轉換成機器碼的動態編譯過程——即使那些能夠解釋字節碼的過程也算。
HotSpot動態編譯
HotSpot執行過程組合了編譯、性能分析以及動態編譯。它沒有把所有要執行的字節碼轉換成機器碼，而是先以解釋器的方式運行，只編譯“熱門”代碼——執行得最頻繁的代碼。當HotSpot執行時，會搜集性能分析數據，用來決定哪個代碼段執行得足夠頻繁，值得編譯。只編譯執行最頻繁的代碼有幾項性能優勢：沒有把時間浪費在編譯那些不經常執行的代碼上；這樣，編譯器就可以花更多時間來優化熱門代碼路徑，因為它知道在這上面花的時間物有所值。而且，通過延遲編譯，編譯器可以訪問性能分析數據，并用這些數據來改進優化決策，例如是否需要內聯某個方法調用。
為了讓事情變得更復雜，HotSpot提供了兩個Java編譯器：客戶機編譯器和服務器編譯器。默認采用客戶機編譯器；在啟動JVM時，您可以指定-server開關，選擇服務器編譯器。服務器編譯器針對***峰值操作速度進行了優化，適用于需要長期運行的服務器應用程序。客戶機編譯器的優化目標，是減少應用程序的啟動時間和內存消耗，優化的復雜程度遠遠低于服務器編譯器，因此需要的編譯時間也更少。
HotSpot服務器編譯器能夠執行各種樣的類。它能夠執行許多靜態編譯器中常見的標準優化，例如代碼提升(hoisting)、公共的子表達式清除、循環展開(unrolling)、范圍檢測清除、死代碼清除、數據流分析，還有各種在靜態編譯語言中不實用的優化技術，例如虛方法調用的聚合內聯。#p#
持續重新編譯
HotSpot技術另一個有趣的方面是：編譯不是一個全有或者全無(all-or-nothing)的命題。在解釋代碼路徑一定次數之后，會把它重新編譯成機器碼。但是JVM會繼續進行性能分析，而且如果認為代碼路徑特別熱門，或者未來的性能分析數據認為存在額外的優化可能，那么還有可能用更高一級的優化重新編譯代碼。JVM在一個應用程序的執行過程中，可能會把相同的字節碼重新編譯許多次。為了深入了解編譯器做了什么，可以-XX:+PrintCompilation標志調用JVM，這個標志會使編譯器（客戶機或服務器）每次運行的時候打印一條短消息。
棧上(On-stack)替換
HotSpot開始的版本編譯的時候每次編譯一個方法。如果某個方法的累計執行次數超過指定的循環迭代次數（在HotSpot的***版中，是10,000次），那么這個方法就被當作熱門方法，計算的方式是：為每個方法關聯一個計數器，每次執行一個后向分支時，就會遞增計數器一次。但是，在方法編譯之后，方法調用并沒有切換到編譯的版本，需要退出并重新進入方法，后續調用才會使用編譯的版本。結果就是，在某些情況下，可能永遠不會用到編譯的版本，例如對于計算密集型程序，在這類程序中所有的計算都是在方法的一次調用中完成的。重量級方法可能被編譯，但是編譯的代碼永遠用不到。
HotSpot最近的版本采用了稱為棧上(on-stack)替換(OSR)的技術，支持在循環過程中間，從解釋執行切換到編譯的代碼（或者從編譯代碼的一個版本切換到另一個版本）。
從Java編譯、執行優化的原理可以看出，編譯器會將“熱門代碼塊”、“熱門方法”持續優化，以提高性能，再回顧我們常常強調的兩個原則：
1、盡量寫小方法。小方法意味著功能單一、重用性高，自然會被很多地方用到，容易變成“熱門方法”。
2、不重復發明輪子，盡量用已存在的輪子。大家共用一個“輪子”，自然就是“熱門”輪子，Java編譯器會知道這個輪子要好好優化，讓他賺的更快。
【編輯推薦】
