前言
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
