java內存溢出問題

相信有必定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

發生這種問題的原意是程序中使用了大量的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下，減小類的重複加載。這種方法是網上部分人推薦的，我沒試過，但感受減小不了太大的空間，最靠譜的仍是第一種方法。

第二種OutOfMemoryError：  Java heap space

發生這種問題的緣由是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。