起因

17年的一個(gè)項(xiàng)目出了OOM（java heap space）問題，眼下有個(gè)問題：法院項(xiàng)目，不能外網(wǎng)，一連接外網(wǎng)高院會(huì)直接定位到計(jì)算機(jī)，發(fā)出警報(bào)（檔案的機(jī)密性?。┎荒苓h(yuǎn)程，那只能視頻教他們?cè)趺醋隽?，全程和一個(gè)文員說代碼，真的很累==！

過程

這個(gè)過程對(duì)一個(gè)不太了解內(nèi)存的問題的開發(fā)無疑是艱難的，搜了一下，知道了是內(nèi)存溢出導(dǎo)致的，于是著手解決

網(wǎng)上大多數(shù)都說調(diào)整運(yùn)行內(nèi)存，我也跟這個(gè)試了，但是不見效果，具體操作過程如下

設(shè)置-Xms256m  -Xmx512m -XX:PermSize=64M -XX:MaxPermSize=256M 出現(xiàn)異常，然后調(diào)大參數(shù)-Xms512m -Xmx1024m 沒有解決，最后調(diào)整到2G 還沒有解決  以上均在GUI界面修改java options參數(shù)，因?yàn)槟沁叞惭b的服務(wù)，至于網(wǎng)上說修改注冊(cè)表和catalina.bat或者catalina.sh的自行搜索

既然這樣，那就只能通過代碼優(yōu)化了，開啟項(xiàng)目，監(jiān)聽堆和內(nèi)存運(yùn)行情況，操作如下

先打開jdk下的內(nèi)存監(jiān)聽程序(jdk/bin/jvisualvm.exe),這是jdk自帶的，如果你項(xiàng)目已經(jīng)打開的情況下，工具里面會(huì)顯示tomcat運(yùn)行的情況

只需要監(jiān)聽CPU和內(nèi)存這兩個(gè)部分，CPU會(huì)顯示CPU運(yùn)行情況和GC處理頻率；內(nèi)存會(huì)顯示運(yùn)行時(shí)堆內(nèi)數(shù)據(jù)的變化，如對(duì)象實(shí)例等。

給出現(xiàn)內(nèi)存溢出的模塊發(fā)一個(gè)請(qǐng)求，如果有異常的情況下你就可以監(jiān)測(cè)出來，我的就是一次性加載數(shù)據(jù)太多，實(shí)例化對(duì)象太多導(dǎo)致的堆中年輕代和老年代數(shù)據(jù)占用完

我復(fù)現(xiàn)了一下，堆中出現(xiàn)了一個(gè)很高的點(diǎn)，那就是在加載樹結(jié)構(gòu)，然后忽然下落，是因?yàn)镴VM 98% 的時(shí)間都用在了GC上，出現(xiàn)了java heap space ，CPU也能直觀的看到，垃圾回收活動(dòng)出現(xiàn)了一個(gè)較高的峰值

我們來看一下堆峰值時(shí)的數(shù)據(jù)，創(chuàng)建了300萬的ArrayList和TreeVO對(duì)象

根據(jù)這些，知道了代碼中出現(xiàn)的問題，代碼中有一塊調(diào)用了這樣的代碼，我們來看一下，這里創(chuàng)建了ArrayList和TreeVO ，而且ArrayList和TreeVO之間是強(qiáng)引用關(guān)系，GC不能清除，所以就導(dǎo)致了OOM

知道了問題，那就可以修改了，一步一步追溯到上面的方法，是因?yàn)椴樵儣l件的限制，像當(dāng)于直接把所有文件查詢出來，又因?yàn)閿?shù)據(jù)有上萬條，所以就各創(chuàng)建300W的對(duì)象，數(shù)據(jù)庫刪除排序條件，問題解決了 = 。=

這里還不夠理想，TreeVO應(yīng)該放在循環(huán)外面，循環(huán)內(nèi)把對(duì)象實(shí)例化，最后釋放對(duì)象和集合

總結(jié)

• 問題總算解決了，這也是一次難得的真實(shí)上手內(nèi)存的問題，可歌可泣啊
• 現(xiàn)在的開發(fā)人員可以說是上手就能寫代碼，往往忽視了最重要的基礎(chǔ)
• 看書是必不可少的（因?yàn)槲易罱诳础渡钊肜斫鈐ava虛擬機(jī)》，不然怎么知道jvisualvm查看內(nèi)存啊）
• 網(wǎng)上很多講解內(nèi)存的，但是不夠全面，想要系統(tǒng)的了解還是看書吧

到此這篇關(guān)于如何解決項(xiàng)目中java heap space的問題的文章就介紹到這了,更多相關(guān)java heap space問題內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論