一次jvm调优经历-idea启动优化

 受《深入理解JVM》这本书的启发，准备针对idea进行一次优化。

首先放一下效果图

优化前: 系统启动并且运行了几个小时后的idea，多次启动后取的平均时间23秒，

优化后：时长19秒左右。提升了四分之一的启动时间，并且在后续loadingClass的时间也明显提升。

 

1 准备工作

   1 为了记录idea启动时间，需要安装一个idea的插件，这里我去idea的插件官网下载的，下载后从本地install 到disk中。地址是

 http://plugins.jetbrains.com/plugin/11083-start-time

   2 jvisualvm的virutalGC插件

2 . 开始优化

 启动idea，用jvisualvm观察，这里面总时长可以由右边的图表获得，这张图片是idea打开一段时间之后的截图

1类编译时长 1分15秒。

2类加载器加载时间。

3GC总次数，总时长 

4 年轻代GC次数(Minor GC)

5 老年代GC(FULL GC)

前两条的时间虽然长，但是是JIT优化编译时长，很难进行控制，目前已知的只能通过-Xverify:none参数去掉字节码验证来提升一些速度，但是效果不是很明显，不过idea在后续loadingClass的时候确实快了很多。主要优化部分在3，4，5的GC部分。

首先我们希望能去掉FullGc，这时需要打印idea的jvm日志，确定GC原因

#GC日志相关
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-Xloggc:D:\gc.log

这里的日志忘记保存，由于默认-xms是128M，打开会后发现大量的担保失败，导致堆扩容，触发Fullgc的操作，这时候的解决方案也简单，单纯增大堆内存即可。于是加上

-Xms750m
-Xmx750m

然后继续启动，但是加上后，我们希望的是达到0次，发现GC次数仍然达到4次。首先怀疑是不是堆内存扩的太小了，观察jvisualvm监控，发现堆内存维持在300多M，远没有达到750M，仔细看一下GC日志。(此处忘记截图)

发现4次FullGC的时候老年代和新生代的内存远没有达到堆内存，只达到了百分之十左右，但是却发生了FullGC，这个时候联想一下触发FullGC的原因，除了堆内存，还有一块元空间(MetaSpace)也是触发FullGC也可能触发FullGC，打开jvisualvm监控后，发现元凶果然在这里。

在不设置MetaSpace的参数的时候，实际空间和最大空间的比值在百分之99左右维持，如果空间不足会执行扩容，直到达到机器内存的上限，这里每次扩容的时候会触发一次FullGC。

找到原因后观察idea启动后，MetaSpace稳定在300M之内。于是增加两个参数

-XX:MetaspaceSize=300m
-XX:MaxMetaspaceSize=512m

最大元空间是512M，在元空间达到300M的时候执行扩容。

 

启动后再次观察，

fullGC确实消失，已经达到了我们的预期，0次。但是这个时候MinorGC仍然有10次，我们希望这个GC次数也减少一些，观察MinorGC日志。

发现jvm启动11秒后，每隔两秒左右就有一次MinorGC，新生代最大空间有大概250M，这时候两种方案，如果机器内存不足的情况下可以调整新生代和老年代的比例，通过-XX:NewRatio=n调整。当然，也可以直接调大堆内存，我的机器内存12G，索性就直接调大了堆内存。

-Xms2048m
-Xmx2048m

需要注意的是，这里的参数也不是越大越好，如果太大在idea运行的过程中发生FullGC的时候回收时间会很长，会有明显的停顿感。

调整过后，打印gc日志。

minorGC也减少了一部分，当然，这里的gc不可避免。只能略微调整减少部分。

针对CMS的GC日志部分也是需要了解的，这里有一篇博文讲的不错 可以参考https://www.cnblogs.com/onmyway20xx/p/6590603.html