寫在前面

基本問題:

介紹下 Java 內(nèi)存區(qū)域（運(yùn)行時數(shù)據(jù)區(qū)）。
JDK7 和 JDK8 在內(nèi)存結(jié)構(gòu)上有什么變化

拓展問題:

String 類和常量池
8種基本類型的包裝類和常量池

概述

由于 java 語言天生自帶內(nèi)存自動管理機(jī)制，所以 java 程序開發(fā)時幾乎不用考慮內(nèi)存的回收，不再需要像 C/C++ 程序開發(fā)那樣為一個 new 出來的對象去寫對應(yīng)的 delete/free 操作，也不容易出現(xiàn)內(nèi)存泄露和內(nèi)存溢出問題。也正是因?yàn)?java 程序?qū)?nèi)存管理都交給 JVM 來處理，如果不了解虛擬機(jī)是怎樣使用內(nèi)存的，那么排查錯誤將會是一個非常艱巨的任務(wù)。

運(yùn)行時數(shù)據(jù)區(qū)域

根據(jù) Java 虛擬機(jī)規(guī)范的規(guī)定, Java 虛擬機(jī)(Java Virtual Machine, JVM)在執(zhí)行 Java 程序的過程中會把它管理的內(nèi)存劃分成若干個不同的數(shù)據(jù)區(qū)域：程序計數(shù)器(Program Counter Register)、Java虛擬機(jī)棧(JVM Stack)、本地方法棧(Native Method Stack)、方法區(qū)(Method Area)、堆(Heap)。

程序計數(shù)器 (Program Counter Register)

程序計數(shù)器是一塊較小的內(nèi)存空間，可以看作是當(dāng)前線程所執(zhí)行的字節(jié)碼的行號指示器。字節(jié)碼解釋器工作時通過改變這個計數(shù)器的值來選取下一條需要執(zhí)行的字節(jié)碼指令，分支、循環(huán)、跳轉(zhuǎn)、異常處理、線程恢復(fù)等功能都需要依賴這個計數(shù)器來完成。

另外，為了線程切換后能恢復(fù)到正確的執(zhí)行位置，每條線程都需要有一個獨(dú)立的程序計數(shù)器，各線程之間計數(shù)器互不影響，獨(dú)立存儲，我們稱這類內(nèi)存區(qū)域?yàn)?線程私有 的內(nèi)存。

從上面的介紹中我們知道程序計數(shù)器主要有兩個作用：

字節(jié)碼解釋器通過改變程序計數(shù)器來依次讀取指令，從而實(shí)現(xiàn)代碼的流程控制，如：順序執(zhí)行、選擇、循環(huán)、異常處理。
在多線程的情況下，程序計數(shù)器用于記錄當(dāng)前線程執(zhí)行的位置，從而當(dāng)線程被切換回來的時候能夠知道該線程上次運(yùn)行到哪兒了。

注意：程序計數(shù)器是唯一一個不會出現(xiàn) OutOfMemoryError 的內(nèi)存區(qū)域，它的生命周期隨著線程的創(chuàng)建而創(chuàng)建，隨著線程的結(jié)束而死亡。

Java虛擬機(jī)棧 (JVM Stack)

與程序計數(shù)器一樣，Java 虛擬機(jī)棧 (Java Virtual Machine Stacks) 也是線程私有的，它的生命周期和線程相同，描述的是 Java 方法執(zhí)行的內(nèi)存模型: 每次方法調(diào)用的數(shù)據(jù)都是通過棧傳遞的。

Java 內(nèi)存可以粗糙的區(qū)分為堆內(nèi)存 (Heap) 和棧內(nèi)存 (Stack) ，其中棧就是現(xiàn)在說的虛擬機(jī)棧，或者說是虛擬機(jī)棧中局部變量表部分。 (實(shí)際上，Java 虛擬機(jī)棧是由一個個棧幀組成，而每個棧幀中都擁有：局部變量表、操作數(shù)棧、動態(tài)鏈接、方法出口信息。)

局部變量表主要存放了編譯器可知的各種數(shù)據(jù)類型 (boolean、byte、char、short、int、float、long、double) 、對象引用 (reference 類型，它不同于對象本身，可能是一個指向?qū)ο笃鹗嫉刂返囊弥羔?，也可能是指向一個代表對象的句柄或其他與此對象相關(guān)的位置）和 returnAddress 類型(指向了一條字節(jié)碼指令的地址)。

returnAddress 類型的值是指向字節(jié)碼的指針， 數(shù)據(jù)只存在于字節(jié)碼層面，與編程語言無關(guān)，也就是說，我們在 Java 語言中是不會直接與 returnAddress 類型的數(shù)據(jù)打交道的

Java 虛擬機(jī)棧會出現(xiàn)兩種異常：StackOverFlowError 和 OutOfMemoryError。

StackOverFlowError： 若 Java 虛擬機(jī)棧的內(nèi)存大小不允許動態(tài)擴(kuò)展，那么當(dāng)線程請求棧的深度超過當(dāng)前 Java 虛擬機(jī)棧的最大深度的時候，就拋出 StackOverFlowError 異常。
OutOfMemoryError： 若 Java 虛擬機(jī)棧的內(nèi)存大小允許動態(tài)擴(kuò)展，且當(dāng)線程請求棧時內(nèi)存用完了，無法再動態(tài)擴(kuò)展了，此時拋出 OutOfMemoryError 異常。

Java 虛擬機(jī)棧也是線程私有的，每個線程都有各自的 Java 虛擬機(jī)棧，而且隨著線程的創(chuàng)建而創(chuàng)建，隨著線程的死亡而死亡。

擴(kuò)展：那么方法/函數(shù)如何調(diào)用？

Java 棧可用類比數(shù)據(jù)結(jié)構(gòu)中棧，Java 棧中保存的主要內(nèi)容是棧幀，每一次函數(shù)調(diào)用都會有一個對應(yīng)的棧幀被壓入 Java 棧，每一個函數(shù)調(diào)用結(jié)束后，都會有一個棧幀被彈出。

Java 方法有兩種返回方式：

return;         //語句
throw Exception //拋出異常

不管哪種返回方式都會導(dǎo)致棧幀被彈出。

本地方法棧 (Native Method Stack)

本地方法棧和虛擬機(jī)棧所發(fā)揮的作用非常相似，區(qū)別是： 虛擬機(jī)棧為虛擬機(jī)執(zhí)行 Java 方法 （也就是字節(jié)碼）服務(wù)，而本地方法棧則為虛擬機(jī)使用到的 Native 方法 (沒有強(qiáng)制規(guī)范，比如通過 JNI 直接調(diào)用本地 C/C++ 庫)服務(wù)。 虛擬機(jī)規(guī)范中對本地方法棧中的方法使用的語言、使用方式與數(shù)據(jù)結(jié)構(gòu)并沒有強(qiáng)制規(guī)定，因此具體的虛擬機(jī)可以自由實(shí)現(xiàn)它。甚至有的虛擬機(jī)（譬如Sun HotSpot虛擬機(jī)）直接就把本地方法棧和虛擬機(jī)棧合二為一。

Navtive 方法

Java 通過 JNI 直接調(diào)用本地 C/C++ 庫，可以認(rèn)為 Native 方法相當(dāng)于 C/C++ 暴露給 Java 的一個接口，Java 通過調(diào)用這個接口從而調(diào)用到 C/C++ 方法。當(dāng)線程調(diào)用 Java 方法時，虛擬機(jī)會創(chuàng)建一個棧幀并壓入 Java 虛擬機(jī)棧。然而當(dāng)它調(diào)用的是 native 方法時，虛擬機(jī)會保持 Java 虛擬機(jī)棧不變，也不會向 Java 虛擬機(jī)棧中壓入新的棧幀，虛擬機(jī)只是簡單地動態(tài)連接并直接調(diào)用指定的 native 方法。

本地方法被執(zhí)行的時候，在本地方法棧也會創(chuàng)建一個棧幀，用于存放該本地方法的局部變量表、操作數(shù)棧、動態(tài)鏈接、出口信息。

方法執(zhí)行完畢后相應(yīng)的棧幀也會出棧并釋放內(nèi)存空間，也會出現(xiàn) StackOverFlowError 和 OutOfMemoryError 兩種異常。

Java 堆 (Java Heap)

Java 堆是 Java 虛擬機(jī)所管理的內(nèi)存中最大的一塊，Java 堆是所有線程共享的一塊內(nèi)存區(qū)域，在虛擬機(jī)啟動時創(chuàng)建。此內(nèi)存區(qū)域的唯一目的就是存放對象實(shí)例，幾乎所有的對象實(shí)例以及數(shù)組都在這里分配內(nèi)存。

Java 堆是垃圾收集器管理的主要區(qū)域，因此也被稱作 ** GC 堆（Garbage Collected Heap）** 。從垃圾回收的角度，由于現(xiàn)在收集器基本都采用分代垃圾收集算法，所以 Java 堆還可以細(xì)分為：新生代和老年代；再細(xì)致一點(diǎn)有：Eden 空間、From Survivor、To Survivor 空間等。進(jìn)一步劃分的目的是更好地回收內(nèi)存，或者更快地分配內(nèi)存。

上圖所示的 eden 區(qū)、s0 區(qū)、s1 區(qū)都屬于新生代，tentired 區(qū)屬于老年代。大部分情況，對象都會首先在 Eden 區(qū)域分配，在一次新生代垃圾回收后，如果對象還存活，則會進(jìn)入 s0 或者 s1，并且對象的年齡還會加 1(Eden 區(qū)->Survivor 區(qū)后對象的初始年齡變?yōu)?1)，當(dāng)它的年齡增加到一定程度（默認(rèn)為 15 歲），就會被晉升到老年代中。對象晉升到老年代的年齡閾值，可以通過參數(shù) -XX:MaxTenuringThreshold 來設(shè)置。

方法區(qū) (Method Area)

方法區(qū)與 Java 堆一樣，是各個線程共享的內(nèi)存區(qū)域，它用于存儲已被虛擬機(jī)加載的類信息、常量、靜態(tài)變量、即時編譯器編譯后的代碼等數(shù)據(jù)。雖然 Java 虛擬機(jī)規(guī)范把方法區(qū)描述為堆的一個邏輯部分，但是它卻有一個別名叫做 Non-Heap（非堆），目的應(yīng)該是與 Java 堆區(qū)分開來。

方法區(qū)也被稱為永久代，其實(shí)從不同角度去理解虛擬機(jī)，因此很多人都會分不清方法區(qū)和永久代的關(guān)系。

方法區(qū)和永久代的關(guān)系

《 Java 虛擬機(jī)規(guī)范》只是規(guī)定了有方法區(qū)這么個概念和它的作用，并沒有規(guī)定如何去實(shí)現(xiàn)它。那么，在不同的 JVM 上方法區(qū)的實(shí)現(xiàn)肯定是不同的了。 方法區(qū)和永久代的關(guān)系很像 Java 中接口和類的關(guān)系，類實(shí)現(xiàn)了接口，而永久代就是 HotSpot 虛擬機(jī)對虛擬機(jī)規(guī)范中方法區(qū)的一種實(shí)現(xiàn)方式。 也就是說，永久代是 HotSpot 的概念，方法區(qū)是 Java 虛擬機(jī)規(guī)范中的定義，是一種規(guī)范，而永久代是一種實(shí)現(xiàn)，一個是標(biāo)準(zhǔn)一個是實(shí)現(xiàn)，其他的虛擬機(jī)實(shí)現(xiàn)并沒有永久代這一說法。

簡而言之，方法區(qū)是一種規(guī)范，而永久代是方法區(qū)的一種實(shí)現(xiàn)，Java 規(guī)范了方法區(qū)的定義，但是沒有規(guī)定方法區(qū)的實(shí)現(xiàn)。

常用參數(shù)

JDK 1.8 之前永久代還沒被徹底移除的時候通常通過下面這些參數(shù)來調(diào)節(jié)方法區(qū)大小

-XX:PermSize=N //方法區(qū) (永久代) 初始大小
-XX:MaxPermSize=N //方法區(qū) (永久代) 最大大小,超過這個值將會拋出 OutOfMemoryError 異常:java.lang.OutOfMemoryError: PermGen

相對而言，垃圾收集行為在這個區(qū)域是比較少出現(xiàn)的，但并非數(shù)據(jù)進(jìn)入方法區(qū)后就“永久存在”了。

JDK 1.8 的時候，方法區(qū)（HotSpot 的永久代）被徹底移除了（JDK1.7 就已經(jīng)開始了，只是講運(yùn)行時常量池放入 Java 堆中，但沒有完全去除），取而代之是元空間，元空間使用的是直接內(nèi)存。

下面是一些常用參數(shù)：

-XX:MetaspaceSize=N //設(shè)置 Metaspace 的初始（和最小大?。?-XX:MaxMetaspaceSize=N //設(shè)置 Metaspace 的最大大小

與永久代很大的不同就是，如果不指定大小的話，隨著更多類的創(chuàng)建，虛擬機(jī)會耗盡所有可用的系統(tǒng)內(nèi)存。

為什么要將永久代 (PermGen) 替換為元空間 (MetaSpace) 呢?

整個永久代有一個 JVM 本身設(shè)置固定大小上限，無法進(jìn)行調(diào)整，而元空間使用的是直接內(nèi)存，受本機(jī)可用內(nèi)存的限制，并且永遠(yuǎn)不會得到 java.lang.OutOfMemoryError。你可以使用 -XX：MaxMetaspaceSize 標(biāo)志設(shè)置最大元空間大小，默認(rèn)值為 unlimited，這意味著它只受系統(tǒng)內(nèi)存的限制。-XX：MetaspaceSize 調(diào)整標(biāo)志定義元空間的初始大小如果未指定此標(biāo)志，則 Metaspace 將根據(jù)運(yùn)行時的應(yīng)用程序需求動態(tài)地重新調(diào)整大小。

當(dāng)然這只是其中一個原因，還有很多底層的原因，這里就不提了。

運(yùn)行時常量池 (Runtime Constant Pool)

運(yùn)行時常量池是方法區(qū)的一部分。
方法區(qū)存著類的信息，常量和靜態(tài)變量，即類被編譯后的數(shù)據(jù)。這個說法其實(shí)是沒問題的，只是太籠統(tǒng)了。更加詳細(xì)一點(diǎn)的說法是方法區(qū)里存放著類的版本，字段，方法，接口和常量池。常量池用于存放編譯期生成的各種字面量和符號引用。

既然運(yùn)行時常量池是方法區(qū)的一部分，自然受到方法區(qū)內(nèi)存的限制，當(dāng)常量池?zé)o法再申請到內(nèi)存時會拋出 OutOfMemoryError 異常。

JDK1.7 及之后版本的 JVM 已經(jīng)將運(yùn)行時常量池從方法區(qū)中移了出來，在 Java 堆（Heap）中開辟了一塊區(qū)域存放運(yùn)行時常量池。

直接內(nèi)存 (Direct Memory)

直接內(nèi)存并不是虛擬機(jī)運(yùn)行時數(shù)據(jù)區(qū)的一部分，也不是虛擬機(jī)規(guī)范中定義的內(nèi)存區(qū)域，但是這部分內(nèi)存也被頻繁地使用。而且也可能導(dǎo)致 OutOfMemoryError 異常出現(xiàn)，即堆外內(nèi)存溢出。

java.lang.OutOfMemoryError: Direct buffer memory
io.netty.util.internal.OutOfDirectMemoryError

堆外內(nèi)存溢出原因很多，這里不仔細(xì)分析原因。

JDK1.4 中新加入的 NIO (New Input/Output) 類，引入了一種基于通道 (Channel) 與緩存區(qū) (Buffer) 的 I/O 方式，它可以直接使用 Native 函數(shù)庫直接分配堆外內(nèi)存，然后通過一個存儲在 Java 堆中的 DirectByteBuffer 對象作為這塊內(nèi)存的引用進(jìn)行操作。這樣就能在一些場景中顯著提高性能，因?yàn)楸苊饬嗽?Java 堆和 Native 堆之間來回復(fù)制數(shù)據(jù)。

本機(jī)直接內(nèi)存的分配不會受到 Java 堆的限制，但是，既然是內(nèi)存就會受到本機(jī)總內(nèi)存大小以及處理器尋址空間的限制。

總結(jié)

這里對運(yùn)行時區(qū)域可能出現(xiàn)的內(nèi)存溢出情況和主要原因做一個小結(jié)。

本文由小龍的博客 發(fā)布！