起因

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

過程

這個過程對一個不太了解內存的問題的開發無疑是艱難的，搜了一下，知道了是內存溢出導致的，于是著手解決

網上大多數都說調整運行內存，我也跟這個試了，但是不見效果，具體操作過程如下

設置-Xms256m -Xmx512m -XX:PermSize=64M -XX:MaxPermSize=256M 出現異常，然后調大參數-Xms512m -Xmx1024m 沒有解決，最后調整到2G 還沒有解決 以上均在GUI界面修改java options參數，因為那邊安裝的服務，至于網上說修改注冊表和catalina.bat或者catalina.sh的自行搜索

既然這樣，那就只能通過代碼優化了，開啟項目，監聽堆和內存運行情況，操作如下

先打開jdk下的內存監聽程序(jdk/bin/jvisualvm.exe),這是jdk自帶的，如果你項目已經打開的情況下，工具里面會顯示tomcat運行的情況

只需要監聽CPU和內存這兩個部分，CPU會顯示CPU運行情況和GC處理頻率；內存會顯示運行時堆內數據的變化，如對象實例等。

給出現內存溢出的模塊發一個請求，如果有異常的情況下你就可以監測出來，我的就是一次性加載數據太多，實例化對象太多導致的堆中年輕代和老年代數據占用完

我復現了一下，堆中出現了一個很高的點，那就是在加載樹結構，然后忽然下落，是因為JVM 98% 的時間都用在了GC上，出現了java heap space ，CPU也能直觀的看到，垃圾回收活動出現了一個較高的峰值

我們來看一下堆峰值時的數據，創建了300萬的ArrayList和TreeVO對象

根據這些，知道了代碼中出現的問題，代碼中有一塊調用了這樣的代碼，我們來看一下，這里創建了ArrayList和TreeVO ，而且ArrayList和TreeVO之間是強引用關系，GC不能清除，所以就導致了OOM

知道了問題，那就可以修改了，一步一步追溯到上面的方法，是因為查詢條件的限制，像當于直接把所有文件查詢出來，又因為數據有上萬條，所以就各創建300W的對象，數據庫刪除排序條件，問題解決了 = 。=

這里還不夠理想，TreeVO應該放在循環外面，循環內把對象實例化，最后釋放對象和集合

總結

問題總算解決了，這也是一次難得的真實上手內存的問題，可歌可泣啊 現在的開發人員可以說是上手就能寫代碼，往往忽視了最重要的基礎 看書是必不可少的（因為我最近在看《深入理解java虛擬機》，不然怎么知道jvisualvm查看內存啊） 網上很多講解內存的，但是不夠全面，想要系統的了解還是看書吧

到此這篇關于如何解決項目中java heap space的問題的文章就介紹到這了,更多相關java heap space問題內容請搜索好吧啦網以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持好吧啦網！