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