今天生產(chǎn)環(huán)境出現(xiàn)Java.lang.OutOfMemoryErrot: GC overhead limit exceeded

網(wǎng)上查了資料這個(gè)錯(cuò)只有在java.lang.OutOfMemoryError: GC overhead limit exceeded（某項(xiàng)操作使用大量?jī)?nèi)存時(shí)發(fā)生）

資料：http://blog.csdn.net/jiandanjinxin/article/details/51740890

好吧放闺，那只能先heapdump下看看到底哪個(gè)沒(méi)有回收

方案一：

重啟前先把修改一下tomcat的啟動(dòng)參數(shù)鞋怀，萬(wàn)一再發(fā)生OOM可以自動(dòng)dump堆棧信息啃洋。

1欢嘿、 在tomcat啟動(dòng)參數(shù)中加入兩個(gè)參數(shù) -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/export/home/tomcat/domains/server2/oom.hprof

2、 重啟tomcat

參數(shù)說(shuō)明

（1）-XX:+HeapDumpOnOutOfMemoryError 表示當(dāng)JVM發(fā)生OOM時(shí)揩局，自動(dòng)生成DUMP文件毫玖。

（2）-XX:HeapDumpPath=存儲(chǔ)文件/目錄 表示生成DUMP文件的路徑

方案二：

生產(chǎn)系統(tǒng)，總不能等著他當(dāng)吧，既然是OOM那就先看下生產(chǎn)上的堆內(nèi)存分配情況

jmap -heap PID

Debugger attached successfully.

Server compiler detected.

JVM version is 25.112-b15

using thread-local object allocation.

Parallel GC with 4 thread(s)

Heap Configuration:

MinHeapFreeRatio? ? ? ? = 0

MaxHeapFreeRatio? ? ? ? = 100

MaxHeapSize? ? ? ? ? ? ? = 2063597568 (1968.0MB)

NewSize? ? ? ? ? ? ? ? ? = 42991616 (41.0MB)

MaxNewSize? ? ? ? ? ? ? = 687865856 (656.0MB)

OldSize? ? ? ? ? ? ? ? ? = 87031808 (83.0MB)

NewRatio? ? ? ? ? ? ? ? = 2

SurvivorRatio? ? ? ? ? ? = 8

MetaspaceSize? ? ? ? ? ? = 21807104 (20.796875MB)

CompressedClassSpaceSize = 1073741824 (1024.0MB)

MaxMetaspaceSize? ? ? ? = 17592186044415 MB

G1HeapRegionSize? ? ? ? = 0 (0.0MB)

Heap Usage:

PS Young Generation

Eden Space:

capacity = 161480704 (154.0MB)

used? ? = 161480704 (154.0MB)

free? ? = 0 (0.0MB)

100.0% used

From Space:

capacity = 229113856 (218.5MB)

used? ? = 82645888 (78.8172607421875MB)

free? ? = 146467968 (139.6827392578125MB)

36.07197287971968% used

To Space:

capacity = 229113856 (218.5MB)

used? ? = 0 (0.0MB)

free? ? = 229113856 (218.5MB)

0.0% used

PS Old Generation

capacity = 1375731712 (1312.0MB)

used? ? = 1375583088 (1311.8582611083984MB)

free? ? = 148624 (0.1417388916015625MB)

99.98919673082305% used

23110 interned Strings occupying 2726400 bytes.

一看內(nèi)存又快完了孕豹，好害怕啊，竟然大部分的堆內(nèi)存都在老年代十气，難道是有線(xiàn)程還沒(méi)結(jié)束励背，導(dǎo)致內(nèi)存無(wú)法釋放，那要再確認(rèn)一下砸西。

jmap -dump:format=b,file=文件名.hprof [pid] ?

jmap的幾個(gè)操作要慎用

dump很占用系統(tǒng)資源叶眉，可能會(huì)引起down機(jī)，但是沒(méi)辦法問(wèn)題要查啊芹枷。

然后down到本地衅疙，用mat來(lái)分析，mat的安裝辦法見(jiàn)下：

mat安裝

mat使用

打開(kāi)dump文件一看鸳慈，被一個(gè)填滿(mǎn)了

再看詳細(xì)的信息饱溢，發(fā)現(xiàn)全部是jdbc在取數(shù)據(jù)，而且線(xiàn)程還沒(méi)結(jié)束走芋，當(dāng)然回收不了了绩郎，果然是代碼有坑啊。

根據(jù)這個(gè)的數(shù)據(jù)翁逞，找到對(duì)應(yīng)的腳本肋杖，并找到對(duì)應(yīng)的代碼，原來(lái)1000w的數(shù)據(jù)挖函，對(duì)端系統(tǒng)什么條件都沒(méi)帶状植，直接來(lái)查導(dǎo)致內(nèi)存溢出。

后面對(duì)該代碼加上默認(rèn)分頁(yè)怨喘，問(wèn)題解決津畸。

jvm內(nèi)存優(yōu)化：JAVA_OPTS="-server -Xms256m -Xmx512m -XX:PermSize=64M -XX:MaxPermSize=128m"