【jvm实战】IDEA运行速度调优
2017-11-15 17:32
330 查看
1.个人电脑配置
CPU:Intel Core i7-7700HQ 2.80GHzRAM:16.0G
OS:windows10 64位
2.IDEA启动速度优化
打开ides安装目录里的bin文件夹,打开idea.exe.vmoptions(64位的叫idea64.exe.vmoptions)看到的是idea安装完成后默认的VM参数配置(其实里面还有一些其他的配置,最好不要动它们):-Xms128m
-Xmx512m
-XX:ReservedCodeCacheSize=240m
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow
这个配置下,idea的启动时间大概是20s,下面是启动完成时VisualVM里的截图:
可以看到:发生Minor GC 103次,共719.084ms,Major GC 14次,共442.858ms,个人觉得默认配置下已经运行的比较流畅了。
顺便提一下,可用以下命令来输出一个名为gclog.log的gc日志来查看各种GC的详细信息
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails
-Xloggc:gclog.log
继续,我们可以尝试一下把堆内存降低一下:
-Xms128m
-Xmx256m
-XX:ReservedCodeCacheSize=240m
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow
这次idea的启动时间大概是21s,启动完成时VisualVM里的截图:
可以看到执行Major GC 41次,一共3.4秒,这就是老年代内存不足导致频繁执行FULL GC的结果.
最后看看我调大堆内存的运行结果,配置如下:
-Xms1024m
-Xmx2048m
-XX:ReservedCodeCacheSize=240m
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow
启动时间19s,结果:
这次的运行结果是最理想的Minor GC和Major GC的次数都降下来了.
老年代扩容的时候也会导致FULL GC,我把最小堆调到与最大堆一样,另外idea运行时可能会时不时执行一下System,gc()来进行FULL GC,通过-XX:+DisableExplicitGC来禁止此操作。最后我发现无论堆内存设成多大,FULL GC还是会有那么几次,个人猜测是metaspace区(JDK1.8之前是perm区)内存不够进行扩容时导致的,于是把metaspace的初始值调成512m:
-Xms2048m
-Xmx2048m
-XX:+DisableExplicitGC
-XX:MetaspaceSize=512m
-XX:ReservedCodeCacheSize=240m
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow
运行结果启动用了18.8s
可以看到Full GC的次数在启动完成时是0了
继续优化,IDEA使用者较多,它的编译代码我们可以认为是可靠的,不需要在加载的时候再进行字节码验证,用-Xverify:none参数可以禁止掉字节码验证:
-Xms2048m
-Xmx2048m
-Xverify:none
-XX:+DisableExplicitGC
-XX:MetaspaceSize=512m
-XX:ReservedCodeCacheSize=240m
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow
运行结果启动用了17.6s
修改前的类加载时间为38.41s
修改后为31.70s
3.IDEA运行期间优化
IDEA默认给我们配置了GC收集器是并行的CMS(-XX:+UseConcMarkSweepGC这个参数可以看出),它默认搭配的新生代收集器是ParNew(-XX:+UseParNewGC),由于我个人电脑CPU还是挺强力的,而且开发时也不会打开太多其他乱七八糟的应用,所以按默认配置就可以了,如果CPU配置比较低,而且CPU占用率大的用户,可以考虑改用串行的GC收集器相关文章推荐
- 优化JVM参数提高eclipse运行速度及Java垃圾收集调优实战
- 6.调优实战-优化idea启动速度
- Spark入门实战系列--6.SparkSQL(中)--深入了解SparkSQL运行计划及调优
- Spark入门实战系列--6.SparkSQL(中)--深入了解SparkSQL运行计划及调优
- Spark入门实战系列--6.SparkSQL(中)--深入了解SparkSQL运行计划及调优
- JVM调优实战6
- JVM之调优案例分析与实战
- JVM调优实战
- JVM调优实战
- JVM调优案例分析与实战:高性能硬件上的程序部署策略
- Jvm 调优实战
- Jvm运行参数与调优(整理/划重点)
- Jvm 调优实战
- JVM 性能调优实战之:使用阿里开源工具 TProfiler 在海量业务代码中精确定位性能代码
- 一次JVM调优实战
- 实战6.SparkSQL(中)--深入了解SparkSQL运行计划及调优
- JVM笔记——调优案例分析与实战
- 《高性能Linux服务器构建实战:运维监控、性能调优与集群应用》 1.7.2 Nginx+FastCGI运行原理
- JVM调优之---一次GC调优实战
- Jvm 调优实战