工欲善其事必先利其器，何不给IDEA来一次调优呢？

前言

最近在读周志明大大的《深入理解Java 虚拟机》，看到大大对ecplise进行调优，手痒痒，想着亲手给自己的IDEA也做一次调优，正好最近电脑升级了一次内存，之前的配置肯定也不适合了，废话不多说，直接开搞！

环境介绍

IDEA：2019.1.3 64位（安装在固态盘）

JDK：1.8 64位

内存大小：16GB

使用软件：Java VisualVM，jstat ，jps

不要直接复制最后的配置，每台机器和环境都不一样，直接复制不能起到调优的效果，反而有可能起到反作用！！！！

启动时间计算标准：测试使用同一个SSM的Web项目，启动时间从双击到IDEA验证完项目中的Spring 配置为止

因为IDEA安装插件会影响启动速度，列举一下已安装的插件

优化前

IDEA初始配置

-Xms128m
-Xmx750m
-XX:ReservedCodeCacheSize=240m
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-Djdk.http.auth.tunneling.disabledSchemes=""
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow

统计：

启动时间：62s
Minor GC：75次耗时1.006s
Full GC：12次耗时0.535s

分析

首先Minor GC，和Full GC次数有点太多了，Minor GC次数多的原因主要就是Eden区过小，反正内存16GB肯定够用了，干脆就给他分配2GB看看效果，至于Full GC，引发的原因有很多种，稍后再分析讨论

第一次优化

-Xms2048m
-Xmx2048m
-Xmn768m
-XX:ReservedCodeCacheSize=240m
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-Djdk.http.auth.tunneling.disabledSchemes=""
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow

这次优化配置将初始堆大小变为2GB，最大堆大小也变为2GB，新生代的堆大小初始为768MB

统计

启动时间：42.25s
Minor GC：5次耗时0.48s
Full GC：6次耗时0.42s

分析

Minor GC的次数已经算是很正常了，但是Full GC的次数好像还是有点多，但是从图中可以看出，Old区并没有存储多少东西，这里使用jstat查看一下发生GC的原因

可以看到引发Full GC 的原因是由于元空间不足发生了扩容引起的，那么下一步优化的思路应该就从元空间入手了

第二次优化

-Xms2048m
-Xmx2048m
-Xmn768m
-XX:ReservedCodeCacheSize=240m
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-Djdk.http.auth.tunneling.disabledSchemes=""
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow
-XX:MetaspaceSize=512m

这次使用-XX:MetaspaceSize参数，将元空间的初始大小改大一些

统计

启动时间：39s
Minor GC：4次耗时0.4s
Full GC：1次耗时0.8s

分析

这次Full GC 只发生了一次，为什么还发生一次，元空间的大小应该是足够了呀！！！本着一次都不能忍的原则，再次使用jstat查看一次引发GC的原因

发现目标，是IDEA启动时代码中使用 System.gc() 触发了这一次的Full GC，我们空间是完全足够的，所以这次Full GC是完全没必要的。干掉它

第三次优化

-Xms2048m
-Xmx2048m
-Xmn768m
-XX:ReservedCodeCacheSize=240m
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-Djdk.http.auth.tunneling.disabledSchemes=""
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow
-XX:MetaspaceSize=512m
-XX:+DisableExplicitGC

这里使用-XX:+DisableExplicitGC参数，将代码中的System.gc()触发的GC给禁用掉，再次看看效果

统计

启动时间：38s
Minor GC：5次耗时0.5s
Full GC：0次耗时 0s

分析

虽然只是优化了1s，但是没有发生Full GC 就很舒服了，好像垃圾收集方面没啥可以搞得了，将目标转向上面的类加载时间，这玩意长，搞他肯定合理，先看一下搞之前的类加载时间

第四次优化

-Xms2048m
-Xmx2048m
-Xmn768m
-XX:ReservedCodeCacheSize=240m
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-Djdk.http.auth.tunneling.disabledSchemes=""
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow
-XX:MetaspaceSize=512m
-XX:+DisableExplicitGC
-Xverify:none

这个优化吧，诚实的讲完全是周大大书上说的，我自己是想不到的，他说是JDK6之后添加的类型检查验证器会影响到以前的类型检查验证器的工作，他调优的是Ecplise，说由于使用人数多，编译代码可以认为肯定是安全可靠的，因此没必要进行字节码验证。狗头一下，那我就说IDEA使用人数甚多，也是很没必要的，咱也禁用（禁用参数 -Xverify:none）

统计

启动时间：35s
Minor GC：5次耗时0.5s
Full GC：0次耗时 0s

分析

事实证明，禁用掉确实很合理，类加载时间从58s优化到46s，到此好像也没啥优化的了，于是我有去网上找了一下可以优化的点，由于没给我带来啥明显的提升，所以就放到一起写了

倒数第一次优化

-Xms2048m
-Xmx2048m
-Xmn768m
-XX:ReservedCodeCacheSize=240m
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-Djdk.http.auth.tunneling.disabledSchemes=""
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow
-XX:MetaspaceSize=512m
-XX:+DisableExplicitGC
-Xverify:none
-XX:+UseNUMA
-Xnoclassgc
-XX:CMSInitiatingOccupancyFraction=75
-XX:CMSFullGCsBeforeCompaction=3

-Xnoclassgc：禁用掉JVM的类的垃圾回收

-XX:+UseNUMA：这个说起来比较复杂，有兴趣参考链接

-XX:CMSInitiatingOccupancyFraction=75：当老年代容量使用到75%时就触发Full GC，默认是92%，因为这里我们使用的是ParNew + CMS的垃圾收集器组合，到达92%再进行清理容易引起CMS由于没有足够的空余位置协助清理造成并发失败，然后会冻结用户的线程（IDEA长时间卡顿的原因）,去使用古老的Serial Old收集器（单线程的哦）进行收集。

-XX:CMSFullGCsBeforeCompaction=3：CMS 是基于标记清除的算法，意味着会产生很多空间碎片，这个参数就是指定发生多少次Full GC对空间做一次压缩整理，默认是0，即每次都整理，有点浪费时间

统计

启动时间：34s
Minor GC：4次耗时0.38s
Full GC：0次耗时 0s

分析

通过启动速度可以看出，上面设置的参数对于启动速度的优化没有多大的提升，这是很正常的，他们的价值还将会体现在IDEA长时间使用的时候。

Q&A

为什么不使用G1收集器？

其实我背地里悄悄的用了，上面最后一次配置，我将CMS换为G1后，时间又长了。。。我的理解应该是G1复杂的记忆集和对写屏障的复杂操作，使得G1消耗更多的计算资源和内存资源，在2GB的内存大小下，与CMS相比并不占优势，在更大的内存下G1的优势才能彻底发挥出来，所以我从一开始就没考虑过G1，一直是针对CMS进行的优化，上面的优化参数也仅仅是针对我电脑下CMS垃圾收集器优化的，如果你想使用G1，按照参考这个思路，针对G1去做一次优化。（纯属个人见解，错误之处请指正）

Java VisualVM、jstat、jps在哪？

jstat、jps 安装完jdk并配置好环境变量后就可以在终端中直接使用，命令形式如上面截图。

Java VisualVM 在jdk根目录的bin文件夹下，如果没有，说明你的jdk版本比较新（起码jdk8后面的了），需要单独去下载

我的 Java VisualVM 连接上后为什么没有你那么多功能？

我的是安装完所有的插件，安装位置工具--插件--可用插件，安装比较慢的（你懂得，科学一下）

还有优化点吗？

有，肯定有。首先肯定是电脑性能问题，这个需要靠钱解决。其次，固态盘比较大的可以考虑放在固态盘中，提升很明显。还有每次JDK、IDEA新版本的发布都会不仅仅是发布新功能，肯定也会有性能的提升，可以考虑换一下新的版本。至于参数的优化方面，肯定是也还有，这能说我这参数达到的我优化的目的，肯定不是最好的，剩下的调优交给时间吧！

这些IDEA的配置要写在那个配置文件中？

我是直接在IDEA中修改的，位置如下：