我們知道要執行java代碼需要編譯器將其編譯爲字節碼文件，再由jvm去翻譯字節碼文件。
其實jvm(HotSpot爲例)翻譯字節碼文件分爲兩種方式，一種是解釋執行，另一種是即時編譯（Just-in-Time compilation,JIT）。所謂解釋執行就是邊翻譯爲機器碼邊執行，而即時編譯就是先將一個方法中的所有字節碼全部編譯成機器碼之後再執行。
前者的優勢在於無需等待編譯，而後者的優勢在於執行速度更快。在HotSpot中默認採用混合模式，其先解釋執行字節碼，然後將其中的熱點代碼(多次執行，循環等)直接編譯成機器碼，下次就不用再編譯了，讓其更快速地運行。
但是在生產環境中，爲何不都採用即時編譯的模式呢？如果服務端的代碼改動的頻率不高，花點時間去編譯，且不是在運行時能夠獲得更高的效率？
即時編譯運行速度確實快，但是全部採用即時編譯的話，jvm無法獲得程序的運行時信息，這就使得jvm無法對代碼進行很好的優化，而如果先執行進行解釋執行的話，是真真實實把整個代碼都跑了一遍，jvm知道哪裏有坑,哪裏需要重點關注，jvm會根據代碼的執行情況進行更多的優化，而不僅僅是編譯爲機器碼；再者我們的代碼其實也符合二八定律，即80%的代碼都不用佔用虛擬機很多的計算資源，大約爲20%，而對於20%的熱點代碼需要消耗虛擬機80%的計算資源。
編譯完的機器碼需存儲到磁盤上，這也需要佔用比較大的存儲空間，想想，我們這裏很大一部分代碼根本就不需要消耗我很多的計算成本的，而需要佔用大量的磁盤空間，這樣看也是划不來的～