早在Java1.0版本的時候，Sun公司發布了一款名為Sun Classic VM的Java虛擬機，它同時也是世界上第一款商用Java虛擬機，在當時這款虛擬機內部只提供解釋器，用今天的眼光來看待必然是效率低下的，因為如果Java虛擬機只能夠在運行時對代碼采用逐行解釋執行，程序的運行性能可想而知。但是如今的HotSpot VM中不僅內置有解釋器，還內置有先進的JIT（Just In Time Compiler）編譯器，在Java虛擬機運行時，解釋器和即時編譯器能夠相互協作，各自取長補短。在此大家需要注意，無論是采用解釋器進行解釋執行，還是采用即時編譯器進行編譯執行，最終字節碼都需要被轉換為對應平臺的本地機器指令。或許有些開發人員會感覺到詫異，既然HotSpot VM中已經內置JIT編譯器了，那么為什么還需要再使用解釋器來“拖累”程序的執行性能呢？比如JRockit VM內部就不包含解釋器，字節碼全部都依靠即時編譯器編譯后執行，盡管程序的執行性能會非常高效，但程序在啟動時必然需要花費更長的時間來進行編譯。對于服務端應用來說，啟動時間并非是關注重點，但對于那些看中啟動時間的應用場景而言，或許就需要采用解釋器與即時編譯器并存的架構來換取一個平衡點。

既然HotSpot VM中采用了即時編譯器，那么這就意味著將字節碼編譯為本地機器指令是一件運行時任務。在HotSpot VM中內嵌有兩個JIT編譯器，分別為Client Compiler和Server Compiler，但大多數情況下我們簡稱為C1編譯器和C2編譯器。開發人員可以通過如下命令顯式指定Java虛擬機在運行時到底使用哪一種即時編譯器，如下所示：

-client：指定Java虛擬機運行在Client模式下，并使用C1編譯器；

-server：指定Java虛擬機運行在Server模式下，并使用C2編譯器。

除了可以顯式指定Java虛擬機在運行時到底使用哪一種即時編譯器外，默認情況下HotSpot VM則會根據操作系統版本與物理機器的硬件性能自動選擇運行在哪一種模式下，以及采用哪一種即時編譯器。簡單來說，C1編譯器會對字節碼進行簡單和可靠的優化，以達到更快的編譯速度；而C2編譯器會啟動一些編譯耗時更長的優化，以獲取更好的編譯質量。不過在Java7版本之后，一旦開發人員在程序中顯式指定命令“-server”時，缺省將會開啟分層編譯（Tiered Compilation）策略，由C1編譯器和C2編譯器相互協作共同來執行編譯任務。不過在早期版本中，開發人員則只能夠通過命令“-XX:+TieredCompilation”手動開啟分層編譯策略。

之前筆者曾經提及過，缺省情況下HotSpot VM是采用解釋器與即時編譯器并存的架構，當然開發人員可以根據具體的應用場景，通過命令顯式地為Java虛擬機指定在運行時到底是完全采用解釋器執行，還是完全采用即時編譯器執行。如下所示：

-Xint：完全采用解釋器模式執行程序；

-Xcomp：完全采用即時編譯器模式執行程序；

-Xmixed：采用解釋器+即時編譯器的混合模式共同執行程序。

在此大家需要注意，如果Java虛擬機在運行時完全采用解釋器執行，那么即時編譯器將會停止所有的工作，字節碼將完全依靠解釋器逐行解釋執行。反之如果Java虛擬機在運行時完全采用即時編譯器執行，但解釋器仍然會在即時編譯器無法進行的特殊情況下介入執行，以確保程序能夠最終順利執行。

由于即時編譯器將本地機器指令的編譯推遲到了運行時，自此Java程序的運行性能已經達到了可以和C/C++程序一較高下的地步。這主要是因為JIT編譯器可以針對那些頻繁被調用的“熱點代碼”做出深度優化，而靜態編譯器的代碼優化則無法完全推斷出運行時熱點，因此通過JIT編譯器編譯的本地機器指令比直接生成的本地機器指令擁有更高的執行效率也就理所當然了。比如使用Python實現的PyPy執行器，比使用C實現的CPython解釋器更加靈活，更重要的是，在程序的運行性能上進行比較，PyPy將近是CPython解釋器執行效率的1至5倍，這就是對JIT技術魅力的一個有力證明。并且Java技術自身的諸多優勢同樣也是C/C++無法比擬的，所謂各有所長就是這個道理。在此大家需要注意，世界上永遠沒有最好的編程語言，只有最適用于具體應用場景的編程語言。

總結

以上是生活随笔為你收集整理的java 解释器与JIT编译器的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。