很多開發者都在其系統中見過“java.lang.OutOfMemoryError: PermGen space”這一問題。這往往是由類加載器相關的內存泄漏以及新類加載器的創建導致的，通常出現于代碼熱部署時。相對于正式產品，該問題在開發機上出現的頻率更高，在產品中最常見的“問題”是默認值太低了。常用的解決方法是將其設置為256MB或更高。
PermGen space簡單介紹
PermGen space的全稱是Permanent Generation space,是指內存的***保存區域，說說為什么會內存益出：這一部分用于存放Class和Meta的信息,Class在被 Load的時候被放入PermGen space區域，它和和存放Instance的Heap區域不同,所以如果你的APP會LOAD很多CLASS的話,就很可能出現PermGen space錯誤。這種錯誤常見在web服務器對JSP進行pre compile的時候。
JVM 種類有很多，比如 Oralce-Sun Hotspot, Oralce JRockit, IBM J9, Taobao JVM（淘寶好樣的！）等等。當然武林盟主是Hotspot了，這個毫無爭議。需要注意的是，PermGen space是Oracle-Sun Hotspot才有，JRockit以及J9是沒有這個區域。
元空間（MetaSpace）一種新的內存空間誕生
JDK8 HotSpot JVM 將移除***區，使用本地內存來存儲類元數據信息并稱之為：元空間（Metaspace）；這與Oracle JRockit 和IBM JVM’s很相似，如下圖所示
這 意味著不會再有java.lang.OutOfMemoryError: PermGen問題，也不再需要你進行調優及監控內存空間的使用……但請等等，這么說還為時過早。在默認情況下，這些改變是透明的，接下來我們的展示將使 你知道仍然要關注類元數據內存的占用。請一定要牢記，這個新特性也不能神奇地消除類和類加載器導致的內存泄漏。
java8中metaspace總結如下：
PermGen 空間的狀況
這部分內存空間將全部移除。
JVM的參數：PermSize 和 MaxPermSize 會被忽略并給出警告（如果在啟用時設置了這兩個參數）。
Metaspace 內存分配模型
大部分類元數據都在本地內存中分配。
用于描述類元數據的“klasses”已經被移除。
Metaspace 容量
默認情況下，類元數據只受可用的本地內存限制（容量取決于是32位或是64位操作系統的可用虛擬內存大小）。
新參數（MaxMetaspaceSize）用于限制本地內存分配給類元數據的大小。如果沒有指定這個參數，元空間會在運行時根據需要動態調整。
Metaspace 垃圾回收
對于僵死的類及類加載器的垃圾回收將在元數據使用達到“MaxMetaspaceSize”參數的設定值時進行。
適時地監控和調整元空間對于減小垃圾回收頻率和減少延時是很有必要的。持續的元空間垃圾回收說明，可能存在類、類加載器導致的內存泄漏或是大小設置不合適。
Java 堆內存的影響
一些雜項數據已經移到Java堆空間中。升級到JDK8之后，會發現Java堆 空間有所增長。
Metaspace 監控
元空間的使用情況可以從HotSpot1.8的詳細GC日志輸出中得到。
Jstat 和 JVisualVM兩個工具，在使用b75版本進行測試時，已經更新了，但是還是能看到老的PermGen空間的出現。
前面已經從理論上充分說明，下面讓我們通過“泄漏”程序進行新內存空間的觀察……
#p#
PermGen vs. Metaspace 運行時比較
為了更好地理解Metaspace內存空間的運行時行為，
將進行以下幾種場景的測試：
-
使用JDK1.7運行Java程序，監控并耗盡默認設定的85MB大小的PermGen內存空間。
-
使用JDK1.8運行Java程序，監控新Metaspace內存空間的動態增長和垃圾回收過程。
-
使用JDK1.8運行Java程序，模擬耗盡通過“MaxMetaspaceSize”參數設定的128MB大小的Metaspace內存空間。
首先建立了一個模擬PermGen OOM的代碼
| 2 |
public void method(String name) { |
上面是一個簡單的ClassA，把他編譯成class字節碼放到D：/classes下面，測試代碼中用URLClassLoader來加載此類型上面類編譯成class
| 05 |
public class OOMTest { |
| 06 |
public static void main(String[] args) { |
| 09 |
URL url = new File("D:/classes").toURI().toURL(); |
| 12 |
ClassLoadingMXBean loadingBean = ManagementFactory.getClassLoadingMXBean(); |
| 14 |
List<ClassLoader> classLoaders = new ArrayList<ClassLoader>(); |
| 17 |
ClassLoader classLoader = new URLClassLoader(urls); |
| 18 |
classLoaders.add(classLoader); |
| 19 |
classLoader.loadClass("ClassA"); |
| 20 |
//顯示數量信息（共加載過的類型數目，當前還有效的類型數目，已經被卸載的類型數目） |
| 21 |
System.out.println("total: " + loadingBean.getTotalLoadedClassCount()); |
| 22 |
System.out.println("active: " + loadingBean.getLoadedClassCount()); |
| 23 |
System.out.println("unloaded: " + loadingBean.getUnloadedClassCount()); |
| 25 |
} catch (Exception e) { |
虛擬機器參數設置如下：-verbose -verbose:gc
設置-verbose參數是為了獲取類型加載和卸載的信息
設置-verbose:gc是為了獲取垃圾收集的相關信息
JDK 1.7 @64-bit – PermGen 耗盡測試
Java1.7的PermGen默認空間為85 MB（或者可以通過-XX:MaxPermSize=XXXm指定）
可以從上面的JVisualVM的截圖看出：當加載超過6萬個類之后，PermGen被耗盡。我們也能通過程序和GC的輸出觀察耗盡的過程。
程序輸出(摘取了部分)
| 02 |
[Loaded ClassA from file:/D:/classes/] |
| 06 |
[GC 245041K->213978K(536768K), 0.0597188 secs] |
| 07 |
[Full GC 213978K->211425K(644992K), 0.6456638 secs] |
| 08 |
[GC 211425K->211425K(656448K), 0.0086696 secs] |
| 09 |
[Full GC 211425K->211411K(731008K), 0.6924754 secs] |
| 10 |
[GC 211411K->211411K(726528K), 0.0088992 secs] |
| 12 |
java.lang.OutOfMemoryError: PermGen space |
JDK 1.8 @64-bit – Metaspace大小動態調整測試
Java的Metaspace空間：不受限制 （默認）
從 上面的截圖可以看到，JVM Metaspace進行了動態擴展，本地內存的使用由20MB增長到646MB，以滿足程序中不斷增長的類數據內存占用需求。我們也能觀察到JVM的垃圾 回收事件—試圖銷毀僵死的類或類加載器對象。但是，由于我們程序的泄漏，JVM別無選擇只能動態擴展Metaspace內存空間。程序加載超過10萬個 類，而沒有出現OOM事件。
JDK 1.8 @64-bit – Metaspace 受限測試
Java的Metaspace空間：128MB（-XX:MaxMetaspaceSize=128m）
可 以從上面的JVisualVM的截圖看出：當加載超過2萬個類之后，Metaspace被耗盡；與JDK1.7運行時非常相似。我們也能通過程序和GC的 輸出觀察耗盡的過程。另一個有趣的現象是，保留的原生內存占用量是設定的***大小兩倍之多。這可能表明，如果可能的話，可微調元空間容量大小策略，來避免 本地內存的浪費。
從Java程序的輸出中看到如下異常。
| 1 |
[Loaded ClassA from file:/D:/classes/] |
| 5 |
[GC (Metadata GC Threshold) 64306K->57010K(111616K), 0.0145502 secs] |
| 6 |
[Full GC (Metadata GC Threshold) 57010K->56810K(122368K), 0.1068084 secs] |
| 7 |
java.lang.OutOfMemoryError: Metaspace |
在 設置了MaxMetaspaceSize的情況下，該空間的內存仍然會耗盡，進而引發“java.lang.OutOfMemoryError: Metadata space”錯誤。因為類加載器的泄漏仍然存在，而通常Java又不希望無限制地消耗本機內存，因此設置一個類似于MaxPermSize的限制看起來也 是合理的。
總結
-
之前不管是不是需要，JVM都會吃掉那塊空間……如果設置得太小，JVM會死掉；如果設置得太大，這塊內存就被JVM浪費了。理論上說，現在你完全可以不關注這個，因為JVM會在運行時自動調校為“合適的大小”；
-
提高Full GC的性能，在Full GC期間，Metadata到Metadata pointers之間不需要掃描了，別小看這幾納秒時間；
-
隱患就是如果程序存在內存泄露，像OOMTest那樣，不停的擴展metaspace的空間，會導致機器的內存不足，所以還是要有必要的調試和監控。
本文鏈接：http://my.oschina.net/roll1987/blog/220412
