深刻解析：《JVM結構體系》

一個虛擬機是一個軟件實現物理機。Java是在WORA（Write Once Run Anywhere）基礎上開發的，它運行在虛擬機上。該編譯器編譯Java文件轉換成一個Java 的.class文件，那麼 的.class文件輸入到JVM，它加載並執行類文件。如下是JVM的體系結構圖：

1、基礎知識

（一） JVM實例：JVM實例對應了一個獨立運行的java程序，它是進程級別。

（二） JVM執行引擎實例：JVM執行引擎實例則對應了屬於用戶運行程序的線程，它是線程級別的。

（三） JVM生命週期：

（1）JVM實例的誕生

當啓動一個Java程序時，一個JVM實例就產生了，任何一個擁有public static void main(String[] args)函數的class均可以做爲JVM實例運行的起點

（2）JVM實例的運行

main()做爲該程序初始線程的起點，任何其餘線程均由該線程啓動。JVM內部有兩種線程：守護線程和非守護線程，main()屬於非守護線程，守護線程一般由JVM本身使用，java程序也能夠標明本身建立的線程是守護線程。

（3）JVM實例的消亡

當程序中的全部非守護線程都終止時，JVM才退出；若安全管理器容許，程序也可使用java.lang.Runtime類或者java.lang.System.exit()來退出。

2、JVM結構

JVM能夠由不一樣的廠商來實現。因爲廠商的不一樣必然致使JVM在實現上的一些不一樣，然而JVM仍是能夠實現跨平臺的特性，這就要歸功於設計JVM時的體系結構了。

JVM體系結構包含三部分:

類加載器（Class Loader）子系統

執行引擎（Execution Engine）

運行時數據區(Runtime Data Area)

Java程序執行過程

Java程序從源文件建立到程序運行要通過兩大步驟：一、源文件由編譯器編譯成字節碼（ByteCode） 二、字節碼由java虛擬機解釋運行。由於java程序既要編譯同時也要通過JVM的解釋運行，因此說Java被稱爲半解釋語言（ "semi-interpreted" language）。

3、運行時數據區

程序計數器(Program Counter Register)、Java棧(VM Stack)、本地方法棧(Native Method Stack)、方法區(Method Area)、堆(Heap)

(一) 程序計數器(Program Counter Register

程序計數器是一塊較小的內存空間， 能夠看做是當前線程所執行的字節碼的行號指示器。 分支、循環、跳轉、異常處理、線程恢復等基礎功能都須要依賴這個計數器來完成。

因爲Java 虛擬機的多線程是經過線程輪流切換並分配處理器執行時間的方式來實現的，在任何一個肯定的時刻，一個處理器（對於多核處理器來講是一個內核）只會執行一條線程中的指令。所以，爲了線程切換後能恢復到正確的執行位置，每條線程都須要有一個獨立的程序計數器，各條線程之間的計數器互不影響，獨立存儲，咱們稱這類內存區域爲 「線程私有」 的內存。

在JVM規範中規定，若是線程執行的是非native方法，則程序計數器中保存的是當前須要執行的指令的地址；若是線程執行的是native方法，則程序計數器中的值是undefined。

因爲程序計數器中存儲的數據所佔空間的大小不會隨程序的執行而發生改變，所以，對於程序計數器是不會發生內存溢出現象(OutOfMemory)的。

Java棧(VM Stack)

Java棧也稱做虛擬機棧（Java Vitual Machine Stack），是Java方法執行的內存模型。

Java棧中存放的是一個個的棧幀， 每一個棧幀對應一個被調用的方法，在棧幀中包括局部變量表(Local Variables)、操做數棧(Operand Stack)、指向當前方法所屬的類的運行時常量池（運行時常量池的概念在方法區部分會談到）的引用(Reference to runtime constant pool)、方法返回地址(Return Address)和一些額外的附加信息。

當線程執行一個方法時，就會隨之建立一個對應的棧幀，並將創建的棧幀壓棧。當方法執行完畢以後，便會將棧幀出棧。

會有兩種異常StackOverFlowError和 OutOfMemoneyError。當線程請求棧深度大於虛擬機所容許的深度就會拋出StackOverFlowError錯誤；虛擬機棧動態擴展，當擴展沒法申請到足夠的內存空間時候，拋出OutOfMemoneyError。它是線程私有的，生命週期與線程相同。

本地方法棧(Native Method Stack) 本地方法棧與Java棧的做用和原理很是類似。區別只不過是Java棧是爲執行Java方法服務的， 而本地方法棧則是爲執行本地方法（Native Method）服務的。

在JVM規範中，並無對本地方發展的具體實現方法以及數據結構做強制規定，虛擬機能夠自由實現它。在HotSopt虛擬機中直接就把本地方法棧和Java棧合二爲一。

與虛擬機棧同樣，本地方法棧區域也會拋出StackOverflowError和OutOfMemoryError異常

方法區(Method Area)

JDK8以後-JVM運行時數據區域

JDK7及以前版本的方法區（Method Area）和Java堆同樣， 是各個線程共享的內存區域，用於存儲已經被虛擬機加載的類信息、常量、靜態常量、即時編譯器編譯後的代碼等數據。

在方法區中有一個很是重要的部分就是 運行時常量池 ，它是每個類或接口的常量池的運行時表示形式， 在類和接口被加載到JVM後，對應的運行時常量池就被建立出來。固然並不是Class文件常量池中的內容才能進入運行時常量池，在運行期間也可將新的常量放入運行時常量池中，好比String的intern方法。

實際上對於以上代碼，在JDK六、JDK七、JDK8運行結果均不同。緣由就在於字符串常量池在JDK6的時候仍是存放在方法區（永久代）因此它會拋出

OutOfMemoryError:Permanent Space；而JDK7後則將字符串常量池移到了Java堆中，上面的代碼不會拋出OOM，若將堆內存改成20M則會拋出OutOfMemoryError:Java heap space；至於JDK8則是純粹取消了方法區這個概念，取而代之的是」元空間（Metaspace）「，因此在JDK8中虛擬機參數」-XX:MaxPermSize」也就沒有了任何意義，取代它的是」-XX:MetaspaceSize「和」-XX:MaxMetaspaceSize」等。

在JVM規範中，沒有強制要求方法區必須實現垃圾回收。不少人習慣將方法區稱爲「永久代」，是由於HotSpot虛擬機以永久代來實現方法區，從而JVM的垃圾收集器能夠像管理堆區同樣管理這部分區域，從而不須要專門爲這部分設計垃圾回收機制。不過自從JDK7以後，Hotspot虛擬機便將運行時常量池從永久代移除了。

堆(Heap)

JVM中所管理內存中的最大的一塊。在虛擬機啓動時被建立。

惟一的目的是存放對象實例，幾乎全部的對象實例和數組都是在這裏分配內存。 （JVM規範中說的是全部的，可是隨着JIT便編譯器的發展和逃逸技術分析的成熟，一些實例能夠不在這個區域分配內存）

程序員基本不用去關心空間釋放的問題，Java的垃圾回收機制會自動進行處理，所以堆是垃圾收集管理的主要區域，因此也會被稱爲」GC堆「。

堆是被全部線程共享的，在JVM中只有一個堆。

淺堆和深堆

淺堆（Shallow Heap）和深堆（Retained Heap）是兩個很是重要的概念，它們分別表示一個對象結構所佔用的內存大小和一個對象被GC回收後，能夠真實釋放的內存大小。

淺堆（Shallow Heap）是指一個對象所消耗的內存。在32位系統中，一個對象引用會佔據4個字節，一個int類型會佔據4個字節，long型變量會佔據8個字節，每一個對象須要佔用8個字節。

深堆（Retained Heap）的概念略微複雜。要理解深堆，首先須要瞭解保留集（Retained Set）。對象A的保留集指當對象A被垃圾回收後，能夠被釋放的全部對象集合（包括對象A自己），即對象A的保留集能夠被認爲是隻能經過對象A被直接或間接訪問到的全部對象的集合。通俗地說，就是指僅被對象A所持有的對象的集合。深堆是指對象的保留集中全部的對象的淺堆大小之和。