java中三種常見內存溢出錯誤的處理方法

　　java虛擬機規范規定JVM的內存分為了好幾塊，比如堆，棧，程序計數器，方法區等，而Hotspot jvm的實現中，將堆內存分為了三部分，新生代，老年代，持久帶，其中持久帶實現了規范中規定的方法區，而內存模型中不同的部分都會出現相應的OOM錯誤

　　相信有一定java開發經驗的人或多或少都會遇到OutOfMemoryError的問題，這個問題曾困擾了我很長時間，隨著解決各類問題經驗的積累以及對問題根源的探索，終于有了一個比較深入的認識。

　　在解決java內存溢出問題之前，需要對jvm（java虛擬機）的內存管理有一定的認識。jvm管理的內存大致包括三種不同類型的內存區域：Permanent Generation space（永久保存區域）、Heap space（堆區域）、Java Stacks（Java棧）。其中永久保存區域主要存放Class（類）和Meta的信息，Class第一次被Load的時候被放入PermGen space區域，Class需要存儲的內容主要包括方法和靜態屬性。堆區域用來存放Class的實例（即對象），對象需要存儲的內容主要是非靜態屬性。每次用new創建一個對象實例后，對象實例存儲在堆區域中，這部分空間也被jvm的垃圾回收機制管理。而Java棧跟大多數編程語言包括匯編語言的棧功能相似，主要基本類型變量以及方法的輸入輸出參數。Java程序的每個線程中都有一個獨立的堆棧。容易發生內存溢出問題的內存空間包括：Permanent Generation space和Heap space。

　　第一種OutOfMemoryError： PermGen space

　　JVM管理兩種類型的內存，堆和非堆。堆是給開發人員用的上面說的就是，是在JVM啟動時創建；非堆是留給JVM自己用的，用來存放類的信息的。它和堆不同，運行期內GC不會釋放空間。如果web app用了大量的第三方jar或者應用有太多的class文件而恰好MaxPermSize設置較小，超出了也會導致這塊內存的占用過多造成溢出，或者tomcat熱部署時侯不會清理前面加載的環境，只會將context更改為新部署的，非堆存的內容就會越來越多。

　　PermGen space的全稱是Permanent Generation space，是指內存的永久保存區域，這塊內存主要是被JVM存放Class和Meta信息的，Class在被Loader時就會被放到PermGen space中，它和存放類實例（Instance）的Heap區域不同，GC（Garbage Collection）不會在主程序運行期對PermGen space進行清理，所以如果你的應用中有很CLASS的話，就很可能出現PermGen space錯誤，這種錯誤常見在web服務器對JSP進行pre compile的時候。如果你的WEB APP下都用了大量的第三方jar，其大小超過了jvm默認的大小（4M）那么就會產生此錯誤信息了。

　　一個最佳的配置例子：（經過本人驗證，自從用此配置之后，再未出現過tomcat死掉的情況）

　　set JAVA_OPTS=-Xms800m -Xmx800m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m

　　發生這種問題的原意是程序中使用了大量的jar或class，使java虛擬機裝載類的空間不夠，與Permanent Generation space有關。解決這類問題有以下兩種辦法：

　　1.增加java虛擬機中的XX:PermSize和XX:MaxPermSize參數的大小，其中XX:PermSize是初始永久保存區域大小，XX:MaxPermSize是最大永久保存區域大小。如針對tomcat6.0，在catalina.sh 或catalina.bat文件中一系列環境變量名說明結束處（大約在70行左右）增加一行： JAVA_OPTS=“ -XX:PermSize=64M -XX:MaxPermSize=128m” 如果是windows服務器還可以在系統環境變量中設置。感覺用tomcat發布sprint+struts+hibernate架構的程序時很容易發生這種內存溢出錯誤。使用上述方法，我成功解決了部署ssh項目的tomcat服務器經常宕機的問題。

　　2.清理應用程序中web-inf/lib下的jar，如果tomcat部署了多個應用，很多應用都使用了相同的jar，可以將共同的jar移到tomcat共同的lib下，減少類的重復加載。這種方法是網上部分人推薦的，我沒試過，但感覺減少不了太大的空間，最靠譜的還是第一種方法。

　 java中三種常見內存溢出錯誤的處理方法

　　第二種OutOfMemoryError： Java heap space

　　第一種情況是個補充，主要存在問題就是出現在這個情況中。其默認空間（即-Xms）是物理內存的1/64，最大空間（-Xmx）是物理內存的1/4。如果內存剩余不到40％，JVM就會增大堆到Xmx設置的值，內存剩余超過70％，JVM就會減小堆到Xms設置的值。所以服務器的Xmx和Xms設置一般應該設置相同避免每次GC后都要調整虛擬機堆的大小。假設物理內存無限大，那么JVM內存的最大值跟操作系統有關，一般32位機是1.5g到3g之間，而64位的就不會有限制了。

　　注意：如果Xms超過了Xmx值，或者堆最大值和非堆最大值的總和超過了物理內存或者操作系統的最大限制都會引起服務器啟動不起來。

　　發生這種問題的原因是java虛擬機創建的對象太多，在進行垃圾回收之間，虛擬機分配的到堆內存空間已經用滿了，與Heap space有關。解決這類問題有兩種思路：

　　1.檢查程序，看是否有死循環或不必要地重復創建大量對象。找到原因后，修改程序和算法。我以前寫一個使用K-Means文本聚類算法對幾萬條文本記錄（每條記錄的特征向量大約10來個）進行文本聚類時，由于程序細節上有問題，就導致了Java heap space的內存溢出問題，后來通過修改程序得到了解決。

　　2.增加Java虛擬機中Xms（初始堆大小）和Xmx（最大堆大小）參數的大小。如：set JAVA_OPTS= -Xms256m -Xmx1024m

　　第三種OutOfMemoryError：unable to create new native thread

　　在java應用中，有時候會出現這樣的錯誤：OutOfMemoryError： unable to create new native thread.這種怪事是因為JVM已經被系統分配了大量的內存（比如1.5G），并且它至少要占用可用內存的一半。有人發現，在線程個數很多的情況下，你分配給JVM的內存越多，那么，上述錯誤發生的可能性就越大。

　　那么是什么原因造成這種問題呢？

　　每一個32位的進程最多可以使用2G的可用內存，因為另外2G被操作系統保留。這里假設使用1.5G給JVM，那么還余下500M可用內存。這500M內存中的一部分必須用于系統dll的加載，那么真正剩下的也許只有400M，現在關鍵的地方出現了：當你使用Java創建一個線程，在JVM的內存里也會創建一個Thread對象，但是同時也會在操作系統里創建一個真正的物理線程（參考JVM規范），操作系統會在余下的400兆內存里創建這個物理線程，而不是在JVM的1500M的內存堆里創建。在jdk1.4里頭，默認的棧大小是256KB，但是在jdk1.5里頭，默認的棧大小為1M每線程，因此，在余下400M的可用內存里邊我們最多也只能創建400個可用線程。

　　這樣結論就出來了，要想創建更多的線程，你必須減少分配給JVM的最大內存。還有一種做法是讓JVM宿主在你的JNI代碼里邊。

　　給出一個有關能夠創建線程的最大個數的估算公式：

　　（MaxProcessMemory - JVMMemory - ReservedOsMemory） / （ThreadStackSize） = Number of threads

　　對于jdk1.5而言，假設操作系統保留120M內存：

　　1.5GB JVM：（2GB-1.5Gb-120MB）/（1MB） = ~380 threads 1.0GB JVM：（2GB-1.0Gb-120MB）/（1MB） = ~880 threads

　　對于棧大小為256KB的jdk1.4而言，

　　1.5GB allocated to JVM： ~1520 threads 1.0GB allocated to JVM： ~3520 threads

　　對于這個異常我們首先需要判斷下，發生內存溢出時進程中到底都有什么樣的線程，這些線程是否是應該存在的，是否可以通過優化來降低線程數；另外一方面默認情況下java為每個線程分配的棧內存大小是1M，通常情況下，這1M的棧內存空間是足足夠用了，因為在通常在棧上存放的只是基礎類型的數據或者對象的引用，這些東西都不會占據太大的內存，我們可以通過調整jvm參數，降低為每個線程分配的棧內存大小來解決問題，例如在jvm參數中添加-Xss128k將線程棧內存大小設置為128k。