幾個常見的jvm問題，總結的比較好，搬來借鑒。

1. java.lang.OutOfMemoryError:Javaheap space ----JVM Heap（堆）溢出JVM在啟動的時候會自動設置JVM Heap的值，其初始空間(即-Xms)是物理內存的1/64，最大空間(-Xmx)不可超過物理內存。

可以利用JVM提供的-Xmn -Xms -Xmx等選項可進行設置。Heap的大小是Young Generation 和Tenured Generaion 之和。

在JVM中如果98％的時間是用于GC，且可用的Heap size 不足2％的時候將拋出此異常信息。

解決方法：手動設置JVM Heap（堆）的大小。  

2. java.lang.OutOfMemoryError: PermGen space  ---- PermGen space溢出。 PermGen space的全稱是Permanent Generation space，是指內存的永久保存區域。

為什么會內存溢出，這是由于這塊內存主要是被JVM存放Class和Meta信息的，Class在被Load的時候被放入PermGen space區域，它和存放Instance的Heap區域不同,sun的 GC不會在主程序運行期對PermGen space進行清理，所以如果你的APP會載入很多CLASS的話，就很可能出現PermGen space溢出。

解決方法： 手動設置MaxPermSize大小

3. java.lang.StackOverflowError   ---- 棧溢出棧溢出了，JVM依然是采用棧式的虛擬機，這個和C和Pascal都是一樣的。函數的調用過程都體現在堆棧和退棧上了。調用構造函數的 “層”太多了，以致于把棧區溢出了。通常來講，一般棧區遠遠小于堆區的，因為函數調用過程往往不會多于上千層，而即便每個函數調用需要 1K的空間(這個大約相當于在一個C函數內聲明了256個int類型的變量)，那么棧區也不過是需要1MB的空間。通常棧的大小是1－2MB的。通常遞歸也不要遞歸的層次過多，很容易溢出。

解決方法：修改程序。

jvm參數說明：

-server:一定要作為第一個參數，在多個CPU時性能佳 -Xms：java Heap初始大小。 默認是物理內存的1/64。-Xmx：java heap最大值。建議均設為物理內存的一半。不可超過物理內存。

-XX:PermSize:設定內存的永久保存區初始大小，缺省值為64M。（我用visualvm.exe查看的）

-XX:MaxPermSize:設定內存的永久保存區最大 大小，缺省值為64M。（我用visualvm.exe查看的）

-XX:SurvivorRatio=2  :生還者池的大小,默認是2，如果垃圾回收變成了瓶頸，您可以嘗試定制生成池設置

-XX:NewSize: 新生成的池的初始大小。 缺省值為2M。

-XX:MaxNewSize: 新生成的池的最大大小。   缺省值為32M。

如果 JVM 的堆大小大于 1GB，則應該使用值：-XX:newSize=640m -XX:MaxNewSize=640m -XX:SurvivorRatio=16，或者將堆的總大小的 50% 到 60% 分配給新生成的池。調大新對象區，減少Full GC次數。

 +XX:AggressiveHeap 會使得 Xms沒有意義。這個參數讓jvm忽略Xmx參數,瘋狂地吃完一個G物理內存,再吃盡一個G的swap。

-Xss：每個線程的Stack大小，“-Xss 15120” 這使得JBoss每增加一個線程（thread)就會立即消耗15M內存，而最佳值應該是128K,默認值好像是512k. -verbose:gc 現實垃圾收集信息 -Xloggc:gc.log 指定垃圾收集日志文件 -Xmn：young generation的heap大小，一般設置為Xmx的3、4分之一 -XX:+UseParNewGC ：縮短minor收集的時間 -XX:+UseConcMarkSweepGC ：縮短major收集的時間 此選項在Heap Size 比較大而且Major收集時間較長的情況下使用更合適。

-XX:userParNewGC 可用來設置并行收集【多CPU】-XX:ParallelGCThreads 可用來增加并行度【多CPU】-XX:UseParallelGC 設置后可以使用并行清除收集器【多CPU】

【原創】原創文章，更多關注敬請關注微信公眾號。