一、JVM 內(nèi)存模型

根據(jù) JVM 規(guī)范，JVM 內(nèi)存共分為虛擬機棧、堆、方法區(qū)、程序計數(shù)器、本地方法棧五個部分。

1、虛擬機棧：每個線程有一個私有的棧，隨著線程的創(chuàng)建而創(chuàng)建。棧里面存著的是一種叫“棧幀”的東西，每個方法會創(chuàng)建一個棧幀，棧幀中存放了局部變量表（基本數(shù)據(jù)類型和對象引用）、操作數(shù)棧、方法出口等信息。棧的大小可以固定也可以動態(tài)擴展。當(dāng)棧調(diào)用深度大于JVM所允許的范圍，會拋出StackOverflowError的錯誤，不過這個深度范圍不是一個恒定的值，我們通過下面這段程序可以測試一下這個結(jié)果：

棧溢出測試源碼：

package com.paddx.test.memory; public class StackErrorMock { private static int index = 1; public void call(){ index++; call(); } public static void main(String[] args) { StackErrorMock mock = new StackErrorMock(); try { mock.call(); }catch (Throwable e){ System.out.println('Stack deep : '+index); e.printStackTrace(); } }}

代碼段 1

運行三次，可以看出每次棧的深度都是不一樣的，輸出結(jié)果如下。

至于紅色框里的值是怎么出來的，就需要深入到 JVM 的源碼中才能探討，這里不作詳細闡述。

虛擬機棧除了上述錯誤外，還有另一種錯誤，那就是當(dāng)申請不到空間時，會拋出 OutOfMemoryError。這里有一個小細節(jié)需要注意，catch 捕獲的是Throwable，而不是 Exception。因為StackOverflowError 和 OutOfMemoryError 都不屬于 Exception 的子類。

2、本地方法棧：

這部分主要與虛擬機用到的 Native 方法相關(guān)，一般情況下， Java 應(yīng)用程序員并不需要關(guān)心這部分的內(nèi)容。

3、PC 寄存器：

PC 寄存器，也叫程序計數(shù)器。JVM支持多個線程同時運行，每個線程都有自己的程序計數(shù)器。倘若當(dāng)前執(zhí)行的是 JVM 的方法，則該寄存器中保存當(dāng)前執(zhí)行指令的地址；倘若執(zhí)行的是native 方法，則PC寄存器中為空。

4、堆

堆內(nèi)存是 JVM 所有線程共享的部分，在虛擬機啟動的時候就已經(jīng)創(chuàng)建。所有的對象和數(shù)組都在堆上進行分配。這部分空間可通過 GC 進行回收。當(dāng)申請不到空間時會拋出 OutOfMemoryError。下面我們簡單的模擬一個堆內(nèi)存溢出的情況：

package com.paddx.test.memory; import java.util.ArrayList;import java.util.List; public class HeapOomMock { public static void main(String[] args) { List<byte[]> list = new ArrayList<byte[]>(); int i = 0; boolean flag = true; while (flag){ try {i++;list.add(new byte[1024 * 1024]);//每次增加一個1M大小的數(shù)組對象 }catch (Throwable e){e.printStackTrace();flag = false;System.out.println('count='+i);//記錄運行的次數(shù) } } }}

代碼段 2

運行上述代碼，輸出結(jié)果如下：

注意，這里我指定了堆內(nèi)存的大小為16M，所以這個地方顯示的count=14（這個數(shù)字不是固定的），至于為什么會是14或其他數(shù)字，需要根據(jù) GC 日志來判斷，具體原因會在下篇文章中給大家解釋。

5、方法區(qū)：

方法區(qū)也是所有線程共享。主要用于存儲類的信息、常量池、方法數(shù)據(jù)、方法代碼等。方法區(qū)邏輯上屬于堆的一部分，但是為了與堆進行區(qū)分，通常又叫“非堆”。 關(guān)于方法區(qū)內(nèi)存溢出的問題會在下文中詳細探討。

二、PermGen（永久代）

絕大部分 Java 程序員應(yīng)該都見過 'java.lang.OutOfMemoryError:PermGenspace'這個異常。這里的 “PermGen space”其實指的就是方法區(qū)。不過方法區(qū)和“PermGen space”又有著本質(zhì)的區(qū)別。前者是 JVM 的規(guī)范，而后者則是 JVM 規(guī)范的一種實現(xiàn)，并且只有 HotSpot 才有“PermGen space”，而對于其他類型的虛擬機，如 JRockit（Oracle）、J9（IBM） 并沒有“PermGen space”。由于方法區(qū)主要存儲類的相關(guān)信息，所以對于動態(tài)生成類的情況比較容易出現(xiàn)永久代的內(nèi)存溢出。最典型的場景就是，在 jsp 頁面比較多的情況，容易出現(xiàn)永久代內(nèi)存溢出。我們現(xiàn)在通過動態(tài)生成類來模擬 “PermGenspace”的內(nèi)存溢出：

package com.paddx.test.memory;public class Test {}

代碼段 3

package com.paddx.test.memory; import java.io.File;import java.net.URL;import java.net.URLClassLoader;import java.util.ArrayList;import java.util.List; public class PermGenOomMock{ public static void main(String[] args) { URL url = null; List<ClassLoader> classLoaderList = new ArrayList<ClassLoader>(); try { url = new File('/tmp').toURI().toURL(); URL[] urls = {url}; while (true){ClassLoader loader = new URLClassLoader(urls);classLoaderList.add(loader);loader.loadClass('com.paddx.test.memory.Test'); } } catch (Exception e) { e.printStackTrace(); } }}

代碼段 4

運行結(jié)果如下：

本例中使用的 JDK 版本是 1.7，指定的 PermGen 區(qū)的大小為 8M。通過每次生成不同URLClassLoader對象來加載Test類，從而生成不同的類對象，這樣就能看到我們熟悉的'java.lang.OutOfMemoryError:PermGenspace' 異常了。這里之所以采用 JDK 1.7，是因為在 JDK 1.8 中， HotSpot 已經(jīng)沒有 “PermGen space”這個區(qū)間了，取而代之是一個叫做 Metaspace（元空間） 的東西。下面我們就來看看 Metaspace 與 PermGen space 的區(qū)別。

三、Metaspace（元空間）

其實，移除永久代的工作從JDK1.7就開始了。JDK1.7中，存儲在永久代的部分數(shù)據(jù)就已經(jīng)轉(zhuǎn)移到了Java Heap或者是 Native Heap。但永久代仍存在于JDK1.7中，并沒完全移除，譬如符號引用(Symbols)轉(zhuǎn)移到了native heap；字面量(interned strings)轉(zhuǎn)移到了java heap；類的靜態(tài)變量(class statics)轉(zhuǎn)移到了java heap。我們可以通過一段程序來比較 JDK 1.6 與 JDK 1.7及 JDK 1.8 的區(qū)別，以字符串常量為例：

package com.paddx.test.memory; import java.util.ArrayList;import java.util.List; public class StringOomMock { static String base = 'string'; public static void main(String[] args) { List<String> list = new ArrayList<String>(); for (int i=0;i< Integer.MAX_VALUE;i++){ String str = base + base; base = str; list.add(str.intern()); } }}

這段程序以2的指數(shù)級不斷的生成新的字符串，這樣可以比較快速的消耗內(nèi)存。我們通過 JDK 1.6、JDK 1.7 和 JDK 1.8 分別運行：

JDK 1.6 的運行結(jié)果：

JDK 1.7的運行結(jié)果：

JDK 1.8的運行結(jié)果：

從上述結(jié)果可以看出，JDK 1.6下，會出現(xiàn)“PermGen Space”的內(nèi)存溢出，而在 JDK 1.7和 JDK 1.8 中，會出現(xiàn)堆內(nèi)存溢出，并且 JDK 1.8中 PermSize 和 MaxPermGen 已經(jīng)無效。因此，可以大致驗證 JDK 1.7 和 1.8 將字符串常量由永久代轉(zhuǎn)移到堆中，并且 JDK 1.8 中已經(jīng)不存在永久代的結(jié)論。現(xiàn)在我們看看元空間到底是一個什么東西？

元空間的本質(zhì)和永久代類似，都是對JVM規(guī)范中方法區(qū)的實現(xiàn)。不過元空間與永久代之間最大的區(qū)別在于：元空間并不在虛擬機中，而是使用本地內(nèi)存。因此，默認情況下，元空間的大小僅受本地內(nèi)存限制，但可以通過以下參數(shù)來指定元空間的大小：

-XX:MetaspaceSize，初始空間大小，達到該值就會觸發(fā)垃圾收集進行類型卸載，同時GC會對該值進行調(diào)整：如果釋放了大量的空間，就適當(dāng)降低該值；如果釋放了很少的空間，那么在不超過MaxMetaspaceSize時，適當(dāng)提高該值。-XX:MaxMetaspaceSize，最大空間，默認是沒有限制的。

除了上面兩個指定大小的選項以外，還有兩個與 GC 相關(guān)的屬性：-XX:MinMetaspaceFreeRatio，在GC之后，最小的Metaspace剩余空間容量的百分比，減少為分配空間所導(dǎo)致的垃圾收集-XX:MaxMetaspaceFreeRatio，在GC之后，最大的Metaspace剩余空間容量的百分比，減少為釋放空間所導(dǎo)致的垃圾收集

現(xiàn)在我們在 JDK 8下重新運行一下代碼段 4，不過這次不再指定 PermSize 和 MaxPermSize。而是指定 MetaSpaceSize 和 MaxMetaSpaceSize的大小。輸出結(jié)果如下：

從輸出結(jié)果，我們可以看出，這次不再出現(xiàn)永久代溢出，而是出現(xiàn)了元空間的溢出。

四、總結(jié)

通過上面分析，大家應(yīng)該大致了解了 JVM 的內(nèi)存劃分，也清楚了 JDK 8 中永久代向元空間的轉(zhuǎn)換。不過大家應(yīng)該都有一個疑問，就是為什么要做這個轉(zhuǎn)換？所以，最后給大家總結(jié)以下幾點原因：

1、字符串存在永久代中，容易出現(xiàn)性能問題和內(nèi)存溢出。

2、類及方法的信息等比較難確定其大小，因此對于永久代的大小指定比較困難，太小容易出現(xiàn)永久代溢出，太大則容易導(dǎo)致老年代溢出。

3、永久代會為 GC 帶來不必要的復(fù)雜度，并且回收效率偏低。

4、Oracle 可能會將HotSpot 與 JRockit 合二為一。

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持好吧啦網(wǎng)。