什么是jvm？

jvm(java virtual machine)是一個(gè)抽象的計(jì)算機(jī)，和實(shí)際的計(jì)算機(jī)一樣，它具有指令集并使用不同的存儲(chǔ)區(qū)域，它負(fù)責(zé)執(zhí)行指令，還要管理數(shù)據(jù)、內(nèi)存和寄存器。

看到這里，可能不懂jvm的人，已經(jīng)蒙圈了。沒關(guān)系，下面讓我詳細(xì)為大家介紹jvm的體系架構(gòu)圖，或許你會(huì)明白些。

簡(jiǎn)單來說，jvm就是一個(gè)虛擬計(jì)算機(jī)。我們都知道java語言其中的一個(gè)特性就是跨平臺(tái)的，而jvm就是java程序?qū)崿F(xiàn)跨平臺(tái)的關(guān)鍵部分。java編譯器編譯java程序時(shí)，生成的是與平臺(tái)無關(guān)的字節(jié)碼（也就是.class文件），所謂的平臺(tái)無關(guān)是指編譯生成的字節(jié)碼無論是在window、linux、mac系統(tǒng)都是可執(zhí)行。也就是說java編譯生成的.class文件不是面向平臺(tái)的，而是面向jvm的。不同平臺(tái)上的jvm都是不同的，但是他們都是提供了相同的接口。圖一為java的大致運(yùn)行步驟：

引用一個(gè)《瘋狂java講義》中提到例子來幫助大家理解jvm的作用：

jvm的作用就像有兩只不同的鉛筆，但需要把同一個(gè)筆帽套在兩支不同的筆上，只有為這兩支筆分別提供一個(gè)轉(zhuǎn)換器，這個(gè)轉(zhuǎn)換器向上的接口相同，用于適應(yīng)同一個(gè)筆帽；向下的接口不同，用于適應(yīng)兩支不同的筆。在這個(gè)類比中，可以近似地理解兩支不同的筆就是不同的操作系統(tǒng)，而同一個(gè)筆帽就是java字節(jié)碼程序，轉(zhuǎn)換器角色則對(duì)應(yīng)jvm。類似地，也可以認(rèn)為jvm分為向上和向下兩個(gè)部分，所有平臺(tái)的jvm向上提供給java字節(jié)碼程序的接口完全相同，但向下適應(yīng)的不同平臺(tái)的接口則互不相同。

jvm體系結(jié)構(gòu)概覽

上面我們是初步介紹了jvm的作用，那么要深入去了解jvm我們就需要了解jvm的體系結(jié)構(gòu)，請(qǐng)看圖二：

圖二是jvm的體系架構(gòu)圖，接下讓我們一起來聊一聊每一個(gè)部分都是什么意思。

1.類裝載器子系統(tǒng)（classloader）

負(fù)責(zé)加載class文件，class文件在文件開頭有特定的文件標(biāo)示，將class文件字節(jié)碼內(nèi)容加載到內(nèi)存中，并將這些內(nèi)容轉(zhuǎn)換成方法區(qū)中的運(yùn)行時(shí)數(shù)據(jù)結(jié)構(gòu)并且classloader只負(fù)責(zé)class文件的加載，至于它是否可以運(yùn)行，則由execution engine決定。

java編譯生成的*.class文件就是通過classloader進(jìn)行加載的，那么這里就會(huì)有幾個(gè)問題：

classloader如何知道*.class文件就是需要加載的文件？
如果我手動(dòng)將一個(gè)普通文件的擴(kuò)展名稱改為class后綴，classloader會(huì)加載這個(gè)文件嗎？
實(shí)際上，class文件在文件的開頭是有特定的文件標(biāo)識(shí)的，隨便編寫一個(gè)java程序，編譯生成一個(gè)class文件，打開后你都能看到如下內(nèi)容：

cafe babe就是class文件的一個(gè)標(biāo)識(shí)，classloader負(fù)責(zé)加載有cafe babe的class文件，它將class文件字節(jié)碼內(nèi)容加載到內(nèi)存中，并將這些內(nèi)容轉(zhuǎn)換成方法區(qū)中的運(yùn)行時(shí)的數(shù)據(jù)結(jié)構(gòu)并且classloader只負(fù)責(zé)class文件的加載，至于它是否可以運(yùn)行，則由execution engine決定，請(qǐng)看圖三：

car.class文件通過classloader進(jìn)行加載到內(nèi)存中，car class在內(nèi)存中就相當(dāng)一個(gè)模板，我們可以通過這個(gè)模板可以實(shí)例化成不同的實(shí)例car1、car2、car3。

不知大家會(huì)不會(huì)有一個(gè)疑問，classloader加載car.class在java中是用什么類型的加載器加載的呢？在解答這個(gè)問題前我們先寫個(gè)簡(jiǎn)單的代碼看看：

結(jié)果為：
我們?cè)賮砜纯戳硗庖唤M代碼：

結(jié)果為：

從上面我們可以知道，classloader的打印結(jié)果一個(gè)是“sun.misc.launcher$appclassloader@18b4aac2”，一個(gè)則是“null”，這是怎么回事呢，細(xì)心的朋友就可以發(fā)現(xiàn)這兩個(gè)不同的對(duì)象中，其中car對(duì)象是我們自己寫的一個(gè)類，string對(duì)象是系統(tǒng)自帶的一個(gè)類。簡(jiǎn)單來說就是classloader會(huì)根據(jù)不同的類選擇不同的類加載器去進(jìn)行加載。這里就牽扯到了classloader的分類

classloader的類別：

啟動(dòng)類加載器(bootstrap)
擴(kuò)展類加載器(extension)
應(yīng)用程序類加載器(appclassloader)
用戶自定義加載器
一般我們自己所寫的類用的類加載器都是appclassloader，就是上圖所示的“sun.misc.launcher$appclassloader@18b4aac2”，而為什么string這個(gè)對(duì)象是”null“呢？實(shí)際上，這個(gè)“null”指的就是使用bootstrap這個(gè)加載器。

那可能有人有疑問，自己定義的類用appclassloader，能理解，因?yàn)閏ar這個(gè)對(duì)象輸出的類加載器名字中有appclassloader這個(gè)字樣，但是為什么string這個(gè)對(duì)象是”null“，從哪里可用體現(xiàn)是用bootstrap這個(gè)加載器呢？是這樣的，bootstrap累加載器相當(dāng)于擴(kuò)展類加載器、應(yīng)用程序類加載器的祖宗，若是用了bootstrap，由于bootstrap上一級(jí)已經(jīng)沒有了，所以就用“null”來表示

其實(shí)我們可以找一下string這個(gè)類在jdk的位置：

所有在這個(gè)路徑$java_home/jre/lib/rt.jar這個(gè)jar包下的類都是用bootstrap來加載的。

下面請(qǐng)看圖4：

這張圖就可以很清晰得看到：

1.所有在$java_home/jre/lib/rt.jar是通過bootstrap加載的

2.所有在$java_home/jre/lib/ext/*.jar是通過extension加載的

3.所有在$classpath是通過system加載的（應(yīng)用程序類加載器也叫系統(tǒng)類加載器，加載當(dāng)前應(yīng)用的classpath的所有類）

接下來我們?cè)賮砜匆粋€(gè)例子：

如果創(chuàng)建一個(gè)java.lang包，然后創(chuàng)建string類，打印一句話執(zhí)行會(huì)怎么樣呢？

效果如下：

可以看到程序報(bào)錯(cuò)了，說是找不到main方法，可是明明就有main方法為什么沒有執(zhí)行呢？這里就涉及了雙親委派機(jī)制

雙親委派機(jī)制：

當(dāng)一個(gè)類收到了類加載請(qǐng)求，他首先不會(huì)嘗試自己去加載這個(gè)類，而是把這個(gè)請(qǐng)求委派給父類去完成，每一個(gè)層次類加載器都是如此，因此所有的加載請(qǐng)求都應(yīng)該傳送到啟動(dòng)類加載器中，只有當(dāng)父類加載器反饋?zhàn)约簾o法完成這個(gè)請(qǐng)求的時(shí)候（在它的加載路徑下沒有找到所需加載的class），子類加載器才會(huì)嘗試自己去加載。

所以它實(shí)際的運(yùn)行過程是這樣的：

classloader收到string類的加載請(qǐng)求。
先去bootstrap查找是否有這個(gè)類，沒有則反饋無法完成這個(gè)請(qǐng)求，但是恰好，在rt.jar中找到了java.lang.stirng這個(gè)類
執(zhí)行這個(gè)類，這個(gè)類是沒有定義main方法的
報(bào)錯(cuò)，類中沒有定義main方法
所以上面的例子，他會(huì)找到j(luò)dk中java.lang.string這個(gè)類，這個(gè)類確實(shí)是沒有定義main方法，簡(jiǎn)單來說它執(zhí)行的類是jdk中java.lang.string這個(gè)類，而不是我們自己定義的類。

那用雙親委派機(jī)制有什么好處呢：

采用雙親委派的一個(gè)好處是比如加載位于 rt.jar 包中的類 java.lang.object，不管是哪個(gè)加載器加載這個(gè)類，最終都是委托給頂層的啟動(dòng)類加載器進(jìn)行加載，這樣就保證了使用不同的類加載器最終得到的都是同樣一個(gè) object對(duì)象。

2.執(zhí)行引擎(execution engine)

執(zhí)行引擎負(fù)責(zé)解釋命令，提交給操作系統(tǒng)執(zhí)行，這里對(duì)執(zhí)行引擎就不做過多的解釋了，只要知道他是負(fù)責(zé)解釋命令的即可。

3.本地方法接口(native interface)和本地方法棧(native method stack)

本地接口:本地接口的作用是融合不同的編程語言為 java 所用，它的初衷是融合 c/c++程序，java 誕生的時(shí)候是 c/c++橫行的時(shí)候，要想立足，必須有調(diào)用 c/c++程序，于是就在內(nèi)存中專門開辟了一塊區(qū)域處理標(biāo)記為native的代碼，它的具體做法是 native method stack中登記 native方法，在execution engine 執(zhí)行時(shí)加載native libraies。
目前該方法使用的越來越少了，除非是與硬件有關(guān)的應(yīng)用，比如通過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等等，不多做介紹。

如果在程序中有見到native關(guān)鍵字，就代表不是java能完成的事情了，需要加載本地方法庫才能完成

本地方法棧：它的具體做法是native method stack中登記native方法，在execution engine 執(zhí)行時(shí)加載本地方法庫。說白了就是本地方法由本地方法棧來登記，java中的方法由java棧來登記。

4.pc寄存器(program counter register)

每個(gè)線程都有一個(gè)程序計(jì)數(shù)器，是線程私有的,就是一個(gè)指針，指向方法區(qū)中的方法字節(jié)碼（用來存儲(chǔ)指向下一條指令的地址,也即將要執(zhí)行的指令代碼），由執(zhí)行引擎讀取下一條指令，是一個(gè)非常小的內(nèi)存空間，幾乎可以忽略不記。
這塊內(nèi)存區(qū)域很小，它是當(dāng)前線程所執(zhí)行的字節(jié)碼的行號(hào)指示器，字節(jié)碼解釋器通過改變這個(gè)計(jì)數(shù)器的值來選取下一條需要執(zhí)行的字節(jié)碼指令。
如果執(zhí)行的是一個(gè)native方法，那這個(gè)計(jì)數(shù)器是空的。
pc寄存器用來完成分支、循環(huán)、跳轉(zhuǎn)、異常處理、線程恢復(fù)等基礎(chǔ)功能。由于使用的內(nèi)存較小，所以不會(huì)發(fā)生內(nèi)存溢出(outofmemory)錯(cuò)誤。

到此這篇關(guān)于初步認(rèn)識(shí)jvm的體系結(jié)構(gòu)的文章就介紹到這了,更多相關(guān)jvm的體系結(jié)構(gòu)內(nèi)容請(qǐng)搜索服務(wù)器之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持服務(wù)器之家！

原文鏈接：https://blog.csdn.net/weixin_57485542/article/details/117892749