java內(nèi)存溢出排查方法解析

　　內(nèi)存溢出（out of memory），通俗理解就是內(nèi)存不夠，通常在運(yùn)行大型軟件或游戲時(shí)，軟件或游戲所需要的內(nèi)存遠(yuǎn)遠(yuǎn)超出了你主機(jī)內(nèi)安裝的內(nèi)存所承受大小，就叫內(nèi)存溢出。此時(shí)軟件或游戲就運(yùn)行不了，系統(tǒng)會(huì)提示內(nèi)存溢出，有時(shí)候會(huì)自動(dòng)關(guān)閉軟件，重啟電腦或者軟件后釋放掉一部分內(nèi)存又可以正常運(yùn)行該軟件或游戲一段時(shí)間。

　　內(nèi)存溢出已經(jīng)是軟件開發(fā)歷史上存在了近40年的“老大難”問題，像在“紅色代碼”病毒事件中表現(xiàn)的那樣，它已經(jīng)成為黑客攻擊企業(yè)網(wǎng)絡(luò)的“罪魁禍?zhǔn)住薄?如在一個(gè)域中輸入的數(shù)據(jù)超過了它的要求就會(huì)引發(fā)數(shù)據(jù)溢出問題，多余的數(shù)據(jù)就可以作為指令在計(jì)算機(jī)上運(yùn)行。據(jù)有關(guān)安全小組稱，操作系統(tǒng)中超過50%的安全漏洞都是由內(nèi)存溢出引起的，其中大多數(shù)與微軟的技術(shù)有關(guān)。

　　定義及原因

　　內(nèi)存溢出是指應(yīng)用系統(tǒng)中存在無法回收的內(nèi)存或使用的內(nèi)存過多，最終使得程序運(yùn)行要用到的內(nèi)存大于虛擬機(jī)能提供的最大內(nèi)存。為了解決Java中內(nèi)存溢出問題，我們首先必須了解Java是如何管理內(nèi)存的。Java的內(nèi)存管理就是對(duì)象的分配和釋放問題。在Java中，內(nèi)存的分配是由程序完成的，而內(nèi)存的釋放是由垃圾收集器（GarbageCollection，GC）完成的，程序員不需要通過調(diào)用GC函數(shù)來釋放內(nèi)存，因?yàn)椴煌腏VM實(shí)現(xiàn)者可能使用不同的算法管理GC，有的是內(nèi)存使用到達(dá)一定程度時(shí)，GC才開始工作，也有定時(shí)執(zhí)行的，有的是中斷式執(zhí)行GC。但GC只能回收無用并且不再被其它對(duì)象引用的那些對(duì)象所占用的空間。Java的內(nèi)存垃圾回收機(jī)制是從程序的主要運(yùn)行對(duì)象開始檢查引用鏈，當(dāng)遍歷一遍后發(fā)現(xiàn)沒有被引用的孤立對(duì)象就作為垃圾回收。

　　1、 內(nèi)存溢出的原因是什么？

　　內(nèi)存溢出是由于沒被引用的對(duì)象（垃圾）過多造成JVM沒有及時(shí)回收，造成的內(nèi)存溢出。如果出現(xiàn)這種現(xiàn)象可行代碼排查：

　　一）是否App中的類中和引用變量過多使用了Static修飾 如public staitc Student s；在類中的屬性中使用 static修飾的最好只用基本類型或字符串。如public static int i = 0; //public static String str;

　　二）是否App中使用了大量的遞歸或無限遞歸（遞歸中用到了大量的建新的對(duì)象）

　　三）是否App中使用了大量循環(huán)或死循環(huán)（循環(huán)中用到了大量的新建的對(duì)象）

　　四）檢查App中是否使用了向數(shù)據(jù)庫查詢所有記錄的方法。即一次性全部查詢的方法，如果數(shù)據(jù)量超過10萬多條了，就可能會(huì)造成內(nèi)存溢出。所以在查詢時(shí)應(yīng)采用“分頁查詢”。

　　五）檢查是否有數(shù)組，List，Map中存放的是對(duì)象的引用而不是對(duì)象，因?yàn)檫@些引用會(huì)讓對(duì)應(yīng)的對(duì)象不能被釋放。會(huì)大量存儲(chǔ)在內(nèi)存中。

　　六）檢查是否使用了“非字面量字符串進(jìn)行+”的操作。因?yàn)镾tring類的內(nèi)容是不可變的，每次運(yùn)行“+”就會(huì)產(chǎn)生新的對(duì)象，如果過多會(huì)造成新String對(duì)象過多，從而導(dǎo)致JVM沒有及時(shí)回收而出現(xiàn)內(nèi)存溢出。

　　如String s1 = “My name”;

　　String s2 = “is”;

　　String s3 = “xuwei”;

　　String str = s1 + s2 + s3 +.。。。。。。。。;這是會(huì)容易造成內(nèi)存溢出的

　　但是String str = “My name” + “ is ” + “ xuwei” + “ nice ” + “ to ” + “ meet you”; //但是這種就不會(huì)造成內(nèi)存溢出。因?yàn)檫@是”字面量字符串“，在運(yùn)行“+”時(shí)就會(huì)在編譯期間運(yùn)行好。不會(huì)按照J(rèn)VM來執(zhí)行的。

　　在使用String，StringBuffer，StringBuilder時(shí)，如果是字面量字符串進(jìn)行“+”時(shí)，應(yīng)選用String性能更好；如果是String類進(jìn)行“+”時(shí)，在不考慮線程安全時(shí)，應(yīng)選用StringBuilder性能更好。

　　public class Test {

　　public void testHeap（）{

　　for（;;）{ //死循環(huán)一直創(chuàng)建對(duì)象，堆溢出

　　ArrayList list = new ArrayList （2000）;

　　}

　　}

　　int num=1;

　　public void testStack（）{ //無出口的遞歸調(diào)用，棧溢出

　　num++;

　　this.testStack（）;

　　}

　　public static void main（String［］ args）{

　　Test t = new Test （）;

　　t.testHeap（）;

　　t.testStack（）;

　　}

　　}

　　七）使用 DDMS工具進(jìn)行查找內(nèi)存溢出的大概位置

　　2、棧溢出的原因

　　一）、是否有遞歸調(diào)用

　　二）、是否有大量循環(huán)或死循環(huán)

　　三）、全局變量是否過多

　　四）、 數(shù)組、List、map數(shù)據(jù)是否過大

　　五）使用DDMS工具進(jìn)行查找大概出現(xiàn)棧溢出的位置

　　解決方法

　　內(nèi)存溢出雖然很棘手，但也有相應(yīng)的解決辦法，可以按照從易到難，一步步的解決。

　　第一步，就是修改JVM啟動(dòng)參數(shù)，直接增加內(nèi)存。這一點(diǎn)看上去似乎很簡(jiǎn)單，但很容易被忽略。JVM默認(rèn)可以使用的內(nèi)存為64M，Tomcat默認(rèn)可以使用的內(nèi)存為128MB，對(duì)于稍復(fù)雜一點(diǎn)的系統(tǒng)就會(huì)不夠用。在某項(xiàng)目中，就因?yàn)閱?dòng)參數(shù)使用的默認(rèn)值，經(jīng)常報(bào)“OutOfMemory”錯(cuò)誤。因此，-Xms，-Xmx參數(shù)一定不要忘記加。

　　第二步，檢查錯(cuò)誤日志，查看“OutOfMemory”錯(cuò)誤前是否有其它異常或錯(cuò)誤。在一個(gè)項(xiàng)目中，使用兩個(gè)數(shù)據(jù)庫連接，其中專用于發(fā)送短信的數(shù)據(jù)庫連接使用DBCP連接池管理，用戶為不將短信發(fā)出，有意將數(shù)據(jù)庫連接用戶名改錯(cuò)，使得日志中有許多數(shù)據(jù)庫連接異常的日志，一段時(shí)間后，就出現(xiàn)“OutOfMemory”錯(cuò)誤。經(jīng)分析，這是由于DBCP連接池BUG引起的，數(shù)據(jù)庫連接不上后，沒有將連接釋放，最終使得DBCP報(bào)“OutOfMemory”錯(cuò)誤。經(jīng)過修改正確數(shù)據(jù)庫連接參數(shù)后，就沒有再出現(xiàn)內(nèi)存溢出的錯(cuò)誤。

　　查看日志對(duì)于分析內(nèi)存溢出是非常重要的，通過仔細(xì)查看日志，分析內(nèi)存溢出前做過哪些操作，可以大致定位有問題的模塊。

　　第三步，安排有經(jīng)驗(yàn)的編程人員對(duì)代碼進(jìn)行走查和分析，找出可能發(fā)生內(nèi)存溢出的位置。重點(diǎn)排查以下幾點(diǎn)：　　?

　　檢查代碼中是否有死循環(huán)或遞歸調(diào)用。

　　檢查是否有大循環(huán)重復(fù)產(chǎn)生新對(duì)象實(shí)體。

　　檢查對(duì)數(shù)據(jù)庫查詢中，是否有一次獲得全部數(shù)據(jù)的查詢。一般來說，如果一次取十萬條記錄到內(nèi)存，就可能引起內(nèi)存溢出。這個(gè)問題比較隱蔽，在上線前，數(shù)據(jù)庫中數(shù)據(jù)較少，不容易出問題，上線后，數(shù)據(jù)庫中數(shù)據(jù)多了，一次查詢就有可能引起內(nèi)存溢出。因此對(duì)于數(shù)據(jù)庫查詢盡量采用分頁的方式查詢。

　　檢查L(zhǎng)ist、MAP等集合對(duì)象是否有使用完后，未清除的問題。List、MAP等集合對(duì)象會(huì)始終存有對(duì)對(duì)象的引用，使得這些對(duì)象不能被GC回收。

　　第四步，使用內(nèi)存查看工具動(dòng)態(tài)查看內(nèi)存使用情況。某個(gè)項(xiàng)目上線后，每次系統(tǒng)啟動(dòng)兩天后，就會(huì)出現(xiàn)內(nèi)存溢出的錯(cuò)誤。這種情況一般是代碼中出現(xiàn)了緩慢的內(nèi)存泄漏，用上面三個(gè)步驟解決不了，這就需要使用內(nèi)存查看工具了。

　　內(nèi)存查看工具有許多，比較有名的有：Optimizeit Profiler、JProbeProfiler、JinSight和Java1.5的Jconsole等。它們的基本工作原理大同小異，都是監(jiān)測(cè)Java程序運(yùn)行時(shí)所有對(duì)象的申請(qǐng)、釋放等動(dòng)作，將內(nèi)存管理的所有信息進(jìn)行統(tǒng)計(jì)、分析、可視化。開發(fā)人員可以根據(jù)這些信息判斷程序是否有內(nèi)存泄漏問題。一般來說，一個(gè)正常的系統(tǒng)在其啟動(dòng)完成后其內(nèi)存的占用量是基本穩(wěn)定的，而不應(yīng)該是無限制的增長(zhǎng)的。持續(xù)地觀察系統(tǒng)運(yùn)行時(shí)使用的內(nèi)存的大小，可以看到在內(nèi)存使用監(jiān)控窗口中是基本規(guī)則的鋸齒形的圖線，如果內(nèi)存的大小持續(xù)地增長(zhǎng)，則說明系統(tǒng)存在內(nèi)存泄漏問題。通過間隔一段時(shí)間取一次內(nèi)存快照，然后對(duì)內(nèi)存快照中對(duì)象的使用與引用等信息進(jìn)行比對(duì)與分析，可以找出是哪個(gè)類的對(duì)象在泄漏。

　　通過以上四個(gè)步驟的分析與處理，基本能處理內(nèi)存溢出的問題。當(dāng)然，在這些過程中也需要相當(dāng)?shù)慕?jīng)驗(yàn)與敏感度，需要在實(shí)際的開發(fā)與調(diào)試過程中不斷積累。