Java虛擬機發(fā)展史

從1996年初sun公司發(fā)布的jdk1.0中所包含的sun Classic VM到今天，曾經(jīng)涌現(xiàn)或消失過許多經(jīng)典和特色的虛擬機出現(xiàn)。Classic VM只能使用純編輯器來執(zhí)行。如果要使用jit編輯器必須使用外掛。執(zhí)行效率和傳統(tǒng)的c/c++程序有很大差異，“Java語言很慢”就是在這個時候在用戶中樹立起來的。

Sun公司努力去解決classvm的問題，為了提升運行效率，在jdk1.2使用了exact vm 它的執(zhí)行系統(tǒng)已經(jīng)具備現(xiàn)代高性能虛擬機的雛形。編譯器和解釋器混合工作模式。雖然比第一代先進了許多，但在商業(yè)中只存在了很短暫的時間就被hotspot vm所取代，甚至還沒來的及發(fā)布windows和linx下的商用版本。

提起hotspotvm。它是sun jdk 和open jdk中所帶的虛擬機，也是目前使用范圍最廣的Java虛擬機。繼承了上兩代虛擬機的優(yōu)點。

熱點代碼和探測技術(shù)，hotSpot熱點探測能力可以通過執(zhí)行計數(shù)器找出最具有編譯價值的代碼，然后通過jit以方法為單位進行編譯。

Java技術(shù)的未來是趨向于模塊化的，技術(shù)平臺越來越復(fù)雜，越來越龐大。當(dāng)單一的Java開發(fā)無法滿足當(dāng)前軟件的復(fù)雜需求，越來越多的Java虛擬機的語言開發(fā)被應(yīng)用到我們的軟件項目中。

如今，cpu硬件的發(fā)展方向已經(jīng)從高頻率轉(zhuǎn)化為多核心，軟件開發(fā)越來越關(guān)注并行編程的領(lǐng)域。Jdk1.5 引入了Java.util.concurrent包實現(xiàn)了粗粒度的并發(fā)框架。而1.7的forkjoin包則包含了對這個框架的一次重要擴充。Jdk1.8提供lambda 極大的改善了Java語言不適合函數(shù)式編程的現(xiàn)狀。在幾年之前，主流的cpu就支持64位架構(gòu)了。，Java也早早地推出了支持64位的版本。

想要精通jdk內(nèi)部的實現(xiàn)機制，最便捷的路徑是自己編譯一套jdk，雖然門檻高很多，但肯定比閱讀書籍，文章更貼近本質(zhì)，怎么獲取jdk源碼？Source bundle releases 獲取打包好的源碼。大概99M，解壓后約 339M。

Java虛擬機在執(zhí)行Java程序的過程中，會把它所管理的內(nèi)存劃分為若干個不同的數(shù)據(jù)區(qū)。這些區(qū)域有各自的用途，有的區(qū)域隨著隨著虛擬機進程的啟動而存在。有些區(qū)域則依賴于用戶線程的啟動和結(jié)束建立和銷毀。

程序計數(shù)器是一塊較小的內(nèi)存空間，它可以看作當(dāng)前線程執(zhí)行字節(jié)碼的行數(shù)指示器。每條線程都需要一個獨立的程序計數(shù)器。線程之間計數(shù)器互不影響。如果線程正在執(zhí)行一個方法，這個計數(shù)器記錄的是正在執(zhí)行的虛擬機字節(jié)碼指令的地址：如果正在執(zhí)行native方法。這個計數(shù)器值則為空，此內(nèi)存區(qū)域是唯一一個虛擬機沒有任何outofmemoryError的區(qū)域。

Java虛擬機棧也是線程私有的，虛擬機棧是Java方法執(zhí)行的內(nèi)存模型，存儲局部變量表，操作數(shù)棧，方法出口，動態(tài)鏈接等信息。如果線程請求的棧深度大于虛擬機所允許的深度，拋出stackOverFlowError。本地方法棧為虛擬機使用native方法使用。

Java堆是管理內(nèi)存中最大的一塊，是所有線程共享，存放對象實例。有的時候也被成為GC堆，采用分代收集算法，分為新生代和老生代 如果堆無法繼續(xù)擴展并且實例無法內(nèi)存分配。拋出outofmemoryError。方法區(qū)和堆一樣，各個線程共享的內(nèi)存區(qū)域。存儲類信息，常量，靜態(tài)變量，即時編譯器編譯后的代碼等數(shù)據(jù)。運行時常量池是方法區(qū)的一部分。直接內(nèi)存并不是虛擬機運行的一部分，也不是Java規(guī)范的內(nèi)存區(qū)域，在jdk1.4加入nio，引入基于通道的緩沖區(qū)的I/o方式，它可以使用native函數(shù)庫直接分配堆外內(nèi)存，這樣顯著提高性能。