一房资、JVM 內存模型
根據(jù) JVM 規(guī)范蜕劝，JVM 內存共分為虛擬機棧、堆轰异、方法區(qū)岖沛、程序計數(shù)器、本地方法棧五個部分搭独。
1婴削、虛擬機棧：每個線程有一個私有的棧，隨著線程的創(chuàng)建而創(chuàng)建牙肝。棧里面存著的是一種叫“棧幀”的東西唉俗，每個方法會創(chuàng)建一個棧幀，棧幀中存放了局部變量表（基本數(shù)據(jù)類型和對象引用）配椭、操作數(shù)棧虫溜、方法出口等信息。棧的大小可以固定也可以動態(tài)擴展颂郎。當棧調用深度大于JVM所允許的范圍吼渡，會拋出StackOverflowError的錯誤，不過這個深度范圍不是一個恒定的值乓序，我們通過下面這段程序可以測試一下這個結果：
棧溢出測試源碼：
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
運行三次寺酪，可以看出每次棧的深度都是不一樣的，輸出結果如下替劈。
至于紅色框里的值是怎么出來的寄雀，就需要深入到 JVM 的源碼中才能探討，這里不作詳細闡述陨献。
虛擬機棧除了上述錯誤外盒犹，還有另一種錯誤，那就是當申請不到空間時眨业，會拋出 OutOfMemoryError急膀。這里有一個小細節(jié)需要注意，catch 捕獲的是?Throwable龄捡，而不是 Exception卓嫂。因為?StackOverflowError 和 OutOfMemoryError 都不屬于 Exception 的子類。
2聘殖、本地方法棧：
這部分主要與虛擬機用到的 Native 方法相關晨雳，一般情況下， Java 應用程序員并不需要關心這部分的內容奸腺。
3餐禁、PC 寄存器：
PC 寄存器，也叫程序計數(shù)器突照。JVM支持多個線程同時運行帮非，每個線程都有自己的程序計數(shù)器。倘若當前執(zhí)行的是 JVM 的方法讹蘑，則該寄存器中保存當前執(zhí)行指令的地址末盔；倘若執(zhí)行的是native 方法，則PC寄存器中為空衔肢。
4庄岖、堆
堆內存是 JVM 所有線程共享的部分，在虛擬機啟動的時候就已經創(chuàng)建角骤。所有的對象和數(shù)組都在堆上進行分配隅忿。這部分空間可通過 GC 進行回收。當申請不到空間時會拋出 OutOfMemoryError邦尊。下面我們簡單的模擬一個堆內存溢出的情況：
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
運行上述代碼背桐，輸出結果如下：
注意，這里我指定了堆內存的大小為16M蝉揍，所以這個地方顯示的count=14（這個數(shù)字不是固定的）链峭。
5、方法區(qū)：
方法區(qū)也是所有線程共享又沾。主要用于存儲類的信息弊仪、常量池熙卡、方法數(shù)據(jù)、方法代碼等励饵。方法區(qū)邏輯上屬于堆的一部分驳癌，但是為了與堆進行區(qū)分，通常又叫“非堆”役听。 關于方法區(qū)內存溢出的問題會在下文中詳細探討颓鲜。
二、PermGen（永久代）
絕大部分 Java 程序員應該都見過 "java.lang.OutOfMemoryError:?PermGen?space?"這個異常典予。這里的 “PermGen space”其實指的就是方法區(qū)甜滨。不過方法區(qū)和“PermGen space”又有著本質的區(qū)別。前者是 JVM 的規(guī)范瘤袖，而后者則是 JVM 規(guī)范的一種實現(xiàn)衣摩，并且只有 HotSpot 才有?“PermGen space”，而對于其他類型的虛擬機孽椰，如 JRockit（Oracle）昭娩、J9（IBM） 并沒有“PermGen space”。由于方法區(qū)主要存儲類的相關信息黍匾，所以對于動態(tài)生成類的情況比較容易出現(xiàn)永久代的內存溢出栏渺。最典型的場景就是，在 jsp 頁面比較多的情況锐涯，容易出現(xiàn)永久代內存溢出磕诊。我們現(xiàn)在通過動態(tài)生成類來模擬 “PermGen?space”的內存溢出：
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
運行結果如下：
本例中使用的 JDK 版本是 1.7，指定的 PermGen 區(qū)的大小為 8M纹腌。通過每次生成不同URLClassLoader對象來加載Test類霎终，從而生成不同的類對象，這樣就能看到我們熟悉的?"java.lang.OutOfMemoryError:?PermGen?space?" 異常了升薯。這里之所以采用 JDK 1.7莱褒，是因為在 JDK 1.8 中， HotSpot 已經沒有 “PermGen space”這個區(qū)間了涎劈，取而代之是一個叫做 Metaspace（元空間） 的東西广凸。下面我們就來看看 Metaspace 與 PermGen space 的區(qū)別。
三蛛枚、Metaspace（元空間）
其實谅海，移除永久代的工作從JDK1.7就開始了。JDK1.7中蹦浦，存儲在永久代的部分數(shù)據(jù)就已經轉移到了Java Heap或者是 Native Heap扭吁。但永久代仍存在于JDK1.7中，并沒完全移除，譬如符號引用(Symbols)轉移到了native heap侥袜；字面量(interned strings)轉移到了java heap蝌诡；類的靜態(tài)變量(class statics)轉移到了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ù)級不斷的生成新的字符串送漠，這樣可以比較快速的消耗內存顽照。我們通過 JDK 1.6由蘑、JDK 1.7 和 JDK 1.8 分別運行：
JDK 1.6 的運行結果：
JDK 1.7的運行結果：
JDK 1.8的運行結果：
從上述結果可以看出，JDK 1.6下代兵，會出現(xiàn)“PermGen Space”的內存溢出尼酿，而在 JDK 1.7和 JDK 1.8 中，會出現(xiàn)堆內存溢出植影，并且 JDK 1.8中 PermSize 和 MaxPermGen 已經無效裳擎。因此，可以大致驗證 JDK 1.7 和 1.8 將字符串常量由永久代轉移到堆中思币，并且 JDK 1.8 中已經不存在永久代的結論÷瓜欤現(xiàn)在我們看看元空間到底是一個什么東西？
元空間的本質和永久代類似谷饿，都是對JVM規(guī)范中方法區(qū)的實現(xiàn)惶我。不過元空間與永久代之間最大的區(qū)別在于：元空間并不在虛擬機中，而是使用本地內存博投。因此绸贡，默認情況下，元空間的大小僅受本地內存限制毅哗，但可以通過以下參數(shù)來指定元空間的大刑隆：
-XX:MetaspaceSize，初始空間大小虑绵，達到該值就會觸發(fā)垃圾收集進行類型卸載尿瞭，同時GC會對該值進行調整：如果釋放了大量的空間，就適當降低該值翅睛；如果釋放了很少的空間声搁，那么在不超過MaxMetaspaceSize時，適當提高該值宏所。
-XX:MaxMetaspaceSize酥艳，最大空間，默認是沒有限制的爬骤。
除了上面兩個指定大小的選項以外充石，還有兩個與 GC 相關的屬性：
-XX:MinMetaspaceFreeRatio，在GC之后霞玄，最小的Metaspace剩余空間容量的百分比骤铃，減少為分配空間所導致的垃圾收集
-XX:MaxMetaspaceFreeRatio拉岁，在GC之后，最大的Metaspace剩余空間容量的百分比惰爬，減少為釋放空間所導致的垃圾收集
現(xiàn)在我們在 JDK 8下重新運行一下代碼段 4喊暖，不過這次不再指定 PermSize 和 MaxPermSize。而是指定 MetaSpaceSize 和 MaxMetaSpaceSize的大小撕瞧。輸出結果如下：
從輸出結果陵叽，我們可以看出，這次不再出現(xiàn)永久代溢出丛版，而是出現(xiàn)了元空間的溢出巩掺。
四、總結
通過上面分析页畦，大家應該大致了解了 JVM 的內存劃分胖替，也清楚了 JDK 8 中永久代向元空間的轉換。不過大家應該都有一個疑問豫缨，就是為什么要做這個轉換独令？所以，最后給大家總結以下幾點原因：
1好芭、字符串存在永久代中燃箭，容易出現(xiàn)性能問題和內存溢出。
2栓撞、類及方法的信息等比較難確定其大小遍膜，因此對于永久代的大小指定比較困難，太小容易出現(xiàn)永久代溢出瓤湘，太大則容易導致老年代溢出瓢颅。
3、永久代會為 GC 帶來不必要的復雜度弛说，并且回收效率偏低挽懦。
4、Oracle 可能會將HotSpot 與 JRockit 合二為一木人。
歡迎工作一到五年的Java工程師朋友們加入Java程序員開發(fā)： 854393687
群內提供免費的Java架構學習資料（里面有高可用信柿、高并發(fā)、高性能及分布式醒第、Jvm性能調優(yōu)渔嚷、Spring源碼，MyBatis稠曼，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己形病，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼漠吻，給未來的自己一個交代量瓜！
