上周自己负责的一个应用出现频繁full gc的问题，不得不尝试优化一下。第一次做这种事只能先看看网上的文章，然后亲自尝试怎么去完成减少full gc的频率，降低young gc的频率这一目标。虽然最终只是勉强解决了，但还是希望记录下来给下一次积攒经验。
选取了上周优化前后的两个典型工作日上午9:00到晚上9:00的GC情况。优化前一天要发生高达上10次的full gc，young gc也非常频繁。优化后的图已经没有出现full gc，young gc的频率也大大降低了，所以说基本完成目标。
接下来说明排查过程
1.jps命令查看进程id
jps是java后自带的查看虚拟机进程状态命令工具，用如下命令就可以看到虚拟机执行主类和进程ID.
jps -l
2. jmap命令导出堆转储文件
jmap是java自带的内存映像工具，能将当前应用运行内存的情况导出为文件。注意格式，file后面是导出路径，最后的数字为上一步得到的进程id。一般导出来的文件都比较大，我导出的有2.1G，而且进行分析也很耗性能，所以导出后都要传输到其它机器上进行分析，并且为了避免占用磁盘空间删除本地文件。
jmap -dump:format=b,file=kfwebHeap1016.hprof 35073
3.mat工具分析堆转储文件
mat是eclipse提供的堆转储文件分析工具，用mat打开mat上一步导出的文件，如下图所示，可以看到总体内存占用情况的扇形图，哪个文件占用内存最多就可以一目了然了。
点击histogram就可以看出各个对象的内存占用情况，如下所示
点击Leak Suspects就可以给出最有可能发生内存泄漏的几种情况。能很好的帮助用户进行内存分析，这也是mat强大的重要体现，如下：
到这里应该是最关键的环节了，可能因为没有经验，看来看去也没看出哪里不对，所以只能作罢，这条路已经走不下去了，所以说这次分析不太成功。
4.G1来了
后来向一个老同事说明了我的情况，他问我用的什么垃圾回收器，我说用的是默认的，年经代用Parallel Scavenge，老年代用Parallel Old，他说让我先换到G1试试吧。然后我查了一下，发现G1果然比较牛逼，虽然保留了以前的新生代Eden，Survivor和老年代的概念，但新生代和老年代不再物理隔离，而且它将内存分为很多等大的region，每个region根据需要都有可能成为S(Surviror),E(Eden), O(Old)的一种，所以G1既能回收新生代也能回收老年代，它以垃圾回收为第一（这也是它名字的由来:Garbage First，G1）目标，励志于取决CMS, 并且在java9是已经是jdk默认的垃圾回收器了。说了这么多，暂时没有多时间深入研究，不管怎么样还是值得一试的。于是在应用的jvm启动参数加了如下一行:
-XX:+UseG1GC
当然只是在一台机器上作了处理，也便于与其它机器作对比。
5.MetaSpace调整
通过调整后的这台机器与其它机器对比，gc情况还是改善了不少，但是在查看gc日志时发现了这么这个频繁出现的问题：
Metadata GC Threshold
由于元数据空间不足导致的GC.原来在G1中设置PermSize(永久代大小)已经没用了，取而代之的是MetaSpace参数，虽然这个用的是并非堆内存而是机器的物理内存并且最大大小没有限制，但是默认初始大小只有20m，所以要作出调整：
-XX:MetaspaceSize=128m
加了之后果然就没有出现这个问题了
6. 解决Humongous Allocation
在gc日志中还发现频繁出现：
G1 Humongous Allocation
这个是由于大型对象分配导致的问题，大型(Humongous)对象是指超过G1的Region 50%的内存对象，频繁大型对象内存内存分配会导致性能问题，而且如果一个region中大型对象过多的话则最后一个大型对内象边界和该region的边界之间的空间将不会被使用，如果有多个这样的region将会导致堆内存的碎片化，在jdk1.8u40之前这些大型对象的清理在full gc期间进行完成。较新的jvm也是把大型对象放在清理阶段，要解决上面的问题有两种方法。
1.增加region的大小(注意要在1到32m之间并且为2的整数次幂)
2.增加堆内存大小
总结：其实这一次只是引进了G1垃圾回收器并且对相关参数进行调整，但是促使我去了解jvm相关的知识和工具使用，还是有很很大收获的。
