JVM重要知識點整理和學習

JVM是虛擬機器，也是一種規範，他遵循著馮·諾依曼體系結構的設計原理。馮·諾依曼體系結構中，指出計算機處理的資料和指令都是二進位制數，採用儲存程式方式不加區分的儲存在同一個儲存器裡，並且順序執行，指令由操作碼和地址碼組成，操作碼決定了操作型別和所操作的數的數字型別，地址碼則指出地址碼和運算元。從dos到window8，從unix到ubuntu和CentOS，還有MAC OS等等，不同的作業系統指令集以及資料結構都有著差異，而JVM通過在作業系統上建立虛擬機器，自己定義出來的一套統一的資料結構和操作指令，把同一套語言翻譯給各大主流的作業系統，實現了跨平臺執行，可以說JVM是java的核心，是java可以一次編譯到處執行的本質所在。

我研究學習了JVM的組成和執行原理，JVM的統一資料格式規範、位元組碼檔案結構，JVM關於記憶體的管理。

一、JVM的組成和執行原理

JVM的畢竟是個虛擬機器，是一種規範，雖說符合馮諾依曼的計算機設計理念，但是他並不是實體計算機，所以他的組成也不是什麼儲存器，控制器，運算器，輸入輸出裝置。在我看來，JVM放在執行在真實的作業系統中表現的更像應用或者說是程式，他的組成可以理解為JVM這個程式有哪些功能模組，而這些功能模組的運作可以看做是JVM的執行原理。JVM有多種實現，例如Oracle的JVM，HP的JVM和IBM的JVM等，而在本文中研究學習的則是使用最廣泛的Oracle的HotSpot JVM。

 1.JVM在JDK中的位置。

JDK是java開發的必備工具箱，JDK其中有一部分是JRE，JRE是JAVA執行環境，JVM則是JRE最核心的部分。我從oracle.com擷取了一張關於JDK Standard Edtion的組成圖，

從最底層的位置可以看出來JVM有多重要，而實際專案中JAVA應用的效能優化，OOM等異常的處理最終都得從JVM這兒來解決。HotSpot是Oracle關於JVM的商標，區別於IBM，HP等廠商開發的JVM。Java HotSpot Client VM和Java HotSpot Server VM是JDK關於JVM的兩種不同的實現，前者可以減少啟動時間和記憶體佔用，而後者則提供更加優秀的程式執行速度（參考自：http://docs.oracle.com/javase/8/docs/technotes/guides/vm/index.html ，該文件有關於各個版本的JVM的介紹）。在命令列，通過java -version可以檢視關於當前機器JVM的資訊，下面是我在Win8系統上執行命令的截圖，

可以看出我裝的是build 20.13-b02版本，HotSpot 型別Server模式的JVM。

2.JVM的組成

JVM由4大部分組成：ClassLoader，Runtime Data Area，Execution Engine，Native Interface。

我從CSDN找了一張描述JVM大致結構的圖：

2.1.ClassLoader是負責載入class檔案，class檔案在檔案開頭有特定的檔案標示，並且ClassLoader只負責class檔案的載入，至於它是否可以執行，則由Execution Engine決定。

2.2.Native Interface是負責呼叫本地介面的。他的作用是呼叫不同語言的介面給JAVA用，他會在Native Method Stack中記錄對應的本地方法，然後呼叫該方法時就通過Execution Engine載入對應的本地lib。原本多於用一些專業領域，如JAVA驅動，地圖製作引擎等，現在關於這種本地方法介面的呼叫已經被類似於Socket通訊，WebService等方式取代。

2.3.Execution Engine是執行引擎，也叫Interpreter。Class檔案被載入後，會把指令和資料資訊放入記憶體中，Execution Engine則負責把這些命令解釋給作業系統。

2.4.Runtime Data Area則是存放資料的，分為五部分：Stack，Heap，Method Area，PC Register，Native Method Stack。幾乎所有的關於java記憶體方面的問題，都是集中在這塊。下圖是javapapers.com上關於Run-time Data Areas的描述：

可以看出它把Method Area化為了Heap的一部分，javapapers.com中認為Method Area是Heap的邏輯區域，但這取決於JVM的實現者，而HotSpot JVM中把Method Area劃分為非堆記憶體，顯然是不包含在Heap中的。下圖是javacodegeeks.com中，2014年9月刊出的一片博文中關於Runtime Data Area的劃分，其中指出，NonHeap包含PermGen和Code Cache，PermGen包含Method Area,而且PermGen在JAVA SE 8中已經不再用了。查閱資料（https://abhirockzz.wordpress.com/2014/03/18/java-se-8-is-knocking-are-you-there/）得知，java8中PermGen已經從JVM中移除並被MetaSpace取代，java8中也不會見到OOM:PermGen Space的異常。目前Runtime Data Area可以用下圖描述它的組成：

2.4.1.Stack是java棧記憶體，它等價於C語言中的棧，棧的記憶體地址是不連續的，每個執行緒都擁有自己的棧。棧裡面儲存著的是StackFrame，在《JVM Specification》中文版中被譯作java虛擬機器框架，也叫做棧幀。StackFrame包含三類資訊：區域性變數，執行環境，運算元棧。區域性變數用來儲存一個類的方法中所用到的區域性變數。執行環境用於儲存解析器對於java位元組碼進行解釋過程中需要的資訊，包括：上次呼叫的方法、區域性變數指標和運算元棧的棧頂和棧底指標。運算元棧用於儲存運算所需要的運算元和結果。StackFrame在方法被呼叫時建立，在某個執行緒中，某個時間點上，只有一個框架是活躍的，該框架被稱為Current Frame，而框架中的方法被稱為Current Method，其中定義的類為Current Class。區域性變數和運算元棧上的操作總是引用當前框架。當Stack Frame中方法被執行完之後，或者呼叫別的StackFrame中的方法時，則當前棧變為另外一個StackFrame。Stack的大小是由兩種型別，固定和動態的，動態型別的棧可以按照執行緒的需要分配。 下面兩張圖是關於棧之間關係以及棧和非堆記憶體的關係基本描述（來自http://www.programering.com/a/MzM3QzNwATA.html）：

2.4.2.Heap是用來存放物件資訊的，和Stack不同，Stack代表著一種執行時的狀態。換句話說，棧是執行時單位，解決程式該如何執行的問題，而堆是儲存的單位，解決資料儲存的問題。Heap是伴隨著JVM的啟動而建立，負責儲存所有物件例項和陣列的。堆的儲存空間和棧一樣是不需要連續的，它分為Young Generation和Old Generation（也叫Tenured Generation）兩大部分。Young Generation分為Eden和Survivor，Survivor又分為From Space和 ToSpace。

和Heap經常一起提及的概念是PermanentSpace，它是用來載入類物件的專門的記憶體區，是非堆記憶體，和Heap一起組成JAVA記憶體，它包含MethodArea區（在沒有CodeCache的HotSpotJVM實現裡，則MethodArea就相當於GenerationSpace）。在JVM初始化的時候，我們可以通過引數來分別指定，PermanentSpace的大小、堆的大小、以及Young Generation和Old Generation的比值、Eden區和From Space的比值，從而來細粒度的適應不同JAVA應用的記憶體需求。

2.4.3.PC Register是程式計數暫存器，每個JAVA執行緒都有一個單獨的PC Register，他是一個指標，由Execution Engine讀取下一條指令。如果該執行緒正在執行java方法，則PC Register儲存的是 正在被執行的指令的地址，如果是本地方法，PC Register的值沒有定義。PC暫存器非常小，只佔用一個字寬，可以持有一個returnAdress或者特定平臺的一個指標。

2.4.4.Method Area在HotSpot JVM的實現中屬於非堆區，非堆區包括兩部分：Permanet Generation和Code Cache，而Method Area屬於Permanert Generation的一部分。Permanent Generation用來儲存類資訊，比如說：class definitions，structures，methods， field， method (data and code) 和 constants。Code Cache用來儲存Compiled Code，即編譯好的原生程式碼，在HotSpot JVM中通過JIT(Just In Time) Compiler生成，JIT是即時編譯器，他是為了提高指令的執行效率，把位元組碼檔案編譯成本地機器程式碼，如下圖：

引用一個經典的案例來理解Stack，Heap和Method Area的劃分，就是Sring a=”xx”；Stirng b=”xx”，問是否a==b? 首先==符號是用來判斷兩個物件的引用地址是否相同，而在上面的題目中，a和b按理來說申請的是Stack中不同的地址，但是他們指向Method Area中Runtime Constant Pool的同一個地址，按照網上的解釋，在a賦值為“xx”時，會在Runtime Contant Pool中生成一個String Constant，當b也賦值為“xx”時，那麼會在常量池中檢視是否存在值為“xx”的常量，存在的話，則把b的指標也指向“xx”的地址，而不是新生成一個String Constant。我查閱了網路上大家關於String Constant的儲存的說說法，存在略微差別的是，它儲存在哪裡，有人說Heap中會分配出一個常量池，用來儲存常量，所有執行緒共享它。而有人說常量池是Method Area的一部分，而Method Area屬於非堆記憶體，那怎麼能說常量池存在於堆中？

我認為，其實兩種理解都沒錯。Method Area的確從邏輯上講可以是Heap的一部分，在某些JVM實現裡從堆上開闢一塊儲存空間來記錄常量是符合JVM常量池設計目的的，所以前一種說法沒問題。對於後一種說法，HotSpot JVM的實現中的確是把方法區劃分為了非堆記憶體，意思就是它不在堆上。我在HotSpot JVM做了個簡單的實驗，定義多個常量之後，程式丟擲OOM：PermGen Space異常，印證了JVM實現中常量池是在Permanent Space中的說法。但是，我的JDK版本是1.6的。查閱資料，JDK1.7中InternedStrings已經不再儲存在PermanentSpace中，而是放到了Heap中；JDK8中PermanentSpace已經被完全移除，InternedStrings也被放到了MetaSpace中（如果出現記憶體溢位，會報OOM:MetaSpace，這裡有個關於兩者效能對比的文章：http://blog.csdn.net/zhyhang/article/details/17246223 ）。 所以，仁者見仁，智者見智，一個饅頭足以引發血案，就算是同一個商家的JVM，畢竟JDK版本在更新，或許正如StackOverFlow上大神們所說，對於理解JVM Runtime Data Area這一部分的劃分邏輯，還是去看對應版本的JDK原始碼比較靠譜，或者是參考不同的版本JVM Specification（ http://docs.oracle.com/javase/specs/ ）。

2.4.5.Native Method Stack是供本地方法（非java）使用的棧。每個執行緒持有一個Native Method Stack。

 3.JVM的執行原理簡介

Java 程式被javac工具編譯為.class位元組碼檔案之後，我們執行java命令，該class檔案便被JVM的Class Loader載入，可以看出JVM的啟動是通過JAVA Path下的java.exe或者java進行的。JVM的初始化、執行到結束大概包括這麼幾步：

呼叫作業系統API判斷系統的CPU架構，根據對應CPU型別尋找位於JRE目錄下的/lib/jvm.cfg檔案，然後通過該配置檔案找到對應的jvm.dll檔案（如果我們引數中有-server或者-client， 則載入對應引數所指定的jvm.dll，啟動指定型別的JVM），初始化jvm.dll並且掛接到JNIENV結構的例項上，之後就可以通過JNIENV例項裝載並且處理class檔案了。class檔案是位元組碼檔案，它按照JVM的規範，定義了變數，方法等的詳細資訊，JVM管理並且分配對應的記憶體來執行程式，同時管理垃圾回收。直到程式結束，一種情況是JVM的所有非守護執行緒停止，一種情況是程式呼叫System.exit()，JVM的生命週期也結束。

關於JVM如何管理分配記憶體，我通過class檔案和垃圾回收兩部分進行了學習。

二、JVM的記憶體管理和垃圾回收

JVM中的記憶體管理主要是指JVM對於Heap的管理，這是因為Stack，PC Register和Native Method Stack都是和執行緒一樣的生命週期，線上程結束時自然可以被再次使用。雖然說，Stack的管理不是重點，但是也不是完全不講究的。

1.棧的管理