最近在看《 JAVA併發編程實踐 》這本書,裏面涉及到了 Java 內存模型,經過 Java 內存模型瓜熟蒂落的來到的 JVM 內存結構,關於 JVM 內存結構的認知還停留在上大學那會的課堂上,一直沒有系統的學習這一塊的知識,因此這一次我把《 深刻理解Java虛擬機JVM高級特性與最佳實踐 》、《 Java虛擬機規範 Java SE 8版 》這兩本書中關於 JVM 內存結構的部分都看了一遍,算是對 JVM 內存結構有了新的認識。JVM 內存結構是指:Java 虛擬機定義了若干種程序運行期間會使用的運行時數據區,其中有一些會隨着虛擬機啓動而建立,隨着虛擬機退出而銷燬,另外一些則與線程一一對應,隨着線程的開始而建立,隨着線程的結束而銷燬。具體的運行時數據區以下圖所示:java
在 Java 虛擬機規範中,定義了五種運行時數據區,分別是 Java 堆、方法區、虛擬機棧、本地方法區、程序計數器,其中 Java 堆和方法區是線程共享的。接下來就具體看看這 五種運行時數據區。面試
Java 堆是全部線程共享的一塊內存區域,它在虛擬機啓動時 就會被建立,而且單個 JVM 進程有且僅有一個 Java 堆。Java 堆是用來存放對象實例及數組,也就是說咱們代碼中經過 new 關鍵字 new 出來的對象都存放在這裏。因此這裏也就成爲了垃圾回收器的主要活動營地了,因而它就有了一個別名叫作 GC 堆,根據垃圾回收器的規則,咱們能夠對 Java 堆進行進一步的劃分,具體 Java 堆內存結構以下圖所示:編程
咱們能夠將 Java 堆劃分爲新生代和老年代兩個大模塊,在新生代中,咱們又能夠進一步分爲 Eden 空間、From Survivor 空間(s0)、To Survivor 空間(s1),Survivor 空間有一個爲空,用於發生 GC 時存放存活對象,老年代存放的是通過屢次 Minor GC 仍然存活的對象或者是一些大對象,FGC 就是發生在老年代。數組
上面就是 Java 堆的具體結構,咱們也知道 Java 堆中的各空間大小,咱們是能夠動態控制的,這個在圖中我也進行了簡單的標註,下面咱們一塊兒來詳細的瞭解一下這三個參數:微信
在 Java 堆中會發生 OOM 異常,當咱們的 Java 堆內有足夠的空間去完成實例分配時,而且堆也沒法擴展,將會拋出咱們常見的OutOfMemoryError 異常,以下圖所示:數據結構
關於 OOM 異常,我仍是想多說一句,網上有一道很是火的面試題:JVM 堆內存溢出後,其餘線程是否可繼續工做?
,我我的以爲很多回答是錯誤的,有興趣的能夠研究一下。多線程
方法區(Method Area)與 Java 堆同樣,是各個線程共享的內存區域,是 Java 虛擬機中惟二的內存共享區域。在 Java 虛擬機規範中是這樣定義方法區的:它存儲了每一個類的結構信息,例如運行時常量池、字段、方法數據、構造函數和普通方法的字節碼內容,還包括一些在類、實例、接口初始化時用到的特殊方法。併發
方法區在虛擬機啓動的時候被建立,雖然方法區是堆的邏輯組成部分,可是簡單的虛擬機實現能夠選擇在這個區域不實現垃圾收集與壓縮,方法區在實際內存空間中能夠不是連續的,對於方法區的容量,你能夠是固定的,也能夠隨着程序的執行動態擴展,而且在不須要過多空間時自動收縮。函數
上面都是 Java 虛擬機中的規範,來看看具體的實現,拿咱們經常使用的 HotSpot 虛擬機來講,在 JDK1.8 以前,方法區也被稱做爲永久代,這個方法區會發生咱們常見的 java.lang.OutOfMemoryError: PermGen space
異常,咱們也能夠經過啓動參數來控制方法區的大小:學習
在 JDK1.8 以後,HotSpot 虛擬機對方法區進行了不小的改動,完全移除了永久代,將原來存放在永久代的數據遷移至 Java 堆 或者 Metaspace,方法區被移至到了 Metaspace,字符串常量移至 Java Heap,換句話說就是 JDK1.8 開始,Metaspace 也就是咱們所謂的方法區,爲何要作這個改變呢?也許是基於如下兩點緣由:
咱們也能夠經過設置參數來控制 Metaspace 的空間大小,主要有如下幾個命令:
每一條 Java 虛擬機線程都有本身私有的 Java 虛擬機棧,這個 Java 虛擬機棧跟線程同時建立,因此它跟線程有相同的生命週期。Java 虛擬機棧描述的是 Java 方法執行的內存模型:每個方法在執行的同時都會建立一個棧幀,用於存儲局部變量表、操做數棧、動態連接、方法出口等信息,每個方法從調用直至執行完成的過程,就對應着一個棧幀在 Java 虛擬機棧中的入棧到出棧的過程。
局部變量表存放了編譯期可知的各類基本數據類型(boolean、byte、char、short、int、float、long、double)、對象引用(reference 類型,它不等同於對象自己,根據不一樣的虛擬機實現,它多是一個指向對象起始地址的引用指針,也可能指向一個表明對象的句柄或者其餘與此對象相關的位置)和 returnAddress 類型(指向了一條字節碼指令的地址)。
其中 64 位長度的 long 和 double 類型的數據會佔用 2 個局部變量空間(Slot),其他的數據類型只佔用 1 個。局部變量表所需的內存空間在編譯期間完成分配,當進入一個方法時,這個方法須要在幀中分配多大的局部變量空間是徹底肯定的,在方法運行期間不會改變局部變量表的大小。
Java 虛擬機棧既容許被實現成固定的大小,也容許根據計算動態來擴展和收縮,若是採用固定大小的話,每個線程的 Java 虛擬機棧容量能夠在線程建立的時候獨立選定。在 Java 虛擬機棧中會發生兩種異常,這個在虛擬機規範中有指出:
程序計數器也是線程私有的,它只須要一塊較小的內存空間,你能夠把它看做當前線程所執行的字節碼的行號指示器,在虛擬機的概念模型裏(僅是概念模型,各類虛擬機可能會經過一些更高效的方式去實現),字節碼解釋器工做時就是經過改變這個計數器的值來選取下一條須要執行的字節碼指令,分支、循環、跳轉、異常處理、線程恢復等基礎功能都須要依賴這個計數器來完成。
咱們知道在多線程的狀況下,並非一條線程一直執行完,而是多個線程輪流切換執行,因此爲了線程切換後可以恢復到正確的執行位置,咱們就須要程序計數器來告訴線程接下來該執行哪條指令。若是線程正在執行的是一個Java 方法,這個計數器記錄的是正在執行的虛擬機字節碼指令的地址,若是正在執行的是 Natvie 方法,這個計數器值則爲空(Undefined)。
須要特別注意的是,程序計數器是惟一一個在Java虛擬機規範中沒有規定任何 OutOfMemoryError 狀況的區域。
本地方法棧(Native Method Stacks)與 Java 虛擬機棧所發揮的做用是很是類似的,其區別不過是 Java 虛擬機棧爲虛擬機執行 Java 方法(也就是字節碼)服務,而本地方法棧則是爲虛擬機使用到的 Native 方法服務。虛擬機規範中對本地方法棧中的方法使用的語言、使用方式與數據結構並無強制規定,所以具體的虛擬機能夠自由實現它。甚至有的虛擬機(譬如Sun HotSpot虛擬機)直接就把本地方法棧和虛擬機棧合二爲一。
與 Java 虛擬機棧同樣,本地方法棧區域也會拋出 StackOverflowError 和 OutOfMemoryError 異常。
目前互聯網上不少大佬都有 JVM 內存結構相關文章,若有雷同,請多多包涵了。原創不易,碼字不易,還但願你們多多支持。若文中有所錯誤之處,還望提出,謝謝,歡迎掃碼關注微信公衆號:「平頭哥的技術博文」,和平頭哥一塊兒學習,一塊兒進步。