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