JVM結構基礎(一)

2019-11-18 14:06:29

字體：大中小

來源：轉載

供稿：網友

　　JVM結構基礎

前段時間由于研究原來廣為傳播的String和StringBuffer的性能問題，自己做了幾個小實驗并得出一些結論，但是從網友的反應來看那個研究并沒有起到應有的目的，而且網友也很中肯的提出了自己的意見并對實驗中的一些內容指出了其缺陷，針對他們的反應我又反編譯了代碼來進行對比，但是幾位網友仍然不是很信服，而且上次實驗的結果和反編譯得到的結論并不能完全吻合，因為反編譯代碼的對比基本上是基于語句的多少，因此這個這個對比也確實不能使人信服，但是這給我的下一步行動指引了方向：研究JVM指令和JVM結構，在對反編譯后的代碼有完全的理解才能給出可能使人信服的結論。

本文以及以后將要寫的一些文章就是我研究JVM規范的一些心得，我希望在和大家共同理解的基礎上進行我們下一輪的深入研究。

好，閑話少說，開始我們的正文。

JVM執行的對象就是大家非常熟悉的class文件，我們也稱為類文件，JVM規范定義的這個編譯完成的代碼文件(雖然并非強制要求是實際的文件)的格式非常的詳實，但是我們這里只說一些宏觀的內容，以后有機會再研究細節的內容吧。JVM要求的類文件的格式是和硬件和操作系統無關的一種二進制格式，它精確定義了類或者接口的表示，它甚至包含了字節順序這樣的細節，而字節順序在特定平臺的目標文件格式中一般都是固定的，不會進行說明。

JVM所支持的數據類型和java語言規范中定義的幾乎一樣，請注重是幾乎一樣！也就是原始類型和引用類型，他們可以被存儲在變量表中，也可以作為參數傳遞、被方法返回，更通常的就是成為操作的對象。為什么和Java語言規范中定義的不完全一樣呢？因為JVM中有一種Java語言所沒有的原始類型：返回地址類型(returnAddress type)。該類型是jsr, ret以及jsr_w指令需要使用到的，它的值是JVM指令的操作碼的指針，并且它的值是不能被運行中的程序所修改的。

另外需要提到的就是布爾類型的值，雖然在Java語言中它是完全獨立的值，但是在JVM中只提供了對它的有限支持，表現在：
沒有單獨的操作布爾類型的指令，源代碼中的布爾類型的操作在編譯以后是作為int類型的值進行操作的。
JVM直接支持布爾數組，newarray指令可以創建布爾數組，而它的訪問和修改操作卻是使用byte類型的數組的操作指令進行的：baload,bastore。(在JDK1.0，1,1以及1.2中，布爾數組被編碼為byte數組，每個元素是8位)
JVM用1代表true，用0代表false，編譯器將源代碼中的布爾類型映射為JVM中的int類型，而且必須和JVM的要求一致。

另外JVM規范中對于浮點類型的數據有大段的說明，我沒有怎么看，主要是討論JVM的浮點型和IEEE 754的關系的。

關于類型的另外一個需要提一下的是類型檢查。JVM期望幾乎所有的類型檢查已經在運行之前完成了(通常是由編譯器進行檢查的)而不用JVM自己來檢查。原始類型的值不需要被標記或者在運行時被檢查以確定他們的類型，同樣他們也不用和引用類型的值進行區分，區分工作是由JVM的指令集來完成的，JVM的指令集使用不同指令來區分它要操作的值的類型，例如iadd, ladd, fadd以及dadd是用于將兩個數字相加并產生數字類型結果的所有JVM指令，但是每個指令都是針對特定類型的，分別對應int, long, float以及double。

JVM包含對對象的顯式支持。類是動態分配的類實例或者是一個數組，JVM中的引用類型就是對一個對象的引用，引用類型的值可以想象為對象的指針，一個對象同時可能存在多個對它的引用，對象總是通過引用被操作、傳遞或者測試的。

對于引用類型，需要提及的一點就是關于null，它最初是沒有運行時類型的，但是它可以被轉換為任何類型，而且對于null，JVM并沒有要求任何具體的值與之對應。

說完上面這些，我們就開始進入我學習JVM時最想了解的部分了，大家可要打起精神哦。
JVM為運行一個程序定義了幾種數據區(Data Area)，包括：pc寄存器、JVM堆棧、堆、方法區(Method Area)、運行時常量池(Runtime Constant Pool)以及本機方法堆棧(Native Method Stacks)，這些數據區根據其生存期可以分為兩種，一種就是和JVM的生存期相同(包括堆和方法區)，一種和線程的生存期相同(其它的)，和JVM生存期相同的數據區在JVM啟動的時候被創建并在JVM退出的時候被銷毀，而和線程生存期相同的數據區是每個線程一個的，他們在線程創建的時候被創建，在線程被銷毀的時候被銷毀。

由于JVM可以同時支持運行多個線程，因此每個線程必然需要各自的PC(PRogram counter)寄存器，無論從什么角度講，每個JVM線程只能在一個時間只能執行一個方法，該方法也就是線程的當前方法，假如該方法不是本機方法，那么PC寄存器保存的就是當前指令(JVM的指令)的地址，假如是當前方法是本機方法，PC寄存器的值就沒有被定義。JVM的PC寄存器的大小足夠大，可以容納一個returnAddress類型或者特定平臺的本機指針。

每個JVM線程還擁有一個私有的JVM堆棧，它存儲幀(下一篇文章會講到)。JVM堆棧和像C這樣的傳統編程語言中的堆棧是類似的，它保存局部變量和部分結果，并且在方法調用和返回中也擔任一些職責。因為除了對幀的壓入和彈出操作外，對JVM堆棧不能直接進行操作，因此幀可能是在堆上分配的。假如一個線程中計算所需的JVM堆棧大于答應的大小，JVM會拋出StackOverflowError錯誤，假如JVM堆棧是可以動態伸縮的，假如需要擴展，但是又沒有足夠的內存可用或者沒有足夠的內存為一個新線程創建JVM堆棧，JVM會拋出OutOfMemoryError錯誤。

JVM只有一個為所有線程所共享的堆，所有的類實例和數組都是在堆中創建的。堆所存儲的對象被一個自動存儲治理系統回收(也就是我們所熟知的垃圾收集器(gc))。對象不能被顯式的釋放，JVM假設沒有特定類型的自動存儲治理系統，存儲治理技術可以根據實現者的系統需求進行選擇。假如計算所需的內存堆大于自動存儲治理系統可以使用的大小，JVM會拋出OutOfMemoryError錯誤。

JVM只有一個為所有的線程所共享的方法區，方法區類似傳統語言的已編譯代碼的存儲區或者UNIX進程的“文本”段。它存儲類結構，例如運行時常量池，成員和方法數據以及方法、構造方法的代碼(包括用于類和實例的初始化以及接口類型初始化的特定方法(這些特定方法以后會講到))。雖然從邏輯上講方法區是堆的一部分，但是JVM的簡單實現可以選擇不對方法區進行垃圾收集或者壓縮(以筆者的理解就是類不能進行卸載)。最新版本(第二版)的JVM規范沒有要求方法區的位置或者治理已編譯代碼的策略。假如方法區的內存不能滿足一個分配請求，JVM會拋出OutOfMemoryError。

運行時常量池是類文件中的常量池表的運行時表示,它包含幾種常量，范圍從編譯時就已知的數字常量到運行時必須進行解析的方法和成員引用。運行時常量池扮演的功能類似于傳統編程語言中的符號表(symbol table)，但是它所包含的數據比典型的符號表更多。
每個運行時常量池時從JVM的方法區中分配的，對于特定方法或者接口的運行時常量池是JVM在創建類或者接口的時候創建的。
當創建一個類或者接口時，假如創建運行時常量池需要的內存比方法區中的可用內容更多的內存，JVM會拋出OutOfMemoryError。
關于常量池創建的更多內容以后可能會更具體的講解。

JVM的實現可能使用傳統的堆棧(更通常的講就是C棧)以支持本機方法(不是使用JAVA語言編寫的方法)，本機方法堆棧也可以用于在像C語言這樣的語言中為JVM指令集實現解析器，對于不能加載本機方法以及自身不依靠傳統堆棧的JVM實現而言，它可以不提供本機方法堆棧，假如提供，本機方法堆棧通常在線程創建的時候為每個線程分配(以筆者的理解應該是需要使用本機方法的線程)。假如線程計算所需的內存比本機方法堆棧所答應的大，JVM會拋出StackOverflowError錯誤，假如本機方法堆棧可以動態伸縮，而當需要擴展的時候又沒有足夠的內存時，或者沒有足夠的內容用于創建一個本機方法堆棧，JVM會拋出OutOfMemoryError。

對于上面的這些數據區，JVM規范答應它們的大小是固定尺寸的，也可以是根據計算的需要動態伸縮的，假如是固定尺寸的，其尺寸可以在創建時自主選擇。JVM的實現可以給程序員或者用戶提供控制JVM堆棧的初始大小的方法，同樣，在動態伸縮的情況下可以控制最大大小和最小大小，并且它們所使用的內存空間可以不是連續的。

上一篇：把對象作為參數

下一篇：JXTA概念介紹