前言

Java虛擬機是運行所有Java程序的抽象計算機，是Java語言的運行環(huán)境，它是Java 最具吸引力的特性之一。Java虛擬機是通過在實際的計算機上仿真模擬各種計算機功能模擬來實現(xiàn)的，通過Java虛擬機，您只要根據(jù)JVM規(guī)格描述將解釋器移植到特定的計算機上，就能保證經(jīng)過編譯的任何Java代碼能夠在該系統(tǒng)上運行。

最近在看JVM群里有人發(fā)了一個GC情況，讓人幫忙看優(yōu)化的，于是我也湊熱鬧發(fā)了出來想讓群里的大神們指導優(yōu)化一下，以下是優(yōu)化過程記錄.

一開始我貼了下面的兩張圖

jstat看GC記錄

jstat -gcutil pid 1000 20

jcmd看VM參數(shù)(第一次使用這個命令)

jcmd pid VM.flags

可以看到YGC了8W多次，F(xiàn)GC有1100+，相比較另一個發(fā)出來求教的，我這個更糟糕，他的是運行了3天左右 FGC370次

然后飛神讓我看下運行時間

ps -p pid -o etime

我的也是跑了3天左右，感覺優(yōu)化空間非常的大

又讓我拉了JVM配置

jinfo -flags pid(沒權限，沒執(zhí)行成功)

ps aux | grep pid

發(fā)現(xiàn)我的JVM完全沒做過優(yōu)化，據(jù)我自己的印象，就改過PermSize,因為這個OOM過，所以調大了一點。

然后飛神給了我一份他之前用過的配置

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)是周五晚上了，我沒有權限直接修改這個配置，所以準備下周一再配上去看效果。

萬萬沒想到，回家路上，笨神出來說話了，要我看下存活實例

jmap -histo:live pid

由于沒有開啟GC日志，于是笨神讓我開著jstat（飛神提到jstat -gccause pid可以gc情況），然后在另一個窗口執(zhí)行jmap -histo:live

剛開始沒明白，后來才知道原來這個命令可以觸發(fā)FGC

可以看到FGC了以后Old區(qū)從90%降到了79%，F(xiàn)GC效果很差，說明活對象太多了。

回過頭去看jmap實例，發(fā)現(xiàn)AtomicInteger這個類對象特別的多，竟然有300多萬個實例,已經(jīng)是top2了。

翻看代碼沒有發(fā)現(xiàn)有使用這個類的地方，初步懷疑是依賴的jar包使用的，笨神建議dump用MAT分析一下。

dump命令導出文件

jmap -dump:format=b,file=pid.dump pid

總結

以上就是這篇文章的全部內容了，暫時告一段落，持續(xù)更新中。希望本文的內容對大家的學習或者工作能帶來一定的幫助，如果有疑問大家可以留言交流，謝謝大家對腳本之家的支持。

最新評論