java中三種常見內(nèi)存溢出錯(cuò)誤的處理方法

　　java虛擬機(jī)規(guī)范規(guī)定JVM的內(nèi)存分為了好幾塊，比如堆，棧，程序計(jì)數(shù)器，方法區(qū)等，而Hotspot jvm的實(shí)現(xiàn)中，將堆內(nèi)存分為了三部分，新生代，老年代，持久帶，其中持久帶實(shí)現(xiàn)了規(guī)范中規(guī)定的方法區(qū)，而內(nèi)存模型中不同的部分都會(huì)出現(xiàn)相應(yīng)的OOM錯(cuò)誤

　　相信有一定java開發(fā)經(jīng)驗(yàn)的人或多或少都會(huì)遇到OutOfMemoryError的問題，這個(gè)問題曾困擾了我很長(zhǎng)時(shí)間，隨著解決各類問題經(jīng)驗(yàn)的積累以及對(duì)問題根源的探索，終于有了一個(gè)比較深入的認(rèn)識(shí)。

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

　　第一種OutOfMemoryError： PermGen space

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

　　PermGen space的全稱是Permanent Generation space，是指內(nèi)存的永久保存區(qū)域，這塊內(nèi)存主要是被JVM存放Class和Meta信息的，Class在被Loader時(shí)就會(huì)被放到PermGen space中，它和存放類實(shí)例（Instance）的Heap區(qū)域不同，GC（Garbage Collection）不會(huì)在主程序運(yùn)行期對(duì)PermGen space進(jìn)行清理，所以如果你的應(yīng)用中有很CLASS的話，就很可能出現(xiàn)PermGen space錯(cuò)誤，這種錯(cuò)誤常見在web服務(wù)器對(duì)JSP進(jìn)行pre compile的時(shí)候。如果你的WEB APP下都用了大量的第三方j(luò)ar， 其大小超過了jvm默認(rèn)的大小（4M）那么就會(huì)產(chǎn)生此錯(cuò)誤信息了。

　　一個(gè)最佳的配置例子：（經(jīng)過本人驗(yàn)證，自從用此配置之后，再未出現(xiàn)過tomcat死掉的情況）

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

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

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

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

　　第二種OutOfMemoryError： Java heap space

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

　　注意：如果Xms超過了Xmx值，或者堆最大值和非堆最大值的總和超過了物理內(nèi)存或者操作系統(tǒng)的最大限制都會(huì)引起服務(wù)器啟動(dòng)不起來。

　　發(fā)生這種問題的原因是java虛擬機(jī)創(chuàng)建的對(duì)象太多，在進(jìn)行垃圾回收之間，虛擬機(jī)分配的到堆內(nèi)存空間已經(jīng)用滿了，與Heap space有關(guān)。解決這類問題有兩種思路：

　　1.檢查程序，看是否有死循環(huán)或不必要地重復(fù)創(chuàng)建大量對(duì)象。找到原因后，修改程序和算法。 我以前寫一個(gè)使用K-Means文本聚類算法對(duì)幾萬條文本記錄（每條記錄的特征向量大約10來個(gè)）進(jìn)行文本聚類時(shí)，由于程序細(xì)節(jié)上有問題，就導(dǎo)致了Java heap space的內(nèi)存溢出問題，后來通過修改程序得到了解決。

　　2.增加Java虛擬機(jī)中Xms（初始堆大小）和Xmx（最大堆大?。﹨?shù)的大小。如：set JAVA_OPTS= -Xms256m -Xmx1024m

　　第三種OutOfMemoryError：unable to create new native thread

　　在java應(yīng)用中，有時(shí)候會(huì)出現(xiàn)這樣的錯(cuò)誤：OutOfMemoryError： unable to create new native thread.這種怪事是因?yàn)镴VM已經(jīng)被系統(tǒng)分配了大量的內(nèi)存（比如1.5G），并且它至少要占用可用內(nèi)存的一半。有人發(fā)現(xiàn)，在線程個(gè)數(shù)很多的情況下，你分配給JVM的內(nèi)存越多，那么，上述錯(cuò)誤發(fā)生的可能性就越大。

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

　　每一個(gè)32位的進(jìn)程最多可以使用2G的可用內(nèi)存，因?yàn)榱硗?G被操作系統(tǒng)保留。這里假設(shè)使用1.5G給JVM，那么還余下500M可用內(nèi)存。這500M內(nèi)存中的一部分必須用于系統(tǒng)dll的加載，那么真正剩下的也許只有400M，現(xiàn)在關(guān)鍵的地方出現(xiàn)了：當(dāng)你使用Java創(chuàng)建一個(gè)線程，在JVM的內(nèi)存里也會(huì)創(chuàng)建一個(gè)Thread對(duì)象，但是同時(shí)也會(huì)在操作系統(tǒng)里創(chuàng)建一個(gè)真正的物理線程（參考JVM規(guī)范），操作系統(tǒng)會(huì)在余下的400兆內(nèi)存里創(chuàng)建這個(gè)物理線程，而不是在JVM的1500M的內(nèi)存堆里創(chuàng)建。在jdk1.4里頭，默認(rèn)的棧大小是256KB，但是在jdk1.5里頭，默認(rèn)的棧大小為1M每線程，因此，在余下400M的可用內(nèi)存里邊我們最多也只能創(chuàng)建400個(gè)可用線程。

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

　　給出一個(gè)有關(guān)能夠創(chuàng)建線程的最大個(gè)數(shù)的估算公式：

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

　　對(duì)于jdk1.5而言，假設(shè)操作系統(tǒng)保留120M內(nèi)存：

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

　　對(duì)于棧大小為256KB的jdk1.4而言，

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

　　對(duì)于這個(gè)異常我們首先需要判斷下，發(fā)生內(nèi)存溢出時(shí)進(jìn)程中到底都有什么樣的線程，這些線程是否是應(yīng)該存在的，是否可以通過優(yōu)化來降低線程數(shù)； 另外一方面默認(rèn)情況下java為每個(gè)線程分配的棧內(nèi)存大小是1M，通常情況下，這1M的棧內(nèi)存空間是足足夠用了，因?yàn)樵谕ǔＴ跅Ｉ洗娣诺闹皇腔A(chǔ)類型的數(shù)據(jù)或者對(duì)象的引用，這些東西都不會(huì)占據(jù)太大的內(nèi)存， 我們可以通過調(diào)整jvm參數(shù)，降低為每個(gè)線程分配的棧內(nèi)存大小來解決問題，例如在jvm參數(shù)中添加-Xss128k將線程棧內(nèi)存大小設(shè)置為128k。

　　垃圾回收GC的角色

　　JVM調(diào)用GC的頻度還是很高的，主要兩種情況下進(jìn)行垃圾回收：

　　當(dāng)應(yīng)用程序線程空閑；另一個(gè)是java內(nèi)存堆不足時(shí)，會(huì)不斷調(diào)用GC，若連續(xù)回收都解決不了內(nèi)存堆不足的問題時(shí)，就會(huì)報(bào)out of memory錯(cuò)誤。因?yàn)檫@個(gè)異常根據(jù)系統(tǒng)運(yùn)行環(huán)境決定，所以無法預(yù)期它何時(shí)出現(xiàn)。

　　根據(jù)GC的機(jī)制，程序的運(yùn)行會(huì)引起系統(tǒng)運(yùn)行環(huán)境的變化，增加GC的觸發(fā)機(jī)會(huì)。

　　為了避免這些問題，程序的設(shè)計(jì)和編寫就應(yīng)避免垃圾對(duì)象的內(nèi)存占用和GC的開銷。顯示調(diào)用System.GC（）只能建議JVM需要在內(nèi)存中對(duì)垃圾對(duì)象進(jìn)行回收，但不是必須馬上回收，

　　一個(gè)是并不能解決內(nèi)存資源耗空的局面，另外也會(huì)增加GC的消耗