java怎么檢查程序內(nèi)存溢出

java程序大家都知道，內(nèi)存溢出是經(jīng)常見的錯(cuò)誤，下面從基本的開始分析！

公司主營業(yè)務(wù)：網(wǎng)站設(shè)計(jì)、做網(wǎng)站、移動(dòng)網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。創(chuàng)新互聯(lián)是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對(duì)我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)推出崗巴免費(fèi)做網(wǎng)站回饋大家。

內(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性能更好。

知道原因了，解決起來就非常簡單了。

java :轉(zhuǎn)變?yōu)槟娌ㄌm表示式的代碼報(bào)錯(cuò)：堆棧溢出，怎么解決？

while(Character.isDigit(chars[i])||chars[i]=='.') {

s.append(chars[i]);

}

這一段是死循環(huán)。。stack一直追加參數(shù)，所以溢出了

java內(nèi)存溢出怎么解決？

第一對(duì)所有的代碼包括頁面中的java代碼都進(jìn)行一遍徹底的回顧檢查，

1.對(duì)那些靜態(tài)(static)的對(duì)象要特別留神，特別是類型為Map,List,Set的，靜態(tài)的變量會(huì)一直駐存在內(nèi)存中，生命周期比較長，不會(huì)被垃圾器回收。

2．對(duì)于代碼，要審查是否生成了大量的冗余的對(duì)象，還有一些邏輯業(yè)務(wù)處理的類，

算法是否過于復(fù)雜，調(diào)整算法，對(duì)于代碼認(rèn)真審查，再仔細(xì)重構(gòu)一遍代碼，能提高代碼質(zhì)量，提高程序運(yùn)行穩(wěn)定性。

3.Java中的內(nèi)存溢出大都是因?yàn)闂Ｖ械淖兞刻嗔恕Ｆ鋵?shí)內(nèi)存有的是。建議不用的盡量設(shè)成null以便回收，多用局部變量，少用成員變量。

1），變量所包含的對(duì)象體積較大，占用內(nèi)存較多。

2），變量所包含的對(duì)象生命周期較長。

3），變量所包含的對(duì)象數(shù)據(jù)穩(wěn)定。

4），該類的對(duì)象實(shí)例有對(duì)該變量所包含的對(duì)象的共享需求。

4．在我的程序中對(duì)靜態(tài)變量的優(yōu)化后，使程序占用內(nèi)存量至少提升了5k-10k。所以也不容忽視。

第二還有就是String類相關(guān)的東西：

1．字符串累加的時(shí)候一定要用StringBuffer的append方法，不要使用+操作符連接兩個(gè)字符串。差別很大。而且在循環(huán)或某些重復(fù)執(zhí)行的動(dòng)作中不要去創(chuàng)建String對(duì)象，因?yàn)镾tring對(duì)象是要用StringBuffer對(duì)象來處理的，一個(gè)String對(duì)象應(yīng)該是產(chǎn)生了 3個(gè)對(duì)象（大概是這樣：））。

2．字符串length()方法來取得字符串長度的時(shí)候不要把length放到循環(huán)中，可以在循環(huán)外面對(duì)其取值。(包括vector的size方法)。特別是循環(huán)次數(shù)多的時(shí)候，盡量把length放到循環(huán)外面。

int size = xmlVector.size();

for (int i = 2; i size; i++) {

。。。

}

3 寫代碼的時(shí)候處理內(nèi)存溢出

try{

//do sth

....

}catch (outofmemoryerror e){//可以用一個(gè)共通函數(shù)來執(zhí)行.

system.out.print (“no memory! ”);

system.gc();

//do sth again

....

} 4.對(duì)于頻繁申請(qǐng)內(nèi)存和釋放內(nèi)存的操作,還是自己控制一下比較好,但是System.gc()的方法不一定適用，最好使用finallize強(qiáng)制執(zhí)行或者寫自己的finallize方法。 Java 中并不保證每次調(diào)用該方法就一定能夠啟動(dòng)垃圾收集，它只不過會(huì)向JVM發(fā)出這樣一個(gè)申請(qǐng)，到底是否真正執(zhí)行垃圾收集，一切都是個(gè)未知數(shù)。