前言
看了周志明的深入理解java虚拟机后，对虚拟机内部运行有了一定的了解，书中有个例子是关于优化eclipse启动速度的，忍不住手痒来尝试下，同时把过程分享给大家。
作为一个程序猿，对eclipse在熟悉不过了，可谓是日夜陪伴，eclipse的打开与运行速度也时刻影响着工作的热情。下面针对eclipse启动速度进行优化。
优化eclipse的步骤
1、 增加插件，查看每次打开时间
2、 查看各部分启动耗时
3、 根据耗时部分去优化
3.1优化jdk
3.2编译时间与类加载优化
3.3gc优化
4、优化完成，查看结果。
准备插件
首先，编写编写一个eclipse启动计时插件，源码及导出的插件如下：
插件下载地址为：http://download.csdn.net/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，效果显著。小伙伴们，还不赶紧试试
