jdk

1991年4月,由James Gosling主導(dǎo)的團(tuán)隊(duì)創(chuàng)造了Oak語(yǔ)言,java的前身,1995年5月23號(hào),Oak語(yǔ)言更名Java,并且提出那句注明的:”write Once,Run Anywhere”的口號(hào).1996年1月23日,JDK1.0發(fā)布.

當(dāng)時(shí)正好趕上瀏覽器快速崛起,發(fā)展的浪潮,大家發(fā)現(xiàn)java一處編譯到處使用的特性和瀏覽器很契合,同一個(gè)頁(yè)面不可能每一個(gè)操作系統(tǒng)我都寫一遍.用現(xiàn)在的話說(shuō)java正好站在這個(gè)風(fēng)口上.導(dǎo)致它飛速發(fā)展才有了今天的江湖地位.

一、JVM簡(jiǎn)介

JVM是Java Virtual Machine（Java虛擬機(jī)）的縮寫，JVM是一種用于計(jì)算設(shè)備的規(guī)范，它是一個(gè)虛構(gòu)出來(lái)的計(jì)算機(jī)，是通過(guò)在實(shí)際的計(jì)算機(jī)上仿真模擬各種計(jì)算機(jī)功能來(lái)實(shí)現(xiàn)的。Java虛擬機(jī)包括一套字節(jié)碼指令集、一組寄存器、一個(gè)棧、一個(gè)垃圾回收堆和一個(gè)存儲(chǔ)方法域。 JVM屏蔽了與具體操作系統(tǒng)平臺(tái)相關(guān)的信息，使Java程序只需生成在Java虛擬機(jī)上運(yùn)行的目標(biāo)代碼（字節(jié)碼）,就可以在多種平臺(tái)上不加修改地運(yùn)行。JVM在執(zhí)行字節(jié)碼時(shí)，實(shí)際上最終還是把字節(jié)碼解釋成具體平臺(tái)上的機(jī)器指令執(zhí)行。

Java語(yǔ)言的一個(gè)非常重要的特點(diǎn)就是與平臺(tái)的無(wú)關(guān)性。而使用Java虛擬機(jī)是實(shí)現(xiàn)這一特點(diǎn)的關(guān)鍵。一般的高級(jí)語(yǔ)言如果要在不同的平臺(tái)上運(yùn)行，至少需要編譯成不同的目標(biāo)代碼。而引入Java語(yǔ)言虛擬機(jī)后，Java語(yǔ)言在不同平臺(tái)上運(yùn)行時(shí)不需要重新編譯。Java語(yǔ)言使用Java虛擬機(jī)屏蔽了與具體平臺(tái)相關(guān)的信息，使得Java語(yǔ)言編譯程序只需生成在Java虛擬機(jī)上運(yùn)行的目標(biāo)代碼（字節(jié)碼），就可以在多種平臺(tái)上不加修改地運(yùn)行。Java虛擬機(jī)在執(zhí)行字節(jié)碼時(shí)，把字節(jié)碼解釋成具體平臺(tái)上的機(jī)器指令執(zhí)行。這就是Java的能夠“一次編譯，到處運(yùn)行”的原因。

二、JVM的組成

我們先把JVM這個(gè)虛擬機(jī)畫出來(lái)，如下圖所示：

從這張圖中我們可以看出，JVM是運(yùn)行在操作系統(tǒng)之上的，它與硬件沒(méi)有直接的交互，我們?cè)賮?lái)看JVM由哪些部分組成，如下圖所示：

1、Class Loader 類加載器

類加載器的作用是加載類文件到內(nèi)存，比如編寫一個(gè)HelloWord.java 程序，然后通過(guò)javac 編譯成class 文件，那怎么才能加載到內(nèi)存中被執(zhí)行呢？Class Loader 承擔(dān)的就是這個(gè)責(zé)任，那不可能隨便建立一個(gè).class 文件就能被加載的，Class Loader 加載的class 文件是有格式要求。

Class Loader 只管加載，只要符合文件結(jié)構(gòu)就加載，至于說(shuō)能不能運(yùn)行，則不是它負(fù)責(zé)的，那是由Execution Engine 負(fù)責(zé)的。

2、Execution Engine 執(zhí)行引擎

執(zhí)行引擎也叫做解釋器(Interpreter) ，負(fù)責(zé)解釋命令，提交操作系統(tǒng)執(zhí)行。

3、Native Interface 本地接口

本地接口的作用是融合不同的編程語(yǔ)言為Java 所用，它的初衷是融合C/C++ 程序，Java 誕生的時(shí)候是C/C++ 橫行的時(shí)候，要想立足，必須有一個(gè)聰明的、睿智的調(diào)用C/C++ 程序，于是就在內(nèi)存中專門開辟了一塊區(qū)域處理標(biāo)記為native 的代碼，它的具體做法是Native Method Stack 中登記native 方法，在Execution Engine 執(zhí)行時(shí)加載native libraies 。目前該方法使用的是越來(lái)越少了，除非是與硬件有關(guān)的應(yīng)用，比如通過(guò)Java 程序驅(qū)動(dòng)打印機(jī)，或者Java 系統(tǒng)管理生產(chǎn)設(shè)備，在企業(yè)級(jí)應(yīng)用中已經(jīng)比較少見，因?yàn)楝F(xiàn)在的異構(gòu)領(lǐng)域間的通信很發(fā)達(dá)，比如可以使用Socket 通信，也可以使用Web Service 等等，不多做介紹。

4、 Runtime data area 運(yùn)行數(shù)據(jù)區(qū)

運(yùn)行數(shù)據(jù)區(qū)是整個(gè)JVM 的重點(diǎn)。我們所有寫的程序都被加載到這里，之后才開始運(yùn)行，Java 生態(tài)系統(tǒng)如此的繁榮，得益于該區(qū)域的優(yōu)良自治。

整個(gè)JVM 框架由加載器加載文件，然后執(zhí)行器在內(nèi)存中處理數(shù)據(jù)，需要與異構(gòu)系統(tǒng)交互是可以通過(guò)本地接口進(jìn)行，瞧，一個(gè)完整的系統(tǒng)誕生了！

三、JVM的內(nèi)存管理

所有的數(shù)據(jù)和程序都是在運(yùn)行數(shù)據(jù)區(qū)存放，它包括以下幾部分：

1、 Stack 棧

棧也叫棧內(nèi)存，是Java程序的運(yùn)行區(qū)，是在線程創(chuàng)建時(shí)創(chuàng)建，它的生命期是跟隨線程的生命期，線程結(jié)束棧內(nèi)存也就釋放，對(duì)于棧來(lái)說(shuō)不存在垃圾回收問(wèn)題，只要線程一結(jié)束，該棧就Over。問(wèn)題出來(lái)了：棧中存的是那些數(shù)據(jù)呢？又什么是格式呢？

棧中的數(shù)據(jù)都是以棧幀（Stack Frame）的格式存在，棧幀是一個(gè)內(nèi)存區(qū)塊，是一個(gè)數(shù)據(jù)集，是一個(gè)有關(guān)方法(Method)和運(yùn)行期數(shù)據(jù)的數(shù)據(jù)集，當(dāng)一個(gè)方法A被調(diào)用時(shí)就產(chǎn)生了一個(gè)棧幀F(xiàn)1，并被壓入到棧中，A方法又調(diào)用了B方法，于是產(chǎn)生棧幀F(xiàn)2也被壓入棧，執(zhí)行完畢后，先彈出F2棧幀，再?gòu)棾鯢1棧幀，遵循“先進(jìn)后出”原則。

那棧幀中到底存在著什么數(shù)據(jù)呢？棧幀中主要保存3類數(shù)據(jù)：本地變量（Local Variables），包括輸入?yún)?shù)和輸出參數(shù)以及方法內(nèi)的變量；棧操作（Operand Stack），記錄出棧、入棧的操作；棧幀數(shù)據(jù)（Frame Data），包括類文件、方法等等。光說(shuō)比較枯燥，我們畫個(gè)圖來(lái)理解一下Java棧，如下圖所示：

示在一個(gè)棧中有兩個(gè)棧幀，棧幀2是最先被調(diào)用的方法，先入棧，然后方法2又調(diào)用了方法1，棧幀1處于棧頂?shù)奈恢茫瑮?處于棧底，執(zhí)行完畢后，依次彈出棧幀1和棧幀2，線程結(jié)束，棧釋放。

2、Heap 堆內(nèi)存

jvm中分為堆和方法區(qū)，**堆**又進(jìn)一步分為**新生代和老年代，方法區(qū)為永久代。**

堆中區(qū)分的新生代和老年代是為了垃圾回收，新生代中的對(duì)象存活期一般不長(zhǎng)，而老年代中的對(duì)象存活期較長(zhǎng)，所以當(dāng)垃圾回收器回收內(nèi)存時(shí)，新生代中垃圾回收效果較好，會(huì)回收大量的內(nèi)存，而老年代中回收效果較差，內(nèi)存回收不會(huì)太多。

基于以上特性，新生代中一般采用復(fù)制算法，因?yàn)榇婊钕聛?lái)的對(duì)象是少數(shù)，所需要復(fù)制的對(duì)象少，而老年代對(duì)象存活多，不適合采用復(fù)制算法，一般是標(biāo)記整理和標(biāo)記清除算法。

因?yàn)閺?fù)制算法需要留出一塊單獨(dú)的內(nèi)存空間來(lái)以備垃圾回收時(shí)復(fù)制對(duì)象使用，所以將新生代分為eden區(qū)和兩個(gè)survivor區(qū)，每次使用eden和一個(gè)survivor區(qū)，另一個(gè)survivor作為備用的對(duì)象復(fù)制內(nèi)存區(qū)。

一個(gè)JVM實(shí)例只存在一個(gè)堆類存，堆內(nèi)存的大小是可以調(diào)節(jié)的。類加載器讀取了類文件后，需要把類、方法、常變量放到堆內(nèi)存中，以方便執(zhí)行器執(zhí)行，堆內(nèi)存分為三部分：

Permanent Space 永久存儲(chǔ)區(qū)

永久存儲(chǔ)區(qū)是一個(gè)常駐內(nèi)存區(qū)域，用于存放JDK自身所攜帶的Class,Interface的元數(shù)據(jù)，也就是說(shuō)它存儲(chǔ)的是運(yùn)行環(huán)境必須的類信息，被裝載進(jìn)此區(qū)域的數(shù)據(jù)是不會(huì)被垃圾回收器回收掉的，關(guān)閉JVM才會(huì)釋放此區(qū)域所占用的內(nèi)存。

Young Generation Space 新生區(qū)

新生區(qū)是類的誕生、成長(zhǎng)、消亡的區(qū)域，一個(gè)類在這里產(chǎn)生，應(yīng)用，最后被垃圾回收器收集，結(jié)束生命。新生區(qū)又分為兩部分：伊甸區(qū)（Eden space）和幸存者區(qū)（Survivor pace），所有的類都是在伊甸區(qū)被new出來(lái)的。幸存區(qū)有兩個(gè)： 0區(qū)（Survivor 0 space）和1區(qū)（Survivor 1 space）。當(dāng)伊甸園的空間用完時(shí)，程序又需要?jiǎng)?chuàng)建對(duì)象，JVM的垃圾回收器將對(duì)伊甸園區(qū)進(jìn)行垃圾回收，將伊甸園區(qū)中的不再被其他對(duì)象所引用的對(duì)象進(jìn)行銷毀。然后將伊甸園中的剩余對(duì)象移動(dòng)到幸存0區(qū)。若幸存0區(qū)也滿了，再對(duì)該區(qū)進(jìn)行垃圾回收，然后移動(dòng)到1區(qū)。那如果1區(qū)也滿了呢？再移動(dòng)到養(yǎng)老區(qū)。

Tenure generation space養(yǎng)老區(qū)

養(yǎng)老區(qū)用于保存從新生區(qū)篩選出來(lái)的JAVA對(duì)象，一般池對(duì)象都在這個(gè)區(qū)域活躍。 三個(gè)區(qū)的示意圖如下：

3、 Method Area 方法區(qū)

方法區(qū)是被所有線程共享，該區(qū)域保存所有字段和方法字節(jié)碼，以及一些特殊方法如構(gòu)造函數(shù)，接口代碼也在此定義。

4、PC Register 程序計(jì)數(shù)器

每個(gè)線程都有一個(gè)程序計(jì)數(shù)器，就是一個(gè)指針，指向方法區(qū)中的方法字節(jié)碼，由執(zhí)行引擎讀取下一條指令。

四、JVM垃圾回收

GC (Garbage Collection)的基本原理：將內(nèi)存中不再被使用的對(duì)象進(jìn)行回收，GC中用于回收的方法稱為收集器，由于GC需要消耗一些資源和時(shí)間，Java在對(duì)對(duì)象的生命周期特征進(jìn)行分析后，按照新生代、舊生代的方式來(lái)對(duì)對(duì)象進(jìn)行收集，以盡可能的縮短GC對(duì)應(yīng)用造成的暫停

（1）對(duì)新生代的對(duì)象的收集稱為minor GC；

（2）對(duì)舊生代的對(duì)象的收集稱為Full GC；

（3）程序中主動(dòng)調(diào)用System.gc()強(qiáng)制執(zhí)行的GC為Full GC。

不同的對(duì)象引用類型， GC會(huì)采用不同的方法進(jìn)行回收，JVM對(duì)象的引用分為了四種類型：

（1）強(qiáng)引用：默認(rèn)情況下，對(duì)象采用的均為強(qiáng)引用（這個(gè)對(duì)象的實(shí)例沒(méi)有其他對(duì)象引用，GC時(shí)才會(huì)被回收）

（2）軟引用：軟引用是Java中提供的一種比較適合于緩存場(chǎng)景的應(yīng)用（只有在內(nèi)存不夠用的情況下才會(huì)被GC）

（3）弱引用：在GC時(shí)一定會(huì)被GC回收

（4）虛引用：由于虛引用只是用來(lái)得知對(duì)象是否被GC

四、JVM的發(fā)展

1.Sun Classic / Exact VM

以今天的視角來(lái)看，Sun Classic VM的技術(shù)可能很原始，這款虛擬機(jī)的使命也早已終結(jié)。但僅憑它“世界上第一款商用Java虛擬機(jī)”的頭銜，就足夠有讓歷史記住它的理由。

1996年1月23日，Sun公司發(fā)布JDK 1.0，Java語(yǔ)言首次擁有了商用的正式運(yùn)行環(huán)境，這個(gè)JDK中所帶的虛擬機(jī)就是Classic VM。這款虛擬機(jī)只能使用純解釋器方式來(lái)執(zhí)行Java代碼，如果要使用JIT編譯器，就必須進(jìn)行外掛。但是假如外掛了JIT編譯器，JIT編譯器就完全接管了虛擬機(jī)的執(zhí)行系統(tǒng)，解釋器便不再工作了。用戶在這款虛擬機(jī)上執(zhí)行java -version命令，將會(huì)看到類似下面這行輸出：

1. java version "1.2.2"

2. Classic VM (build JDK-1.2.2-001, green threads, sunwjit)

Sun的虛擬機(jī)團(tuán)隊(duì)努力去解決Classic VM所面臨的各種問(wèn)題，提升運(yùn)行效率。在JDK 1.2時(shí)，曾在Solaris平臺(tái)上發(fā)布過(guò)一款名為Exact VM的虛擬機(jī)，它的執(zhí)行系統(tǒng)已經(jīng)具備現(xiàn)代高性能虛擬機(jī)的雛形：如兩級(jí)即時(shí)編譯器、編譯器與解釋器混合工作模式等。Exact VM因它使用準(zhǔn)確式內(nèi)存管理（Exact Memory Management，也可以叫Non-Conservative/Accurate Memory Management）而得名，即虛擬機(jī)可以知道內(nèi)存中某個(gè)位置的數(shù)據(jù)具體是什么類型。雖然Exact VM的技術(shù)相對(duì)Classic VM來(lái)說(shuō)先進(jìn)了許多，但是在商業(yè)應(yīng)用上只存在了很短暫的時(shí)間就被更為優(yōu)秀的HotSpot VM所取代，甚至還沒(méi)有來(lái)得及發(fā)布Windows和Linux平臺(tái)下的商用版本。而Classic VM的生命周期則相對(duì)長(zhǎng)了許多，它在JDK 1.2之前是Sun JDK中唯一的虛擬機(jī)，在JDK 1.2時(shí)，它與HotSpot VM并存，但默認(rèn)使用的是Classic VM（用戶可用java-hotspot參數(shù)切換至HotSpot VM），而在JDK 1.3時(shí)，HotSpot VM成為默認(rèn)虛擬機(jī)，但Classic VM仍作為虛擬機(jī)的“備用選擇”發(fā)布（使用java-classic參數(shù)切換），直到JDK 1.4的時(shí)候，Classic VM才完全退出商用虛擬機(jī)的歷史舞臺(tái)，與Exact VM一起進(jìn)入了Sun Labs Research VM之中。

2.Sun HotSpot VM**

提起HotSpot VM，相信所有Java程序員都知道，它是Sun JDK和OpenJDK中所帶的虛擬機(jī)，也是目前使用范圍最廣的Java虛擬機(jī)。但不一定所有人都知道的是，這個(gè)目前看起來(lái)“血統(tǒng)純正”的虛擬機(jī)在最初并非由Sun公司開發(fā)，而是由一家名為“Longview Technologies”的小公司設(shè)計(jì)的；甚至這個(gè)虛擬機(jī)最初并非是為Java語(yǔ)言而開發(fā)的，它來(lái)源于Strongtalk VM，而這款虛擬機(jī)中相當(dāng)多的技術(shù)又是來(lái)源于一款支持Self語(yǔ)言實(shí)現(xiàn)“達(dá)到C語(yǔ)言50%以上的執(zhí)行效率”的目標(biāo)而設(shè)計(jì)的虛擬機(jī)，Sun公司注意到了這款虛擬機(jī)在JIT編譯上有許多優(yōu)秀的理念和實(shí)際效果，在1997年收購(gòu)了Longview Technologies公司，從而獲得了HotSpot VM。

HotSpot VM既繼承了Sun之前兩款商用虛擬機(jī)的優(yōu)點(diǎn)，也有許多自己新的技術(shù)優(yōu)勢(shì)，如它名稱中的HotSpot指的就是它的熱點(diǎn)代碼探測(cè)技術(shù)，HotSpot VM的熱點(diǎn)代碼探測(cè)能力可以通過(guò)執(zhí)行計(jì)數(shù)器找出最具有編譯價(jià)值的代碼，然后通知JIT編譯器以方法為單位進(jìn)行編譯。如果一個(gè)方法被頻繁調(diào)用，或方法中有效循環(huán)次數(shù)很多，將會(huì)分別觸發(fā)標(biāo)準(zhǔn)編譯和OSR（棧上替換）編譯動(dòng)作。通過(guò)編譯器與解釋器恰當(dāng)?shù)貐f(xié)同工作，可以在最優(yōu)化的程序響應(yīng)時(shí)間與最佳執(zhí)行性能中取得平衡，而且無(wú)須等待本地代碼輸出才能執(zhí)行程序，即時(shí)編譯的時(shí)間壓力也相對(duì)減小，這樣有助于引入更多的代碼優(yōu)化技術(shù)，輸出質(zhì)量更高的本地代碼。

在2006年的JavaOne大會(huì)上，Sun公司宣布最終會(huì)把Java開源，并在隨后的一年，陸續(xù)將JDK的各個(gè)部分（其中當(dāng)然也包括了HotSpot VM）在GPL協(xié)議下公開了源碼，并在此基礎(chǔ)上建立了OpenJDK。這樣，HotSpot VM便成為了Sun JDK和OpenJDK兩個(gè)實(shí)現(xiàn)極度接近的JDK項(xiàng)目的共同虛擬機(jī)。

在2008年和2009年，Oracle公司分別收購(gòu)了BEA公司和Sun公司，這樣Oracle就同時(shí)擁有了兩款優(yōu)秀的Java虛擬機(jī)：JRockit VM和HotSpot VM。Oracle公司宣布在不久的將來(lái)（大約應(yīng)在發(fā)布JDK 8的時(shí)候）會(huì)完成這兩款虛擬機(jī)的整合工作，使之優(yōu)勢(shì)互補(bǔ)。整合的方式大致上是在HotSpot的基礎(chǔ)上，移植JRockit的優(yōu)秀特性，譬如使用JRockit的垃圾回收器與MissionControl服務(wù)，使用HotSpot的JIT編譯器與混合的運(yùn)行時(shí)系統(tǒng)。

3. Sun Mobile-Embedded VM / Meta-Circular VM

Sun公司所研發(fā)的虛擬機(jī)可不僅有前面介紹的服務(wù)器、桌面領(lǐng)域的商用虛擬機(jī)，除此之外，Sun公司面對(duì)移動(dòng)和嵌入式市場(chǎng)，也發(fā)布過(guò)虛擬機(jī)產(chǎn)品，另外還有一類虛擬機(jī)，在設(shè)計(jì)之初就沒(méi)抱有商用的目的，僅僅是用于研究、驗(yàn)證某種技術(shù)和觀點(diǎn)，又或者是作為一些規(guī)范的標(biāo)準(zhǔn)實(shí)現(xiàn)。這些虛擬機(jī)對(duì)于大部分不從事相關(guān)領(lǐng)域開發(fā)的Java程序員來(lái)說(shuō)可能比較陌生。Sun公司發(fā)布的其他Java虛擬機(jī)有：

（1）KVM

KVM中的K是“Kilobyte”的意思，它強(qiáng)調(diào)簡(jiǎn)單、輕量、高度可移植，但是運(yùn)行速度比較慢。在Android、iOS等智能手機(jī)操作系統(tǒng)出現(xiàn)前曾經(jīng)在手機(jī)平臺(tái)上得到非常廣泛的應(yīng)用。

（2）CDC/CLDC HotSpot Implementation

CDC/CLDC全稱是Connected（Limited）Device Configuration，在JSR-139/JSR-218規(guī)范中進(jìn)行定義，它希望在手機(jī)、電子書、PDA等設(shè)備上建立統(tǒng)一的Java編程接口，而CDC-HI VM和CLDC-HI VM則是它們的一組參考實(shí)現(xiàn)。CDC/CLDC是整個(gè)Java ME的重要支柱，但從目前Android和iOS二分天下的移動(dòng)數(shù)字設(shè)備市場(chǎng)看來(lái)，在這個(gè)領(lǐng)域中，Sun的虛擬機(jī)所面臨的局面遠(yuǎn)不如服務(wù)器和桌面領(lǐng)域樂(lè)觀。

（3）Squawk VM

Squawk VM由Sun公司開發(fā)，運(yùn)行于Sun SPOT（Sun Small Programmable Object Technology，一種手持的WiFi設(shè)備），也曾經(jīng)運(yùn)用于Java Card。這是一個(gè)Java代碼比重很高的嵌入式虛擬機(jī)實(shí)現(xiàn)，其中諸如類加載器、字節(jié)碼驗(yàn)證器、垃圾收集器、解釋器、編譯器和線程調(diào)度都是Java語(yǔ)言本身完成的，僅僅靠C語(yǔ)言來(lái)編寫設(shè)備I/O和必要的本地代碼。

（4）JavaInJava

JavaInJava是Sun公司于1997年～1998年間研發(fā)的一個(gè)實(shí)驗(yàn)室性質(zhì)的虛擬機(jī)，從名字就可以看出，它試圖以Java語(yǔ)言來(lái)實(shí)現(xiàn)Java語(yǔ)言本身的運(yùn)行環(huán)境，既所謂的“元循環(huán)”（Meta-Circular，是指使用語(yǔ)言自身來(lái)實(shí)現(xiàn)其運(yùn)行環(huán)境）。它必須運(yùn)行在另外一個(gè)宿主虛擬機(jī)之上，內(nèi)部沒(méi)有JIT編譯器，代碼只能以解釋模式執(zhí)行。在20世紀(jì)末主流Java虛擬機(jī)都未能很好解決性能問(wèn)題的時(shí)代，開發(fā)這種項(xiàng)目，其執(zhí)行速度可想而知。

（5）Maxine VM

Maxine VM和上面的JavaInJava非常相似，它也是一個(gè)幾乎全部以Java代碼實(shí)現(xiàn)（只有用于啟動(dòng)JVM的加載器使用C語(yǔ)言編寫）的元循環(huán)Java虛擬機(jī)。這個(gè)項(xiàng)目于2005年開始，到現(xiàn)在仍然在發(fā)展之中，比起JavaInJava，Maxine VM就顯得“靠譜”很多，它有先進(jìn)的JIT編譯器和垃圾收集器（但沒(méi)有解釋器），可在宿主模式或獨(dú)立模式下執(zhí)行，其執(zhí)行效率已經(jīng)接近了HotSpot Client VM的水平。

4. BEA JRockit / IBM J9 VM

Oracle JRockit （原來(lái)的 Bea JRockit）系列產(chǎn)品是一個(gè)全面的[Java](https://baike.baidu.com/item/Java/85979)運(yùn)行時(shí)解決方案組合，包括了行業(yè)最快的標(biāo)準(zhǔn)Java解決方案。 大量的行業(yè)[基準(zhǔn)測(cè)試](https://baike.baidu.com/item/%E5%9F%BA%E5%87%86%E6%B5%8B%E8%AF%95/5876292)顯示，基本JRockit JVM是世界上最快的[JVM](https://baike.baidu.com/item/JVM/2902369)。JRockit面向延遲敏感型應(yīng)用的解決方案JRockit Real Time提供以毫秒或微秒級(jí)的JVM響應(yīng)時(shí)間，適合財(cái)務(wù)前端辦公、軍事指揮與控制和電信網(wǎng)絡(luò)的需要。使用JRockit產(chǎn)品，客戶已經(jīng)體驗(yàn)到了顯著的性能提高（一些超過(guò)了70% ）和硬件成本的減少（達(dá)50%）。

JRockit VM曾經(jīng)號(hào)稱“世界上速度最快的Java虛擬機(jī)”它是BEA公司在2002年從Appeal Virtual Machines公司收購(gòu)的虛擬機(jī)。BEA公司將其發(fā)展為一款專門為服務(wù)器硬件和服務(wù)器端應(yīng)用場(chǎng)景高度優(yōu)化的虛擬機(jī)，由于專注于服務(wù)器端應(yīng)用，它可以不太關(guān)注程序啟動(dòng)速度，因此JRockit內(nèi)部不包含解析器實(shí)現(xiàn)，全部代碼都靠即時(shí)編譯器編譯后執(zhí)行。除此之外，JRockit的垃圾收集器和MissionControl服務(wù)套件等部分的實(shí)現(xiàn)，在眾多Java虛擬機(jī)中也一直處于領(lǐng)先水平。

IBM J9 VM并不是IBM公司唯一的Java虛擬機(jī)，不過(guò)是目前其主力發(fā)展的Java虛擬機(jī)。IBM J9 VM原本是內(nèi)部開發(fā)代號(hào)，正式名稱是“IBM Technology for Java Virtual Machine”，簡(jiǎn)稱IT4J，只是這個(gè)名字太拗口了一點(diǎn)，普及程度不如J9。J9 VM最初是由IBM Ottawa實(shí)驗(yàn)室一個(gè)名為SmallTalk的虛擬機(jī)擴(kuò)展而來(lái)的，當(dāng)時(shí)這個(gè)虛擬機(jī)有一個(gè)bug是由8k值定義錯(cuò)誤引起的，工程師花了很長(zhǎng)時(shí)間終于發(fā)現(xiàn)并解決了這個(gè)錯(cuò)誤，此后這個(gè)版本的虛擬機(jī)就稱為K8了，后來(lái)擴(kuò)展出支持Java的虛擬機(jī)就被稱為J9了。與BEA JRockit專注于服務(wù)器端應(yīng)用不同，IBM J9的市場(chǎng)定位與Sun HotSpot比較接近，它是一款設(shè)計(jì)上從服務(wù)器端到桌面應(yīng)用再到嵌入式都全面考慮的多用途虛擬機(jī)，J9的開發(fā)目的是作為IBM公司各種Java產(chǎn)品的執(zhí)行平臺(tái)，它的主要市場(chǎng)是和IBM產(chǎn)品（如IBM WebSphere等）搭配以及在IBM AIX和z/OS這些平臺(tái)上部署Java應(yīng)用。

5. Azul VM / BEA Liquid VM

我們平時(shí)所提及的“高性能Java虛擬機(jī)”一般是指HotSpot、JRockit、J9這類在通用平臺(tái)上運(yùn)行的商用虛擬機(jī)，但其實(shí)Azul VM和BEA Liquid VM這類特定硬件平臺(tái)專有的虛擬機(jī)才是“高性能”的武器。

Azul VM是Azul Systems 公司在HotSpot基礎(chǔ)上進(jìn)行大量改進(jìn)，運(yùn)行于Azul Systems公司的專有硬件Vega系統(tǒng)上的Java虛擬機(jī)，每個(gè)Azul VM實(shí)例都可以管理至少數(shù)十個(gè)CPU和數(shù)百GB內(nèi)存的硬件資源，并提供在巨大內(nèi)存范圍內(nèi)實(shí)現(xiàn)可控的GC時(shí)間的垃圾收集器、為專有硬件優(yōu)化的線程調(diào)度等優(yōu)秀特性。在2010年，Azul Systems公司開始從硬件轉(zhuǎn)向軟件，發(fā)布了自己的Zing JVM，可以在通用x86平臺(tái)上提供接近于Vega系統(tǒng)的特性。

Liquid VM即是現(xiàn)在的JRockit VE（Virtual Edition），它是BEA公司開發(fā)的，可以直接運(yùn)行在自家Hypervisor系統(tǒng)上的JRockit VM的虛擬化版本，Liquid VM不需要操作系統(tǒng)的支持，或者說(shuō)它自己本身實(shí)現(xiàn)了一個(gè)專用操作系統(tǒng)的必要功能，如文件系統(tǒng)、網(wǎng)絡(luò)支持等。由虛擬機(jī)越過(guò)通用操作系統(tǒng)直接控制硬件可以獲得很多好處，如在線程調(diào)度時(shí)，不需要再進(jìn)行內(nèi)核態(tài)/用戶態(tài)的切換等，這樣可以最大限度地發(fā)揮硬件的能力，提升Java程序的執(zhí)行性能。

6. Apache Harmony / Google Android Dalvik VM

Harmony VM和Dalvik VM只能稱做“虛擬機(jī)”，而不能稱做“Java虛擬機(jī)”，但是這兩款虛擬機(jī)（以及所代表的技術(shù)體系）對(duì)最近幾年的Java世界產(chǎn)生了非常大的影響和挑戰(zhàn)，甚至有些悲觀的評(píng)論家認(rèn)為成熟的Java生態(tài)系統(tǒng)有崩潰的可能。

Apache Harmony是一個(gè)Apache軟件基金會(huì)旗下以Apache License協(xié)議開源的實(shí)際兼容于JDK 1.5和JDK 1.6的Java程序運(yùn)行平臺(tái)，這個(gè)介紹相當(dāng)拗口。它包含自己的虛擬機(jī)和Java庫(kù)，用戶可以在上面運(yùn)行Eclipse、Tomcat、Maven等常見的Java程序，但是它沒(méi)有通過(guò)TCK認(rèn)證，所以我們不得不用那么一長(zhǎng)串拗口的語(yǔ)言來(lái)介紹它，而不能用一句“Apache的JDK”來(lái)說(shuō)明。如果一個(gè)公司要宣布自己的運(yùn)行平臺(tái)“兼容于Java語(yǔ)言”，那就必須要通過(guò)TCK（Technology Compatibility Kit）的兼容性測(cè)試。Apache基金會(huì)曾要求Sun公司提供TCK的使用授權(quán)，但是一直遭到拒絕，直到Oracle公司收購(gòu)了Sun公司之后，雙方關(guān)系越鬧越僵，最終導(dǎo)致Apache憤然退出JCP（Java Community Process）組織，這是目前為止Java社區(qū)最嚴(yán)重的一次“分裂”。

在Sun將JDK開源形成OpenJDK之后，Apache Harmony開源的優(yōu)勢(shì)被極大地削弱，甚至連Harmony項(xiàng)目的最大參與者IBM公司也宣布辭去Harmony項(xiàng)目管理主席的職位，并參與OpenJDK項(xiàng)目的開發(fā)。雖然Harmony沒(méi)有經(jīng)過(guò)真正大規(guī)模的商業(yè)運(yùn)用，但是它的許多代碼（基本上是Java庫(kù)部分的代碼）被吸納進(jìn)IBM的JDK 7實(shí)現(xiàn)及Google Android SDK之中，尤其是對(duì)Android的發(fā)展起到了很大的推動(dòng)作用。

說(shuō)到Android，這個(gè)時(shí)下最熱門的移動(dòng)數(shù)碼設(shè)備平臺(tái)在最近幾年間的發(fā)展過(guò)程中所取得的成果已經(jīng)遠(yuǎn)遠(yuǎn)超越了Java ME在過(guò)去十多年所獲得的成果，Android讓Java語(yǔ)言真正走進(jìn)了移動(dòng)數(shù)碼設(shè)備領(lǐng)域，只是走的并非Sun公司原本想象的那一條路。

Dalvik VM是Android平臺(tái)的核心組成部分之一，它的名字來(lái)源于冰島一個(gè)名為Dalvik的小漁村。Dalvik VM并不是一個(gè)Java虛擬機(jī)，它沒(méi)有遵循Java虛擬機(jī)規(guī)范，不能直接執(zhí)行Java的Class文件，使用的是寄存器架構(gòu)而不是JVM中常見的棧架構(gòu)。但是它與Java又有著千絲萬(wàn)縷的聯(lián)系，它執(zhí)行的dex（Dalvik Executable）文件可以通過(guò)Class文件轉(zhuǎn)化而來(lái)，使用Java語(yǔ)法編寫應(yīng)用程序，可以直接使用大部分的Java API等。目前Dalvik VM隨著Android一起處于迅猛發(fā)展階段，在Android 2.2中已提供即時(shí)編譯器實(shí)現(xiàn)，在執(zhí)行性能上有了很大的提高。

7. Microsoft JVM及其他

在十幾年的Java虛擬機(jī)發(fā)展過(guò)程中，除去上面介紹的那些被大規(guī)模商業(yè)應(yīng)用過(guò)的Java虛擬機(jī)外，還有許多虛擬機(jī)是不為人知的或者曾經(jīng)“絢麗”過(guò)但最終湮滅的。我們以其中微軟公司的JVM為例來(lái)介紹一下。

也許Java程序員聽起來(lái)可能會(huì)覺得驚訝，微軟公司曾經(jīng)是Java技術(shù)的鐵桿支持者（也必須承認(rèn)，與Sun公司爭(zhēng)奪Java的控制權(quán)，令Java從跨平臺(tái)技術(shù)變?yōu)榻壎ㄔ赪indows上的技術(shù)是微軟公司的主要目的）。在Java語(yǔ)言誕生的初期（1996年～1998年，以JDK 1.2發(fā)布為分界），它的主要應(yīng)用之一是在瀏覽器中運(yùn)行Java Applets程序，微軟公司為了在IE3中支持Java Applets應(yīng)用而開發(fā)了自己的Java虛擬機(jī)，雖然這款虛擬機(jī)只有Windows平臺(tái)的版本，卻是當(dāng)時(shí)Windows下性能最好的Java虛擬機(jī)，它在1997年和1998年連續(xù)兩年獲得了《PC Magazine》雜志的“編輯選擇獎(jiǎng)”。但好景不長(zhǎng)，在1997年10月，Sun公司正式以侵犯商標(biāo)、不正當(dāng)競(jìng)爭(zhēng)等罪名控告微軟公司，在隨后對(duì)微軟公司的壟斷調(diào)查之中，這款虛擬機(jī)也曾作為證據(jù)之一被呈送法庭。這場(chǎng)官司的結(jié)果是微軟公司賠償2000萬(wàn)美金給Sun公司（最終微軟公司因壟斷賠償給Sun公司的總金額高達(dá)10億美元），承諾終止其Java虛擬機(jī)的發(fā)展，并逐步在產(chǎn)品中移除Java虛擬機(jī)相關(guān)功能。具有諷刺意味的是，到最后在Windows XP SP3中Java虛擬機(jī)被完全抹去的時(shí)候，Sun公司卻又到處登報(bào)希望微軟公司不要這樣做。Windows XP高級(jí)產(chǎn)品經(jīng)理Jim Cullinan稱：“我們花費(fèi)了3年的時(shí)間和Sun打官司，當(dāng)時(shí)他們?cè)噲D阻止我們?cè)赪indows中支持Java，現(xiàn)在我們這樣做了，可他們又在抱怨，這太具有諷刺意味了?！?/p>

我們?cè)囅胍幌?，如果?dāng)年Sun公司沒(méi)有起訴微軟公司，微軟公司繼續(xù)保持著對(duì)Java技術(shù)的熱情，那Java的世界會(huì)變得怎么樣呢？.NET技術(shù)是否會(huì)發(fā)展起來(lái)？但歷史是沒(méi)有假設(shè)的。

五、JVM相關(guān)問(wèn)題

問(wèn)：堆和棧有什么區(qū)別

答：堆是存放對(duì)象的，但是對(duì)象內(nèi)的臨時(shí)變量是存在棧內(nèi)存中，如例子中的methodVar是在運(yùn)行期存放到棧中的。

棧是跟隨線程的，有線程就有棧，堆是跟隨JVM的，有JVM就有堆內(nèi)存。

問(wèn)：堆內(nèi)存中到底存在著什么東西？

答：對(duì)象，包括對(duì)象變量以及對(duì)象方法。

問(wèn)：類變量和實(shí)例變量有什么區(qū)別？

答：靜態(tài)變量是類變量，非靜態(tài)變量是實(shí)例變量，直白的說(shuō)，有static修飾的變量是靜態(tài)變量，沒(méi)有static修飾的變量是實(shí)例變量。靜態(tài)變量存在方法區(qū)中，實(shí)例變量存在堆內(nèi)存中。

問(wèn)：我聽說(shuō)類變量是在JVM啟動(dòng)時(shí)就初始化好的，和你這說(shuō)的不同呀！

答：那你是道聽途說(shuō)，信我的，沒(méi)錯(cuò)。

問(wèn)：Java的方法（函數(shù)）到底是傳值還是傳址？

答：都不是，是以傳值的方式傳遞地址，具體的說(shuō)原生數(shù)據(jù)類型傳遞的值，引用類型傳遞的地址。對(duì)于原始數(shù)據(jù)類型，JVM的處理方法是從Method Area或Heap中拷貝到Stack，然后運(yùn)行frame中的方法，運(yùn)行完畢后再把變量指拷貝回去。

問(wèn)：為什么會(huì)產(chǎn)生OutOfMemory產(chǎn)生？

答：一句話：Heap內(nèi)存中沒(méi)有足夠的可用內(nèi)存了。這句話要好好理解，不是說(shuō)Heap沒(méi)有內(nèi)存了，是說(shuō)新申請(qǐng)內(nèi)存的對(duì)象大于Heap空閑內(nèi)存，比如現(xiàn)在Heap還空閑1M，但是新申請(qǐng)的內(nèi)存需要1.1M，于是就會(huì)報(bào)OutOfMemory了，可能以后的對(duì)象申請(qǐng)的內(nèi)存都只要0.9M，于是就只出現(xiàn)一次OutOfMemory，GC也正常了，看起來(lái)像偶發(fā)事件，就是這么回事。 但如果此時(shí)GC沒(méi)有回收就會(huì)產(chǎn)生掛起情況，系統(tǒng)不響應(yīng)了。

問(wèn)：我產(chǎn)生的對(duì)象不多呀，為什么還會(huì)產(chǎn)生OutOfMemory？

答：你繼承層次忒多了，Heap中 產(chǎn)生的對(duì)象是先產(chǎn)生 父類，然后才產(chǎn)生子類，明白不？

問(wèn)：OutOfMemory錯(cuò)誤分幾種？

答：分兩種，分別是“OutOfMemoryError:java heap size”和”O(jiān)utOfMemoryError: PermGen space”，兩種都是內(nèi)存溢出，heap size是說(shuō)申請(qǐng)不到新的內(nèi)存了，這個(gè)很常見，檢查應(yīng)用或調(diào)整堆內(nèi)存大小。

“PermGen space”是因?yàn)橛谰么鎯?chǔ)區(qū)滿了，這個(gè)也很常見，一般在熱發(fā)布的環(huán)境中出現(xiàn)，是因?yàn)槊看伟l(fā)布應(yīng)用系統(tǒng)都不重啟，久而久之永久存儲(chǔ)區(qū)中的死對(duì)象太多導(dǎo)致新對(duì)象無(wú)法申請(qǐng)內(nèi)存，一般重新啟動(dòng)一下即可。

問(wèn)：為什么會(huì)產(chǎn)生StackOverflowError？

答：因?yàn)橐粋€(gè)線程把Stack內(nèi)存全部耗盡了，一般是遞歸函數(shù)造成的。

問(wèn)：一個(gè)機(jī)器上可以看多個(gè)JVM嗎？JVM之間可以互訪嗎？

答：可以多個(gè)JVM，只要機(jī)器承受得了。JVM之間是不可以互訪，你不能在A-JVM中訪問(wèn)B-JVM的Heap內(nèi)存，這是不可能的。在以前老版本的JVM中，會(huì)出現(xiàn)A-JVM Crack后影響到B-JVM，現(xiàn)在版本非常少見。

問(wèn)：為什么Java要采用垃圾回收機(jī)制，而不采用C/C++的顯式內(nèi)存管理？

答：為了簡(jiǎn)單，內(nèi)存管理不是每個(gè)程序員都能折騰好的。

問(wèn)：為什么你沒(méi)有詳細(xì)介紹垃圾回收機(jī)制？

答：垃圾回收機(jī)制每個(gè)JVM都不同，JVM Specification只是定義了要自動(dòng)釋放內(nèi)存，也就是說(shuō)它只定義了垃圾回收的抽象方法，具體怎么實(shí)現(xiàn)各個(gè)廠商都不同，算法各異，這東西實(shí)在沒(méi)必要深入。

問(wèn)：JVM中到底哪些區(qū)域是共享的？哪些是私有的？

答：Heap和Method Area是共享的，其他都是私有的

問(wèn)：什么是JIT，你怎么沒(méi)說(shuō)？

答：JIT是指Just In Time，有的文檔把JIT作為JVM的一個(gè)部件來(lái)介紹，有的是作為執(zhí)行引擎的一部分來(lái)介紹，這都能理解。Java剛誕生的時(shí)候是一個(gè)解釋性語(yǔ)言，別噓，即使編譯成了字節(jié)碼（byte code）也是針對(duì)JVM的，它需要再次翻譯成原生代碼(native code)才能被機(jī)器執(zhí)行，于是效率的擔(dān)憂就提出來(lái)了。Sun為了解決該問(wèn)題提出了一套新的機(jī)制，好，你想編譯成原生代碼，沒(méi)問(wèn)題，我在JVM上提供一個(gè)工具，把字節(jié)碼編譯成原生碼，下次你來(lái)訪問(wèn)的時(shí)候直接訪問(wèn)原生碼就成了，于是JIT就誕生了，就這么回事。

問(wèn)：JVM還有哪些部分是你沒(méi)有提到的？

答：JVM是一個(gè)異常復(fù)雜的東西，寫一本磚頭書都不為過(guò)，還有幾個(gè)要說(shuō)明的：

問(wèn)：為什么不建議在程序中顯式的生命System.gc()？

答：因?yàn)轱@式聲明是做堆內(nèi)存全掃描，也就是Full GC，是需要停止所有的活動(dòng)的（Stop The World Collection），你的應(yīng)用能承受這個(gè)嗎？

問(wèn)：JVM有哪些調(diào)整參數(shù)？

答：非常多，堆內(nèi)存、棧內(nèi)存的大小都可以定義，甚至是堆內(nèi)存的三個(gè)部分、新生代的各個(gè)比例都能調(diào)整。

六、Jvm調(diào)優(yōu)與性能優(yōu)化

在互聯(lián)網(wǎng)公司面試中，架構(gòu)的底層一定是面試官會(huì)問(wèn)到的問(wèn)題，針對(duì)面試官一般會(huì)提到的問(wèn)題，我錄制了一些底層原理的錄像視頻，加群 69-757-975-1可以免費(fèi)獲取這些錄像，里面有些分布式，微服務(wù)，性能優(yōu)化，Spring，MyBatis的等源碼知識(shí)點(diǎn)的錄像視頻。上圖的性能優(yōu)化只是其中的一小部分，這些視頻都是我找一些資深架構(gòu)師朋友一起錄制出來(lái)的，視頻希望能夠幫助到以下幾類程序員：

1.對(duì)現(xiàn)在的薪資不滿，想要跳槽，卻對(duì)自己的技術(shù)沒(méi)有信心，不知道如何面對(duì)面試官。

2.想從傳統(tǒng)行業(yè)轉(zhuǎn)行到互聯(lián)網(wǎng)行業(yè)，但沒(méi)有接觸過(guò)互聯(lián)網(wǎng)技術(shù)。

3.工作1 - 5年需要提升自己的核心競(jìng)爭(zhēng)力，但學(xué)習(xí)沒(méi)有系統(tǒng)化，不知道自己接下來(lái)要學(xué)什么才是正確的，踩坑后又不知道找誰(shuí)，百度后依然不知所以然。

4.工作5 - 10年無(wú)法突破技術(shù)瓶頸（運(yùn)用過(guò)很多技術(shù)，在公司一直寫著業(yè)務(wù)代碼，卻依然不懂底層實(shí)現(xiàn)原理）

如果你現(xiàn)在正處于我上述所說(shuō)的幾個(gè)階段可以加下我的群來(lái)學(xué)習(xí)。而且我也能夠提供一些面試指導(dǎo)，職業(yè)規(guī)劃等建議。