一、內存溢出的定義和原因

定義

內(nei)(nei)(nei)存(cun)(cun)(cun)溢出是指應用系統中存(cun)(cun)(cun)在無法回(hui)收(shou)的(de)(de)(de)(de)(de)內(nei)(nei)(nei)存(cun)(cun)(cun)或使(shi)(shi)用的(de)(de)(de)(de)(de)內(nei)(nei)(nei)存(cun)(cun)(cun)過多，最(zui)(zui)終使(shi)(shi)得程(cheng)序(xu)運行(xing)要用到(dao)的(de)(de)(de)(de)(de)內(nei)(nei)(nei)存(cun)(cun)(cun)大(da)于虛(xu)擬機能提供的(de)(de)(de)(de)(de)最(zui)(zui)大(da)內(nei)(nei)(nei)存(cun)(cun)(cun)。為了解(jie)決Java中內(nei)(nei)(nei)存(cun)(cun)(cun)溢出問題(ti)，我們首先(xian)必須了解(jie)Java是如何管(guan)理(li)內(nei)(nei)(nei)存(cun)(cun)(cun)的(de)(de)(de)(de)(de)。Java的(de)(de)(de)(de)(de)內(nei)(nei)(nei)存(cun)(cun)(cun)管(guan)理(li)就(jiu)是對(dui)象的(de)(de)(de)(de)(de)分配和釋(shi)放問題(ti)。在Java中，內(nei)(nei)(nei)存(cun)(cun)(cun)的(de)(de)(de)(de)(de)分配是由(you)程(cheng)序(xu)完成的(de)(de)(de)(de)(de)，而內(nei)(nei)(nei)存(cun)(cun)(cun)的(de)(de)(de)(de)(de)釋(shi)放是由(you)垃圾(ji)收(shou)集器(GarbageCollection，GC)完成的(de)(de)(de)(de)(de)，程(cheng)序(xu)員不(bu)需要通過調用GC函數來釋(shi)放內(nei)(nei)(nei)存(cun)(cun)(cun)，因為不(bu)同(tong)(tong)的(de)(de)(de)(de)(de)JVM實(shi)現者可(ke)能使(shi)(shi)用不(bu)同(tong)(tong)的(de)(de)(de)(de)(de)算(suan)法管(guan)理(li)GC，有(you)的(de)(de)(de)(de)(de)是內(nei)(nei)(nei)存(cun)(cun)(cun)使(shi)(shi)用到(dao)達一(yi)(yi)定程(cheng)度時，GC才開(kai)始工作，也有(you)定時執行(xing)的(de)(de)(de)(de)(de)，有(you)的(de)(de)(de)(de)(de)是中斷式(shi)執行(xing)GC。但(dan)GC只能回(hui)收(shou)無用并且不(bu)再被其它對(dui)象引(yin)用的(de)(de)(de)(de)(de)那些對(dui)象所占用的(de)(de)(de)(de)(de)空(kong)間。Java的(de)(de)(de)(de)(de)內(nei)(nei)(nei)存(cun)(cun)(cun)垃圾(ji)回(hui)收(shou)機制是從程(cheng)序(xu)的(de)(de)(de)(de)(de)主(zhu)要運行(xing)對(dui)象開(kai)始檢查引(yin)用鏈，當遍歷(li)一(yi)(yi)遍后發現沒有(you)被引(yin)用的(de)(de)(de)(de)(de)孤(gu)立對(dui)象就(jiu)作為垃圾(ji)回(hui)收(shou)。

該圖片由注冊用戶"溫暖·生活家"提供，版權聲明反饋

原因

1、內(nei)存中加載的數(shu)(shu)據(ju)(ju)量過于龐(pang)大，如一次從數(shu)(shu)據(ju)(ju)庫取出(chu)過多(duo)數(shu)(shu)據(ju)(ju)。

2、集合類中有對(dui)對(dui)象的引(yin)用，使(shi)用完(wan)后未清(qing)空(kong)，使(shi)得JVM不能回收。

3、代碼中存在死(si)循環(huan)或循環(huan)產生過(guo)多重復的對(dui)象實體。

4、使用的(de)(de)第三(san)方軟件中的(de)(de)BUG。

5、啟動參數設(she)定的過小。

二、內存溢出的解決問題

第一(yi)步，就是修改JVM啟動參(can)數，直接增加內(nei)存。這一(yi)點(dian)看上去似乎(hu)很(hen)簡(jian)單，但很(hen)容易被(bei)忽略。JVM默(mo)認(ren)可以使(shi)用(yong)的內(nei)存為(wei)(wei)(wei)64M，Tomcat默(mo)認(ren)可以使(shi)用(yong)的內(nei)存為(wei)(wei)(wei)128MB，對(dui)于稍復雜一(yi)點(dian)的系統就會不夠用(yong)。在某(mou)項目中，就因為(wei)(wei)(wei)啟動參(can)數使(shi)用(yong)的默(mo)認(ren)值(zhi)，經常(chang)報“OutOfMemory”錯誤。因此，-Xms，-Xmx參(can)數一(yi)定不要忘記加。

第二步，檢查(cha)錯(cuo)誤(wu)日志，查(cha)看“OutOfMemory”錯(cuo)誤(wu)前是(shi)否有(you)(you)(you)其它(ta)異常或錯(cuo)誤(wu)。在一個(ge)項目中(zhong)，使(shi)(shi)(shi)用(yong)兩(liang)個(ge)數(shu)據(ju)(ju)庫(ku)(ku)(ku)連(lian)(lian)(lian)(lian)接(jie)(jie)(jie)，其中(zhong)專(zhuan)用(yong)于發(fa)送短信的(de)(de)(de)數(shu)據(ju)(ju)庫(ku)(ku)(ku)連(lian)(lian)(lian)(lian)接(jie)(jie)(jie)使(shi)(shi)(shi)用(yong)DBCP連(lian)(lian)(lian)(lian)接(jie)(jie)(jie)池管(guan)理，用(yong)戶為(wei)不(bu)將短信發(fa)出(chu)，有(you)(you)(you)意(yi)將數(shu)據(ju)(ju)庫(ku)(ku)(ku)連(lian)(lian)(lian)(lian)接(jie)(jie)(jie)用(yong)戶名改錯(cuo)，使(shi)(shi)(shi)得日志中(zhong)有(you)(you)(you)許多數(shu)據(ju)(ju)庫(ku)(ku)(ku)連(lian)(lian)(lian)(lian)接(jie)(jie)(jie)異常的(de)(de)(de)日志，一段時(shi)間后，就出(chu)現“OutOfMemory”錯(cuo)誤(wu)。經分析(xi)，這是(shi)由于DBCP連(lian)(lian)(lian)(lian)接(jie)(jie)(jie)池BUG引起的(de)(de)(de)，數(shu)據(ju)(ju)庫(ku)(ku)(ku)連(lian)(lian)(lian)(lian)接(jie)(jie)(jie)不(bu)上后，沒有(you)(you)(you)將連(lian)(lian)(lian)(lian)接(jie)(jie)(jie)釋放，最終使(shi)(shi)(shi)得DBCP報“OutOfMemory”錯(cuo)誤(wu)。經過(guo)修改正確數(shu)據(ju)(ju)庫(ku)(ku)(ku)連(lian)(lian)(lian)(lian)接(jie)(jie)(jie)參數(shu)后，就沒有(you)(you)(you)再出(chu)現內存(cun)溢(yi)出(chu)的(de)(de)(de)錯(cuo)誤(wu)。

查看(kan)日(ri)志對于(yu)分析(xi)內存(cun)溢出是非常重要的，通過仔細查看(kan)日(ri)志，分析(xi)內存(cun)溢出前做過哪(na)些操作(zuo)，可以大致定位有問題的模塊。

第三步，安(an)排(pai)有(you)經(jing)驗(yan)的編程人員(yuan)對代(dai)碼進行走查(cha)和分析，找出(chu)(chu)可能發生內(nei)存(cun)溢出(chu)(chu)的位(wei)置。重點排(pai)查(cha)以下幾點：

1、檢查(cha)代碼中是否(fou)有(you)死循環(huan)或(huo)遞歸(gui)調用。

2、檢查是否有大循環重復產生新對象實(shi)體(ti)。

3、檢(jian)查(cha)對(dui)數據(ju)(ju)庫查(cha)詢(xun)中(zhong)，是否有一(yi)次獲得全部數據(ju)(ju)的查(cha)詢(xun)。一(yi)般來(lai)說，如果一(yi)次取十(shi)萬(wan)條記錄到內(nei)存，就可(ke)能引(yin)起(qi)內(nei)存溢(yi)出。這個問(wen)題比(bi)較隱蔽，在上線(xian)前(qian)，數據(ju)(ju)庫中(zhong)數據(ju)(ju)較少(shao)，不(bu)容易出問(wen)題，上線(xian)后，數據(ju)(ju)庫中(zhong)數據(ju)(ju)多了，一(yi)次查(cha)詢(xun)就有可(ke)能引(yin)起(qi)內(nei)存溢(yi)出。因此對(dui)于數據(ju)(ju)庫查(cha)詢(xun)盡量(liang)采用分頁的方式查(cha)詢(xun)。

4、檢(jian)查List、MAP等集(ji)合對象(xiang)(xiang)是否有使(shi)用完(wan)后，未清(qing)除的(de)問題。List、MAP等集(ji)合對象(xiang)(xiang)會始(shi)終存有對對象(xiang)(xiang)的(de)引用，使(shi)得這些(xie)對象(xiang)(xiang)不(bu)能被(bei)GC回收。

第四步，使用(yong)內(nei)(nei)(nei)存(cun)查(cha)(cha)看(kan)工具(ju)動(dong)態(tai)查(cha)(cha)看(kan)內(nei)(nei)(nei)存(cun)使用(yong)情(qing)況。某(mou)個(ge)項目上(shang)線后，每(mei)次系統(tong)啟動(dong)兩天后，就會(hui)出(chu)(chu)現內(nei)(nei)(nei)存(cun)溢出(chu)(chu)的(de)錯誤。這種情(qing)況一般是代碼中出(chu)(chu)現了(le)緩慢的(de)內(nei)(nei)(nei)存(cun)泄漏(lou)，用(yong)上(shang)面三個(ge)步驟解決不了(le)，這就需要使用(yong)內(nei)(nei)(nei)存(cun)查(cha)(cha)看(kan)工具(ju)了(le)。

內存查看工具有許多，比較有名的有：Optimizeit Profiler、JProbeProfiler、JinSight和Java1.5的Jconsole等。它們的基本工作原理大同小異，都是監測Java程序運行時所有對象的申請、釋放等動作，將內存管理的所有信息進(jin)行(xing)統(tong)計、分析、可視(shi)化(hua)。開發人員可以根據這些(xie)信息判斷程序是(shi)否有內(nei)(nei)存泄(xie)漏問題。一般(ban)來說，一個正常的(de)(de)(de)系(xi)統(tong)在(zai)(zai)其啟(qi)動完(wan)成后其內(nei)(nei)存的(de)(de)(de)占用(yong)(yong)量是(shi)基本穩定的(de)(de)(de)，而(er)不應該是(shi)無限(xian)制的(de)(de)(de)增長的(de)(de)(de)。持(chi)續地觀察系(xi)統(tong)運行(xing)時(shi)(shi)使用(yong)(yong)的(de)(de)(de)內(nei)(nei)存的(de)(de)(de)大小，可以看到(dao)在(zai)(zai)內(nei)(nei)存使用(yong)(yong)監控窗口中(zhong)(zhong)是(shi)基本規則的(de)(de)(de)鋸齒(chi)形的(de)(de)(de)圖線(xian)，如(ru)果內(nei)(nei)存的(de)(de)(de)大小持(chi)續地增長，則說明系(xi)統(tong)存在(zai)(zai)內(nei)(nei)存泄(xie)漏問題。通過間隔一段(duan)時(shi)(shi)間取一次內(nei)(nei)存快(kuai)(kuai)照，然后對內(nei)(nei)存快(kuai)(kuai)照中(zhong)(zhong)對象的(de)(de)(de)使用(yong)(yong)與引用(yong)(yong)等信息進(jin)行(xing)比對與分析，可以找出是(shi)哪個類的(de)(de)(de)對象在(zai)(zai)泄(xie)漏。

通過以上四(si)個(ge)步驟(zou)的分(fen)析與處理，基本(ben)能處理內存溢出的問題(ti)。當(dang)然，在這些過程中(zhong)也需(xu)要相(xiang)當(dang)的經驗與敏感(gan)度，需(xu)要在實際的開發與調試(shi)過程中(zhong)不(bu)斷積累。