虛擬機梗概
JDK
Java程序設計語言、 Java虛擬機、 Java API類庫這三部分統稱爲JDK（Java Development
Kit），JDK是用於支持Java程序開發的最小環境
JRE
Java API類庫中的JavaSE API子集、Java虛擬機這兩部分統稱爲JRE（Java Runtime
Environment），JRE是支持Java程序運行的標準環境
（Java技術體系中所包含的內容）
技術服務領域
可以劃分爲以下四種
Java Card
支持一些Java小程序（Applets）運行在小內存設備（如智能卡）上的平臺。
Java ME（Micro Edition）
支持Java程序運行在移動終端（手機、 PDA）上的平臺，對Java API有所精簡，並加入了針對移動終端的支持，這個版本以前稱爲J2ME。
Java SE（Standard Edition）
支持面向桌面級應用（如Windows下的應用程序）的Java平臺，提供了完整的Java核心API，這個版本以前稱爲J2SE。
Java EE（Enterprise Edition）
支持使用多層架構的企業應用（如ERP、 CRM應用）的Java平臺，除了提供Java SE API外，還對其做了大量的擴充[3]並提供了相關的部署支持，以前稱爲J2EE
衆多虛擬機
Sun Classic
第一款商用虛擬機，純解釋器的方式執行java代碼，當然可以選擇外掛一個JIT編譯器來工作。
由於解釋器和編譯器不能配合工作， 這就意味着如果要使用編譯器執行
編譯器就不得不對每一個方法、 每一行代碼都進行編譯
無論它們執行的頻率是否具有編譯的價值
基於程序響應時間的壓力， 這些編譯器根本不敢應用編譯耗時稍高的優化技術
因此這個階段的虛擬機即使用了JIT編譯器輸出本地代碼， 執行效率也和傳統的C/C++程序有很大差距
Exact VM
一個短暫存在的爲了解決Classic存在的，基本具備現代虛擬機的特性，編譯器之間與解釋器的混合工作模式，以及準確的內存管理而成名。
例如一個32位整數，虛擬機知道他是引用類型指向的一個內存地址，還是一個數值爲X的整數。這樣就可以準確的進行GC管理。
Exact還未發行windows / linux版本即被未來更優秀的HotSpot取代。
Sun HotSpot VM
C:\Users\Administrator>java -version
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b15, mixed mode)HotSpot VM的熱點代碼探測能力可以通過執行計數器找出最具有編譯價值的代碼， 然後通知JIT編譯器以方法爲單位進行編譯。
如果一個方法被頻繁調用， 或方法中有效循環次數很多， 將會分別觸發標準編譯和OSR（ 棧上替換） 編譯動作。
通過編譯器與解釋器恰當地協同工作， 可以在最優化的程序響應時間與最佳執行性能中取得平衡， 即時編譯的時間壓力也相對減小
@@>>>OSR棧上替換和標準編譯
@@>>>熱點代碼探測
@@>>>解釋器與編譯器
Sun Mobile-Embedded VM/Meta-Circular VM
Sun公司研發的衆多虛擬機中有一部分是面向研究，驗證觀點或一些陌生的標準規範以及特殊領域的存在
KVM
“Android ios 出現前在手機平臺中曾得到廣泛應用”
CDC/CLDC HotSpot Implementation
“希望規範手機，電子書，pad等設備中的java接口規範，但是現不容樂觀”
Squawk VM
“運行在sum spot（一種手持小型wifi設備），其中除了i/o和非必要的本地代碼外基本都是用java實現”
JavaInJava
“實驗性項目，目的是用java來實現java vm，達成“元循環”的思想，內部沒有編譯器只能依賴解模式執行，性能問題未得到解決”
Maxine VM
“可以理解爲帶有JIT編譯器的JavaInJava性能接近Hotspot，仍在發展中”
BEA JRockit/IBM J9 VM
JRockit 無解釋器，全依賴即時編譯執行。其爲專門爲服務器硬件和服務器應用場景優化的虛擬機，專注服務器端應用，對啓動不太關注。
J9 一款多用途商用的IBM虛擬機，主要針對IBM WebSphere等IBM產品
Azul VM/BEA Liquid VM
Azul是Hotspot針對Azul公司專有硬件Vega系統而優化的硬件平臺虛擬機
Liquid則是BEA針對自家Hypervisor系統上JRockit的虛擬化版本，自身成爲系統直接控制硬件最大效能發揮能力。
64位JDK
Java程序運行在64位虛擬機上需要付出比較大的額外代價：
內存問題， 由於指針膨脹（更寬的尋址）和各種數據類型對齊補白的原因， 通常要比32位系統額外增加10%～ 30%的內存消耗
機構的測試結果顯示， 64位虛擬機的運行速度在各個測試項中幾乎全面落後於32位虛擬機， 兩者大約有15%左右的性能差距
在Java EE方面， 企業級應用經常需要超過4GB的內存， 對於64位虛擬機的需求是非常迫切的
在JDK 1.6 Update 14之後， 提供了普通對象指針壓縮功能
@@>>>指針壓縮