使用visual提升Idea的启动速度

Idea，公认吃内存的IDE。我本机的Idea每次启动都很慢，然后我就把机器内存从8G提高到了16G，但是Idea的启动速度没有明显的增加。相反，相应速度更慢了。这是怎么回事呢？这个时候，就想着用visual监控一下Idea的启动，看一下垃圾回收情况。文章参考了：https://blog.csdn.net/u011863951/article/details/81589423。感谢作者的分享，谢谢！

文章目录
1 .安装visual插件
2 .使用visual GC插件观察Idea的GC情况
3 .生成GC日志，分析GC日志
4 .优化Idea的jvm，提升速度

目前Idea的jvm内存参数配置

Idea的信息

可以看到，使用的是OpenJDK1.8版本
1 .安装visual GC插件
visual GC插件下载地址
https://visualvm.github.io/pluginscenters.html
下载完成，安装插件
打开visual，点击工具------>插件
找到刚才我们下载的插件，安装即可。最终呈现的页面为

2 .使用visual GC插件观察Idea的GC情况
首先打开visual工具，然后打开visual GC选项卡
Idea启动过程的GC监控信息如下：

下面我们从上到下，说明一下监控的参数都是哪些意思

类编译时间，黑色带越短，说明类的编译越快，否则越慢。笔者的加载时间是8分21.859秒。jvm虚拟机启动时，会监控代码的调用，如果某一段代码被调用一定次数，就会成为热点代码，使用JIT编译成本地代码，加快运行速度

然后是类加载时间，共加载35023个类，消耗时间6分7.781秒

GC总次数168次,持续时间5.441秒。上一次GC的原因是内存分配失败

Eden Space (136.5M,34.125M)：27.368M ，154 collections，4.189秒
Eden区最大136.5M,当前容量34.125M,当前使用27.368M，154次 YGC，共耗时4.189秒

Survivor 0 (17.062M，4.250M)：1.328M
幸存区 0 最大容量17.062M，当前容量4.250M，1.328M

Survivor 1(17.062M，4.250M)：1.717M
幸存区 0 最大容量17.062M，当前容量4.250M，使用1.719M

Old Gen (341.375M，191.141M)：154.778M，14collections，1.253s
年老代最大容量341.375M，当前容量191.141M，当前使用153.778M，共经历14次Full GC，耗时1.253秒。( 老年代 GC 也叫做 Full GC， 因为在老年代 GC 时总是会伴随着 Minor GC， 合起来就称为 Full GC )

Metaspace (1.010G，188.062M)：176.411M
方法区最大容量1.010G，当前容量188.062M，当前使用176.411M

最下面是jvm的一些信息

新生代对象经历6次YGC后，进入老年代。
新生代对象每经历一次YGC，就长一岁，经历一定的岁数之后，就会进入老年代，这个年龄的默认值在jdk1,7及之前的版本默认值是15岁。该参数可通过-XX:MaxTenuringThreshold调整

下面开始进行调优
很明显YGC的次数有点太多了，达到了惊人的154次，Full GC也有14次。
而且监控工具很明确的提示了失败原因是分配内存失败。
我们可以增加堆空间的大小，但是具体增加到多大呢
我们打开监视选项，查看堆的变化情况

可以看到堆内存有一个明显的扩容过程，这是一个耗时的操作。我们目前的堆初始容量为：-Xms 128m
很明显是不够用，扩容的最大值最后定格为245M，所以我们可以直接将堆内存的初始容量设置为300M。避免堆扩容造成耗时。
-Xms 300m
重启Idea，再次观察Idea启动的GC情况

可以看到GC次数有了明显的下降
YGC共31次，Full GC共12次
GC次数还是有点多，而且GC的原因还是提示内存分配失败
我们继续增加堆的初始化大小，并且将堆的初始化大小设置成和最大堆内存一样大，防止堆内存不足时，分配内存占用时间。我们直接将堆的初始内存和最大内存设置为1G
再次启动Idea，观察GC情况

可以看到GC次数降低到了YGC共15次，Full GC共6次。GC的原因还是内存分配失败
但是在堆的监视页面，可以看到堆空间并没有发生扩容

可以看到堆空间的最大使用量，也就不到500M，我们分配的1G堆内存是完全够用的。
查看gcinfo.log日志文件

可以看到GC日志中，出现了大量的分配内存失败的错误，而且都出现在ParNew垃圾回收器工作期间，ParNew垃圾回收器是工作在新生代的。所以可以判断是新生代内存不足引起，我们调高新生代的内存
-XX:NewRatio=4：设置年轻代（包括1个Eden和2个Survivor区）与年老代的比值。表示年轻代比年老代为1:4。
我们调成1 。同时增大堆内存至2G

再次启动Idea，观察GC情况

可以看到MinorGC的次数降低到了6次，但是Full GC还是6次，并没有因为堆内存的提高而减少。我们知道jdk1.8之后，oracle公司将永久代的概念去除了，同时将字符串常量池和类的信息转移到了堆中，将永久代的其他东西转移到了本地堆中(Native Heap)
所以，Full GC不一定都是堆内存不足引起的。也有可能是元空间空间不足引起的。我们看一下metaSapce的GC情况

可以看到元空间发生了4次扩容。说明初始容量不足，我们设置一下元空间的大小

我们再次启动Idea，观察GC情况。发现Full GC还是有一次，并且是因为显示调用System.gc()引起的，我们禁用掉System.gc
我看了一下自己机器的cpu核数，是4核的。不太适合使用ParNew收集器，因为它要求CPU的核数要高，所以我们不再使用ParNew+CMS的组合，改为使用G1收集器

必须这么写，否则创建jvm会失败

可以看到MinorGC只有4次，Full GC一次都没有，启动时间也大幅度减少。OK，就这样吧。结果还是比较满意的。
最后的调优参数：