Java程序員沒有遇到過OutOfMemory簡直就是不可能的事情！
可見在Java的世界中，太多的不確定因素導致Java運行程序直接崩潰，直接拋出OutOfMemory異常，而一旦遇到了這個問題，調查起來就非常的困難。在JDK 5.0以前，OutOfMemory只有這麼一句話： java.lang.OutOfMemory Exception…基本上無從下手，無從分析。從JDK 5.0以後對OutOfMemory增加了許多的詳細說明，爲這個異常的分析提供了很大的便利。
這次遇到的問題就是會拋出OutOfMemory:PermGen Space的異常，這個異常非常有意思，根據【此文章】的描述，這是一個Sun JVM的bug，從2003年開始，一隻到現在都沒有解決。而且提出來的解決方案是使用JRockit。Bug產生的原因已經找到，就是因爲JVM在分配PermGen Space的時候出現了PermGen Space不足的情況，默認情況下 PermGen的大小爲64M，在不換用JRockit的情況下，可以在啓動JVM的時候添加一個參數： -XX: MaxPermSize= 128m| 256m| 512m。
那麼究竟什麼是PermGen呢？
PermGen 原來是指Permanent Generation，本身是在Java的垃圾收集機制（GC）中產生的一個概念。Java的垃圾收集機制最早只是遍歷所有的對象，如果發現某個對象沒有被引用，則回收，這是在早期的Java 1.0和Java 1.1的時候的GC規則。慢慢的，這樣一種“愚蠢的”GC算法成爲了JVM性能的瓶頸，在擁有大量數據的Java應用程序中，GC的算法被高度強化，於是各種各樣高效的JVM GC算法被髮展了起來。從J2SE也就是Java 1.2開始，JVM引入了多種GC算法，其中一種用的非常多的就是Generational Collection，中文也叫做“分代收集法”。
分代收集法擯棄了對所有對象的遍歷，而是採用一些經驗屬性去避免額外的工作（While naive garbage collection examines every live object in the heap, generational collection exploits several empirically observed properties of most applications to avoid extra work）。其中導入了一個非常關鍵的概念：infant mortality （幼兒死亡率），這表示越是新生成的變量或者對象，越容易被收集。下面一張圖表示了對象的生命週期，橫軸表示的是測試到對象的生命週期，縱軸表示在一個指定的生命週期上被回收的對象數量。
可以看到，在使用了分代收集法以後，年輕一代的對象被收集的比例最高。並且在內存中的對象會按照不同的“年齡”來劃分，當一個年齡段的對象滿了以後，在這個年齡段上就會發生垃圾收集，從最年輕的一代開始，一直到“永生代”，在內存中，所有的對象可以劃分爲很多代，最後的一代“永生代”就是“Permanent Generation”，這裏就是直接引出“Permanent Generation”概念的地方。具體可以參考下圖：
根據前面所說的情況，在分代垃圾收集的情況下會產生Permanent Generation的概念，而這個分代垃圾收集法是並行收集和併發收集的基礎，所以Permanent Generation會一直存在，那麼這個Permanent Generation究竟是做什麼用的呢？這裏保存了JVM中所有對象的類信息，包括類的元數據，還有方法描述等等，所以這一代內存垃圾收集算法是不一樣的，在Java大程序的情況下，尤其是J2EE 或者說Java EE的大型應用程序上，Permanent Generation的大小會直接限定能載入類的數量和大小。
【解決辦法】就是設定JVM啓動的時候參數，可以如下設置：
java -XX: PermSize=64m -XX: MaxPermSize=128m
另外PermSize 和MaxPermSize如果設置爲相同還可以在一定程度上提高性能，因爲，PermSize在不斷的變化中會需要轉移其中的數據。如果固定了以後，則可以減少每次擴大PermSize帶來的性能損失。
更多的請參考 【Java官方站點】
另外，還可以在Java啓動的時候添加下面的參數來看GC的運行情況：
Java -verbosegc