前言
java虛擬機(jī)是運行所有java程序的抽象計算機(jī)，是java語言的運行環(huán)境，它是java 最具吸引力的特性之一。java虛擬機(jī)是通過在實際的計算機(jī)上仿真模擬各種計算機(jī)功能模擬來實現(xiàn)的，通過java虛擬機(jī)，您只要根據(jù)jvm規(guī)格描述將解釋器移植到特定的計算機(jī)上，就能保證經(jīng)過編譯的任何java代碼能夠在該系統(tǒng)上運行。
最近在看jvm群里有人發(fā)了一個gc情況，讓人幫忙看優(yōu)化的，于是我也湊熱鬧發(fā)了出來想讓群里的大神們指導(dǎo)優(yōu)化一下，以下是優(yōu)化過程記錄.
一開始我貼了下面的兩張圖
jstat看gc記錄
jstat -gcutil pid 1000 20
jcmd看vm參數(shù)(第一次使用這個命令)
jcmd pid vm.flags
可以看到y(tǒng)gc了8w多次，fgc有1100+，相比較另一個發(fā)出來求教的，我這個更糟糕，他的是運行了3天左右 fgc370次
然后飛神讓我看下運行時間
ps -p pid -o etime
我的也是跑了3天左右，感覺優(yōu)化空間非常的大
又讓我拉了jvm配置
jinfo -flags pid(沒權(quán)限，沒執(zhí)行成功)
ps aux | grep pid
發(fā)現(xiàn)我的jvm完全沒做過優(yōu)化，據(jù)我自己的印象，就改過permsize,因為這個oom過，所以調(diào)大了一點。
然后飛神給了我一份他之前用過的配置
|
1
|
java_opts="-xms2g -xmx2g -xmn512m -xx:maxpermsize=256m -server -xss256k -xx:permsize=128m -xx:+printgcdetails -xx:+printgcdatestamps -xloggc:/data/log/gclog/gc.log -xx:+heapdumponoutofmemoryerror -xx:heapdumppath=/data/log/jvmdump/jvm.bin -xx:+useconcmarksweepgc -xx:+useparnewgc -xx:cmsinitiatingoccupancyfraction=75 -xx:+usecmsinitiatingoccupancyonly -xx:+usecmscompactatfullcollection -xx:cmsfullgcsbeforecompaction=0 -xx:+cmsclassunloadingenabled -xx:+tieredcompilation -xx:+printtenuringdistribution -xx:+printgcapplicationstoppedtime -xx:+printheapatgc |
并囑咐了一句loggc和dumppath提前mkdir
因為已經(jīng)是周五晚上了，我沒有權(quán)限直接修改這個配置，所以準(zhǔn)備下周一再配上去看效果。
萬萬沒想到，回家路上，笨神出來說話了，要我看下存活實例
jmap -histo:live pid
由于沒有開啟gc日志，于是笨神讓我開著jstat（飛神提到jstat -gccause pid可以gc情況），然后在另一個窗口執(zhí)行jmap -histo:live
剛開始沒明白，后來才知道原來這個命令可以觸發(fā)fgc
可以看到fgc了以后old區(qū)從90%降到了79%，fgc效果很差，說明活對象太多了。
回過頭去看jmap實例，發(fā)現(xiàn)atomicinteger這個類對象特別的多，竟然有300多萬個實例,已經(jīng)是top2了。
翻看代碼沒有發(fā)現(xiàn)有使用這個類的地方，初步懷疑是依賴的jar包使用的，笨神建議dump用mat分析一下。
dump命令導(dǎo)出文件
jmap -dump:format=b,file=pid.dump pid
總結(jié)
以上就是這篇文章的全部內(nèi)容了，暫時告一段落，持續(xù)更新中。希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作能帶來一定的幫助，如果有疑問大家可以留言交流，謝謝大家對服務(wù)器之家的支持。
原文鏈接：https://segmentfault.com/a/1190000010510968
