JVM內存結構相關知識有哪些

今天就跟大家聊聊有關JVM內存結構相關知識有哪些，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

JVM 內存結構是指：Java 虛擬機定義了若干種程序運行期間會使用的運行時數據區，其中有一些會隨著虛擬機啟動而創建，隨著虛擬機退出而銷毀，另一些則與線程一一對應，隨著線程的開始而創建，隨著線程的結束而銷毀。具體的運行時數據區如下圖所示：

在 Java 虛擬機規范中，定義了五種運行時數據區，分別是 Java 堆、方法區、虛擬機棧、本地方法區、程序計數器，其中 Java 堆和方法區是線程共享的。接下來就具體看看這 五種運行時數據區。

Java 堆（Heap）

Java 堆是所有線程共享的一塊內存區域，它在虛擬機啟動時 就會被創建，并且單個 JVM 進程有且僅有一個 Java 堆。Java 堆是用來存放對象實例及數組，也就是說我們代碼中通過 new 關鍵字 new 出來的對象都存放在這里。所以這里也就成為了垃圾回收器的主要活動營地了，于是它就有了一個別名叫做 GC 堆，根據垃圾回收器的規則，我們可以對 Java 堆進行進一步的劃分，具體 Java 堆內存結構如下圖所示：

我們可以將 Java 堆劃分為新生代和老年代兩個大模塊，在新生代中，我們又可以進一步分為 Eden 空間、From Survivor 空間（s0）、To Survivor 空間（s1），Survivor 空間有一個為空，用于發生 GC 時存放存活對象，老年代存放的是經過多次 Minor GC 仍然存活的對象或者是一些大對象，FGC 就是發生在老年代。

上面就是 Java 堆的具體結構，我們也知道 Java 堆中的各空間大小，我們是可以動態控制的，這個在圖中我也進行了簡單的標注，下面我們一起來詳細的了解一下這三個參數：

-Xms：JVM啟動時申請的初始Heap值，默認為操作系統物理內存的1/64，例如-Xms20m  -Xmx：JVM可申請的最大Heap值，默認值為物理內存的1/4，例如-Xmx20m，我們最好將 -Xms 和 -Xmx 設為相同值，避免每次垃圾回收完成后JVM重新分配內存；  -Xmn：設置新生代的內存大小，－Xmn 是將NewSize與MaxNewSize設為一致，我們也可以分別設置這兩個參數

在 Java 堆中會發生 OOM 異常，當我們的 Java 堆內有足夠的空間去完成實例分配時，并且堆也無法擴展，將會拋出我們常見的OutOfMemoryError 異常，如下圖所示：

關于 OOM 異常，我還是想多說一句，網上有一道非常火的面試題：JVM 堆內存溢出后，其他線程是否可繼續工作？，我個人覺得不少回答是錯誤的，有興趣的可以研究一下。

方法區（Method Area）

方法區（Method Area）與 Java 堆一樣，是各個線程共享的內存區域，是 Java 虛擬機中唯二的內存共享區域。在 Java 虛擬機規范中是這樣定義方法區的：它存儲了每個類的結構信息，例如運行時常量池、字段、方法數據、構造函數和普通方法的字節碼內容，還包括一些在類、實例、接口初始化時用到的特殊方法。

方法區在虛擬機啟動的時候被創建，雖然方法區是堆的邏輯組成部分，但是簡單的虛擬機實現可以選擇在這個區域不實現垃圾收集與壓縮，方法區在實際內存空間中可以不是連續的，對于方法區的容量，你可以是固定的，也可以隨著程序的執行動態擴展，并且在不需要過多空間時自動收縮。

上面都是 Java 虛擬機中的規范，來看看具體的實現，拿我們常用的 HotSpot 虛擬機來說，在 JDK1.8 之前，方法區也被稱作為永久代，這個方法區會發生我們常見的 java.lang.OutOfMemoryError: PermGen space 異常，我們也可以通過啟動參數來控制方法區的大小：

-XX:PermSize 設置最小空間  -XX:MaxPermSize 設置最大空間

在 JDK1.8 之后，HotSpot 虛擬機對方法區進行了不小的改動，徹底移除了永久代，將原來存放在永久代的數據遷移至 Java 堆 或者 Metaspace，方法區被移至到了 Metaspace，字符串常量移至 Java Heap，換句話說就是 JDK1.8 開始，Metaspace 也就是我們所謂的方法區，為什么要做這個改變呢？也許是基于以下兩點原因：

由于 PermGen 內存經常會溢出，引發惱人的 java.lang.OutOfMemoryError: PermGen，因此 JVM 的開發者希望這一塊內存可以更靈活地被管理，不要再經常出現這樣的 OOM  移除 PermGen 可以促進 HotSpot JVM 與 JRockit VM 的融合，因為 JRockit 沒有永久代。

我們也可以通過設置參數來控制 Metaspace 的空間大小，主要有以下幾個命令：

-XX:MetaspaceSize ：分配給類元數據空間（以字節計）的初始大小。MetaspaceSize的值設置的過大會延長垃圾回收時間。垃圾回收過后，引起下一次垃圾回收的類元數據空間的大小可能會變大。  -XX:MaxMetaspaceSize： 分配給類元數據空間的最大值，超過此值就會觸發Full GC，此值默認沒有限制，但應取決于系統內存的大小。JVM會動態地改變此值。  -XX:MinMetaspaceFreeRatio：表示一次GC以后，為了避免增加元數據空間的大小，空閑的類元數據的容量的最小比例，不夠就會導致垃圾回收。  -XX:MaxMetaspaceFreeRatio：表示一次GC以后，為了避免增加元數據空間的大小，空閑的類元數據的容量的最大比例，不夠就會導致垃圾回收。

Java 虛擬機棧（JVM Stacks）

每一條 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 虛擬機棧允許的最大容量，Java 虛擬機將會拋出 StackOverflowError 異常；  如果 Java 虛擬機棧可以動態擴展，并且在嘗試擴展的時候無法申請到足夠的內存或者在創建新的線程時沒有足夠的內存去創建對應的 Java 虛擬機棧，那么虛擬機將會拋出 OutOfMemoryError 異常。

程序計數器（Program Counter Register）

程序計數器也是線程私有的，它只需要一塊較小的內存空間，你可以把它看作當前線程所執行的字節碼的行號指示器，在虛擬機的概念模型里（僅是概念模型，各種虛擬機可能會通過一些更高效的方式去實現），字節碼解釋器工作時就是通過改變這個計數器的值來選取下一條需要執行的字節碼指令，分支、循環、跳轉、異常處理、線程恢復等基礎功能都需要依賴這個計數器來完成。

我們知道在多線程的情況下，并不是一條線程一直執行完，而是多個線程輪流切換執行，所以為了線程切換后能夠恢復到正確的執行位置，我們就需要程序計數器來告訴線程接下來該執行哪條指令。如果線程正在執行的是一個Java 方法，這個計數器記錄的是正在執行的虛擬機字節碼指令的地址，如果正在執行的是 Natvie 方法，這個計數器值則為空（Undefined）。

需要特別注意的是，程序計數器是唯一一個在Java虛擬機規范中沒有規定任何 OutOfMemoryError 情況的區域。

本地方法棧（Native Method Stacks）

本地方法棧（Native Method Stacks）與 Java 虛擬機棧所發揮的作用是非常相似的，其區別不過是 Java 虛擬機棧為虛擬機執行 Java 方法（也就是字節碼）服務，而本地方法棧則是為虛擬機使用到的 Native 方法服務。虛擬機規范中對本地方法棧中的方法使用的語言、使用方式與數據結構并沒有強制規定，因此具體的虛擬機可以自由實現它。甚至有的虛擬機（譬如Sun HotSpot虛擬機）直接就把本地方法棧和虛擬機棧合二為一。

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

看完上述內容，你們對JVM內存結構相關知識有哪些有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。