优化eclipse启动

前言

看了周志明的深入理解java虚拟机后，对虚拟机内部运行有了一定的了解，书中有个例子是关于优化eclipse启动速度的，忍不住手痒来尝试下，同时把过程分享给大家。

作为一个程序猿，对eclipse在熟悉不过了，可谓是日夜陪伴，eclipse的打开与运行速度也时刻影响着工作的热情。下面针对eclipse启动速度进行优化。

 

优化eclipse的步骤

1、 增加插件，查看每次打开时间

2、 查看各部分启动耗时

3、 根据耗时部分去优化

3.1优化jdk

3.2编译时间与类加载优化

3.3gc优化

4、优化完成，查看结果。

准备插件

首先，编写编写一个eclipse启动计时插件，源码及导出的插件如下：

插件下载地址为：http://download.youkuaiyun.com/detail/ll413343176/7866121

把该插件放入到eclipse的plugin下面，重启eclipse即可看到如下提示，可以看到现在eclipse启动耗时8.5s

 

各部分启动耗时

使用Java VisualVM查看各部分启动耗时情况，本工具存在于jdk安装目录下/bin/jvisualvm.exe。jdk1.6以上才会有，打开后按照提示安装上Visual GC插件。

下面为eclipse启动信息截图，可以看到主要耗时为类加载2.4s Full GC 1.8s

 

优化内容

1、 jdk优化

jdk版本比较低的同学先考虑升级下jdk。笔者一直使用1.6，这步就直接掠过。每次jdk更新时都会对执行效率做优化，其他同学可根据自己需求，升级到高版本的jdk。

 

2、 类加载优化

通过多次启动eclipse观察，类加载时间都在2s以上，其中不少时间都消耗在字节码验证部分，考虑到eclipse是可信的，那么此处把字节码验证去掉，在eclipse.ini中增加参数-Xverify:none，此时重新启动，发现类加载时间少了0.5s左右

 

3、 编译优化

此处编译优化指的是JIT编译，即即时编译为本地代码，使用-Xint可以禁止，但结果发现禁止后会大幅度增加启动时间，由此看来JIT运行时编译还是很有必要的。

 

4、 gc优化

在eclipse.ini中增加以下参数

-XX:+PrintGCTimeStamps                 打印gc停顿时间

-XX:+PrintGCDetails         打印gc详细信息

-verbose:gc               打印gc信息

-Xloggc:gc.log          记录gc日志

再次启动后可以在eclipse根目录下产生一个gc.log的文件，打开此文件可以看到每次gc的详细信息。下面摘取其中两次Full GC来分析

 

Full GC 1

4.105: [GC 4.105: [DefNew:2229K->256K(2368K), 0.0022285 secs] 24313K->22517K(32880K), 0.0022588 secs] [Times: user=0.00 sys=0.00, real=0.00secs]

4.153: [GC 4.153: [DefNew:2368K->182K(2368K), 0.0021921 secs] 24629K->22675K(32880K), 0.0022206 secs] [Times: user=0.00 sys=0.00, real=0.00secs]

4.158: [Full GC 4.158: [Tenured:22493K->22689K(30512K), 0.0941863 secs] 22812K->22689K(32880K), [Perm :30463K->30463K(30464K)], 0.0942554 secs] [Times: user=0.09 sys=0.00,real=0.09 secs]

4.301: [GC 4.301: [DefNew:2560K->196K(2880K), 0.0011719 secs] 25249K->22886K(40696K), 0.0011970 secs] [Times: user=0.00 sys=0.00, real=0.00secs]

4.406: [GC 4.406: [DefNew:2737K->254K(2880K), 0.0025144 secs] 25427K->23141K(40696K), 0.0025434 secs] [Times: user=0.00 sys=0.00, real=0.00secs]

 

 

Full GC 2

5.087: [GC 5.087: [DefNew:2817K->320K(2944K), 0.0036476 secs] 26186K->23998K(41172K), 0.0036779 secs] [Times: user=0.00 sys=0.00, real=0.00secs]

5.129: [GC 5.129: [DefNew:2944K->320K(2944K), 0.0037255 secs] 26622K->24808K(41172K), 0.0037595 secs] [Times: user=0.01 sys=0.00, real=0.00secs]

5.179: [Full GC 5.179: [Tenured:24488K->25189K(38228K), 0.1135886 secs] 27275K->25189K(41172K), [Perm :38655K->38655K(38656K)], 0.1136502 secs] [Times: user=0.11 sys=0.00,real=0.11 secs]

5.346: [GC 5.346: [DefNew:2944K->141K(3264K), 0.0014177 secs] 28133K->25330K(45248K), 0.0014476 secs] [Times: user=0.00 sys=0.00, real=0.00secs]

5.392: [GC 5.392: [DefNew:3085K->320K(3264K), 0.0018217 secs] 28274K->25732K(45248K), 0.0018483 secs] [Times: user=0.00 sys=0.00, real=0.00secs]

 

查看上面的日志可以明显发现，Full GC前后整个堆内存都进行了扩展（加粗部分），其他Full GC也类似。那么现在可以确定，eclipse启动时Full GC大多由于堆内存（主要是老年代）扩展引起的，那么现在定死老年代大小，在eclipse启动参数中增加：

-Xms512m

-Xmx512m

-Xmn184m

-XX:MaxPermSize=128m

-XX:PermSize=128m

 

验证

现在已经优化完成，现在重新打开次，看下效果吧。启动时间成功进入5s以内，加载类时间1.25s，年轻代gc 328ms，无full gc，效果显著。小伙伴们，还不赶紧试试