Java編譯和解釋執行對比及原理解析

編程語言分為低級語言和高級語言，機器語言、彙編語言是低級語言，C、C++、java、python等是高級語言。
機器語言是最底層的語言，能夠直接執行。而我們編寫的源代碼是人類語言, 計算機只能識別某些特定的二進制指令，在程序真正運行之前必須將源代碼轉換成二進制指令。
彙編語言通過彙編器翻譯成機器指令後執行，一條彙編指令，對應著一條機器指令。
高級語言編程的程序有三種執行方式：
1.一種是編譯執行，源程序先通過編譯器（負責將源程序翻譯成目標機器指令）翻譯成機器指令，通過編譯-->鏈接-->目標可執行文件，然後執行；即提前將所有源代碼一次性轉換成二進制指令，也就是生成一個可執行程序。比如C，C++等語言都是編譯執行的。
2.一種是解釋執行，是使用解釋器會將我們的一句句代碼解釋成機器可以識別的二進制代碼來執行，可以認為是，解釋一句，執行一句。在這個過程中，不會生成中間文件。如：腳本方式是一條條命令，在執行時，是由系統的解釋器，將其一條條翻譯成機器可識別的指令，例如shell腳本是由shell程序執行的，js是由瀏覽器解釋執行的。
3.最後一種是編譯和解釋相結合的執行方式，下面我們來說Java。
理解Java的幾個編譯器
前端編譯器：把.java文件轉變成.class文件。包括Sun的Javac、Eclipse JDT中的增量式編輯器（ECJ）
後端運行期即時編譯器（JIT編譯器，Just In Time Compiler）：把字節碼轉成機器碼。包括HotSpot VM的C1、C2編譯器
靜態提前編譯器（AOT編譯器，Ahead Of Time Compiler）：把*.java編譯成本地機器碼。包括GNU Compiler for the Java（GCJ）、Excelsior JET
Java採用的是解釋和編譯混合的模式
在編譯時期，我們通過將源代碼編譯成.class ，配合JVM這種跨平臺的抽象，屏蔽了底層計算機操作系統和硬件的區別，實現了“一次編譯，到處運行” 。 而在運行時期，目前主流的JVM 都是混合模式（-Xmixed），即解釋運行 和編譯運行配合使用。
Java一開始被定位為“解釋執行”的語言，但是現在主流的虛擬機中都包含了即時編譯器JIT。
程序從源代碼到運行經歷階段：java程序--（編譯javac）-->字節碼文件.class-->類裝載子系統化身為反射類Class--->運行時數據區--->（解釋執行+JIT編譯器編譯）-->操作系統（Win，Linux，Mac JVM）。
.class文件就是可以到處運行的文件。然後Java字節碼會被轉化為目標機器代碼，這是是由JVM來執行的，即Java的第二次編譯。
Java採用的是解釋和編譯混合的模式。它首先通過javac將源碼編譯成字節碼文件class.然後在運行的時候通過解釋器或者JIT將字節碼轉換成最終的機器碼。
JIT將字節碼轉換成最終的機器碼：
以 Oracle JDK提供的HotSpot虛擬機為例，在HotSpot虛擬機中，提供了兩種編譯模式：解釋執行 和 即時編譯（JIT，Just-In-Time）。解釋執行即逐條翻譯字節碼為可運行的機器碼，而即時編譯則以方法為單位將字節碼翻譯成機器碼（上述提到的“編譯執行”）。前者的優勢在於不用等待，後者則在實際運行當中效率更高。
即時編譯存在的意義在於它是提高程序性能的重要手段之一。根據“二八定律”（即：百分之二十的代碼佔據百分之八十的系統資源），對於大部分不常用的代碼，我們無需耗時間將之編譯為機器碼，而是採用解釋執行的方式，用到就去逐條解釋運行；對於一些僅佔據小部分的熱點代碼（可認為是反覆執行的重要代碼），則可將之翻譯為符合機器的機器碼高效執行，提高程序的效率，此為運行時的即時編譯。
為了滿足不同的場景，HotSpot虛擬機內置了多個即時編譯器：C1,C2與Graal。Graal 是Java10正式引入的實驗性即時編譯器，在此暫不敘述（其實我不是很瞭解，尷尬・・・）。先看一下C1、C2 ，相信大家或多或少接觸過。
C1：即Client編譯器，面向對啟動性能有要求的客戶端GUI程序，採用的優化手段比較簡單，因此編譯的時間較短。
C2：即Server編譯器，面向對性能峰值有要求的服務端程序，採用的優化手段複雜，因此編譯時間長，但是在運行過程中性能更好。
從Java7開始，HotSpot虛擬機默認採用分層編譯的方式：熱點方法首先被C1編譯器編譯，而後 熱點方法中的熱點再進一步被C2編譯，根據前面的運行計算出更優的編譯優化。為了不干擾程序的正常運行，JIT編譯時放在額外的線程中執行的，HotSpot根據實際CPU的資源，以 1:2的比例分配給C1和C2線程數。在計算機資源充足的情況，字節碼的解釋運行和編譯運行時可以同時進行，JIT編譯執行完後的機器碼會在下次調用該方法時啟動，已替換原本的解釋執行（意思就是已經翻譯出效率更高的機器碼，自然替換原來的相對低效率執行的方法）。
以上，可以看出在Java中不單單是解釋執行，即時編譯（編譯執行）在Java性能優化中彰顯重要的作用，所以現在應該說：Java是解釋執行和編譯執行共同存在的，至少大部分是這樣。
編譯與解釋比較？
1.一段程序編譯會浪費時間，並且移植到其他平臺上時還要進行重新編譯，但是其編譯後生成的可執行文件運行速度快。
2.解釋型程序可跨平臺執行，無需將全部代碼編譯之後再運行，能夠及時運行，但因為是逐條解釋執行所以最終的運行速度不如編譯型程序。
3.內存使用：編譯執行需要生成編譯後的機器碼文件，而解釋執行時逐句解釋執行，所以解釋執行對內存佔用更少。
單獨使用解釋器的缺點：
拋棄了JIT可能帶來的性能優勢。如果代碼沒有被JIT編譯的話，再次運行時需要重複解析。
單獨使用JIT編譯器的缺點：
需要將全部的代碼編譯成本地機器碼。要花更多的時間，JVM啟動會變慢非常多；
增加可執行代碼的長度（字節碼比JIT編譯後的機器碼小很多），這將導致頁面調度，從而降低程序的速度。
有些JIT編譯器的優化方式，比如分支預測，如果不進行profiling，往往並不能進行有效優化。
因此，HotSpot採用了惰性評估(Lazy Evaluation)的做法，根據二八定律，消耗大部分系統資源的只有那一小部分的代碼（熱點代碼），而這也就是JIT所需要編譯的部分。JVM會根據代碼每次被執行的情況收集信息並相應地做出一些優化，因此執行的次數越多，它的速度就越快。
JDK 9引入了一種新的編譯模式AOT(Ahead of Time Compilation)，它是直接將字節碼編譯成機器碼，這樣就避免了JIT預熱等各方面的開銷。JDK支持分層編譯和AOT協作使用。
注：JIT為方法級，它會緩存編譯過的字節碼在CodeCache中，而不需要被重複解釋。