起因

17年的一個項(xiàng)目出了OOM（java heap space）問題，眼下有個問題：法院項(xiàng)目，不能外網(wǎng)，一連接外網(wǎng)高院會直接定位到計算機(jī)，發(fā)出警報（檔案的機(jī)密性啊）不能遠(yuǎn)程，那只能視頻教他們怎么做了，全程和一個文員說代碼，真的很累==！

過程

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

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

設(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)上說修改注冊表和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)打開的情況下，工具里面會顯示tomcat運(yùn)行的情況

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

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

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

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

根據(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的對象，數(shù)據(jù)庫刪除排序條件，問題解決了 = 。=

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

總結(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)容請搜索好吧啦網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持好吧啦網(wǎng)！