追加：首先要声明一下，这个案例在<深入理解JVM虚拟机>这本书中也提到过。这本书是我曾经学习JVM的第一本书。里面关于Heap的优化思想，来源于此。建议大家想学JVM原理的，可以找来此书看看。 写这篇文章，是因为最近在给一个社交网站服务器做调优，突然觉得我机器上的eclipse跑的比较多，所以顺便优化下eclipse。至于基于WebSphere服务器的性能调优，这回涉及到更多的工具和方法，会在以后的文章中看到。

　　最近自从eclipse安装了很多插件以后，启动变得非常的慢，每次启动，要消耗近半分钟。这是不正常的。 今天决定好好优化一下。

　　我所使用的eclipse是Eclipse Java EE IDE for Web Developers 3.8版本。跑在MAC OSX上， SSD+8G RAM， 这么高性能的机器竟然不能秒开eclipse， 这太说不过去了。哦，还有我使用的JVM是Oracle的HotSpot，来自于JDK1.6 64bit。

　　首先，在优化前，让我们看看eclipse启动时，JVM的各项性能指标。因为我并不能准确的判定eclipse的启动完成时间，所以我只能说大约事件.

　　首先启动JDK自带的JVM性能监视工具，在java\bin的目录下，有一个jvisualvm，它是绑定在JDK中的visualvm，双击启动 visualvm。然后启动eclipse，在eclipse启动完成以后，使用visualvm的查看eclipse的Visual GC情况，如图：

　　上图中说明在eclipse的启动过程中，JIT对字节码进行了向机器码的编译，花去了22秒的时间。Class加载花去了10秒的时间，Minor GC发生了72次，花去0。64秒，Full GC发生了12次，仅仅花去了61毫秒。

　　我们再去MBean选项查看，发现新生代使用ParNew垃圾收集器，而老年代使用的是CMS垃圾收集器。

　　总上情况看出，由于MAC的性能比较好，所以垃圾回收并没有消耗太多的时间，并且CMS+ParNew本身就是并行垃圾回收，不会造成用户程序太多的停顿。 时间主要消耗在了JIT的即时编译和Class加载上了。

　　首先要优化的就是class加栽。因为eclipse这个工具是一个成熟的工具，经过了这么多人的验证，所以我充分信任eclipse的代码，允许 eclipse的代码在加载的时候，跳过字节码验证。关闭字节码验证的方法是在vm的args中加入参数 -Xverify：none。对于eclipse来说，找到eclipse.ini，加入-Xverify：none。让我们再重启一下eclipse，看看class加载时间是否减小。再次启动，发现class加载事件缩小到7秒，比之前少了3秒。

　　然后优化的是JIT的时间。在使用eclipse编写程序时，主要是文本编辑，编译和运行，JIT虽然可以带给我们高性能，但是JIT在编译机器码的时候，却要消耗很多的时间。eclipse对项目的编译和运行本身就很慢，切运行时是启动一个新的java进程，跟eclipse本身无关，所以，我可以接受抛弃JIT编译器，而只是用JVM解释器执行字节码所带来的效率降低。这样可以去除JIT编译的时间。做法如下，在eclipse。ini中加入vm的参数 -Xint，意思是只使用解释器。让我们来看看结果：

　　JVM编译器时间变成了0，一下减掉20秒。但是，由于缺少了运行时的即时编译优化方案，代码的运行时间变长了，eclipse的整体启动时间慢了更多，超过了30秒。由此可见，JIT是多么有用的一项技术。所以禁止JIT的尝试失败了。我们把之前的参数-Xint去掉。

　　哦，对了，我还装了很多的插件，尤其是android开发插件。启动的时候对插件的激活也会花去很多时间。屏蔽插件激活的方法：Windows -> Preferences， 输入 “startup”，点击 “Startup and Shutdown”，把不需要的插件勾掉。此外，还需要关掉不必要的validation，方法为：Windows -> Preferences -> Validation，只选你需要的。