寫在前面

java內存申請和釋放均是由jvm在控制。而釋放往往會出現各種各樣的問題，經常一個引用沒處理好就引起內存泄漏，最后引發OOM。如果發生在重要業務系統還可能出現嚴重的生產事故。 因此內存使用一定要謹慎，特別是引用要及時斷鏈。雖然jvm有GC(垃圾回收引擎)，但只能清理沒有引用的對象，因此對象在不使用時及時置null。當然，筆者對此是很小心的，但萬萬沒想到還是遇到了fullGC(old GC)。

定義

jvm的GC

通常遇到的是堆區內存問題，也就是堆GC。jvm的GC發展到現在也經歷很多發展了，現在主要還是分代回收的思路。

eden space

伊甸園，新生對象放置的地方。

survivor space

在jvm中的被回收過對象仍存活的地方。

old Generation

幸存區被清理后仍活著的對象就步入老年了。 大多數GC問題都在老年代中被發現，筆者遇到的問題也是在這里。

eden 和survivor都屬于新生代，與old gen有明顯差別，也就是這樣決定了java程序不用主動回收也能在較好的狀態運行。 eden和survivor空間相對old generation小很多，這也意味著存放的內存也少很多。jvm一般將長期引用(jvm會將對象分析其引用計數)的對象(多次GC仍存活的)放在Old generation中。

jvm堆區不同區域使用的是不同算法，eden和survivor的GC屬于miniGC，也就是局部GC，特點是速度快，低延遲(1.標記復制算法與空間小的優勢，2.GC時需要將所有線程掛起Stop The World)。而old generation發生GC則為FullGC，且old generation用的是標記整理算法，線程扶起時間會很長。頻繁的fullGC可能是程序設計不合理或內存參數不合理。

言歸正傳

這兩天筆者遇到一個問題導致了fullGC發生。將進程進行dump分析 jmap命令配合工具 MAT(eclipse提供)發現是部分局部變量占用太多空間未及時釋放造成并且占用了55%以上的內存空間。 為什么局部變量還會未及時釋放？查閱源代碼發現所有引用處均未發現被全局對象、靜態對象引用。ArrayList和LinkedList占用內存過高，但也未被全局對象和靜態對象引用。

感覺程序被幽靈附身了!!! 不存在的，直覺告訴我這種問題肯定在自己的程序上。繼續分析果然發現了問題所在：發現對象內的值關聯性非常強，繼續分析最終找到數據庫查詢參數。會不會是數據造成？面對這個疑問diff了最近數據的情況。

蘆山真面目

最近數據量暴增！ 數量增加了6倍+，空間增加了3倍+。

由于數據結構和業務邏輯的特殊性將同條件的數據全部查出來處理了，由于數據全是相互存在引用，eden空間無法分配進行了miniGC。miniGC后空間仍然不足，就這樣新生對象直接進入old generation。才生出來就進入老年 >_

解決方案

知道了原因就立即分析得到了解決方案。盡量不要構建局部的大對象！！！因此將DB中查詢出的量控制住，增加中間對象的數量，用完即置null。使得eden中及時GC，old generation增長穩定。 修改程序代碼再將壓一下，發現old generation增長緩下來了，問題解決。

如果遇到類似問題還可以用jconsole和jvisual兩款工具實時監控jvm狀態、對象實例指標等。

不好的消息：jdk9已將jvisual去除，要使用jvisual請使用jdk8。jdk10中jconsole也沒了。。 jmap分析吧。。。

總結

以上是生活随笔為你收集整理的Java内存配太大导致fullgc_记一次因为短命大对象导致fullGC的问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。