我的书签
添加书签
移除书签5.3.3 编译时间和类加载时间的优化
从Eclipse启动时间上来看，升级到JDK 1.6所带来的性能提升是……嗯？基本上没有提升？多次测试的平均值与JDK 1.5的差距完全在实验误差范围之内。
各位读者不必失望，Sun JDK 1.6性能白皮书[1]描述的众多相对于JDK 1.5的提升不至于全部是广告，虽然总启动时间没有减少，但在查看运行细节的时候，却发现了一件很值得注意的事情：在JDK 1.6中启动完Eclipse所消耗的类加载时间比JDK 1.5长了接近一倍，不要看反了，这里写的是JDK 1.6的类加载比JDK 1.5慢一倍，测试结果如代码清单5-7所示，反复测试多次仍然是相似的结果。
代码清单5-7 JDK 1.5和JDK 1.6中的类加载时间对比
使用JDK 1.6的类加载时间：
C：\Users\IcyFenix＞jps
3552
6372 org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
6900 Jps
C：\Users\IcyFenix＞jstat-class 6372
Loaded Bytes Unloaded Bytes Time
7917 10190.3 0 0.0 8.18
使用JDK 1.5的类加载时间：
C：\Users\IcyFenix＞jps
3552
7272 Jps
7216 org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
C：\Users\IcyFenix＞jstat-class 7216
Loaded Bytes Unloaded Bytes Time
7902 9691.2 3 2.6 4.34
在本例中，类加载时间上的差距并不能作为一个具有普遍性的测试结果去说明JDK 1.6的类加载必然比JDK 1.5慢，笔者测试了自己机器上的Tomcat和GlassFish启动过程，并未没有出现类似的差距。在国内最大的Java社区中，笔者发起过关于此问题的讨论[2]，从参与者反馈的测试结果来看，此问题只在一部分机器上存在，而且JDK 1.6的各个Update版之间也存在很大差异。
多次试验后，笔者发现在机器上两个JDK进行类加载时，字节码验证部分耗时差距尤其严重。考虑到实际情况：Eclipse使用者甚多，它的编译代码我们可以认为是可靠的，不需要在加载的时候再进行字节码验证，因此通过参数-Xverify：none禁止掉字节码验证过程也可作为一项优化措施。加入这个参数后，两个版本的JDK类加载速度都有所提高，JDK 1.6的类加载速度仍然比JDK 1.5慢，但是两者的耗时已经接近了许多，测试数据如代码清单5-8所示。关于类与类加载的话题，譬如刚刚提到的字节码验证是怎么回事，本书专门规划了两个章节进行详细讲解，在此不再延伸讨论。
代码清单5-8 JDK 1.5和JDK 1.6中取消字节码验证后的类加载时间对比
使用JDK 1.6的类加载时间：
C：\Users\IcyFenix＞jps
5512 org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
5596 Jps
C：\Users\IcyFenix＞jstat-class 5512
Loaded Bytes Unloaded Bytes Time
6749 8837.0 0 0.0 3.94
使用JDK 1.5的类加载时间：
C：\Users\IcyFenix＞jps
4724 org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
5412 Jps
C：\Users\IcyFenix＞jstat-class 4724
Loaded Bytes Unloaded Bytes Time
6885 9109.7 3 2.6 3.10
在取消字节码验证之后，JDK 1.5的平均启动下降到了13秒，而JDK 1.6的测试数据平均比JDK 1.5快1秒，下降到平均12秒左右，如图5-8所示。在类加载时间仍然落后的情况下，依然可以看到JDK 1.6在性能上比JDK 1.5稍有优势，说明至少在Eclipse启动这个测试用例上，升级JDK版本确实能带来一些“免费的”性能提升。
图 5-8 运行在JDK 1.6下取消字节码验证的启动时间
前面说过，除了类加载时间以外，在VisualGC的监视曲线中显示了两项很大的非用户程序耗时：编译时间（Compile Time）和垃圾收集时间（GC Time）。垃圾收集时间读者应该非常清楚了，而编译时间是什么呢？程序在运行之前不是已经编译了吗？虚拟机的JIT编译与垃圾收集一样，是本书的一个重要部分，后面有专门章节讲解，这里先简单介绍一下：编译时间是指虚拟机的JIT编译器（Just In Time Compiler）编译热点代码（Hot Spot Code）的耗时。我们知道Java语言为了实现跨平台的特性，Java代码编译出来后形成的Class文件中存储的是字节码（ByteCode），虚拟机通过解释方式执行字节码命令，比起C/C++编译成本地二进制代码来说，速度要慢不少。为了解决程序解释执行的速度问题，JDK 1.2以后，虚拟机内置了两个运行时编译器[3]，如果一段Java方法被调用次数达到一定程度，就会被判定为热代码交给JIT编译器即时编译为本地代码，提高运行速度（这就是HotSpot虚拟机名字的由来）。甚至有可能在运行期动态编译比C/C++的编译期静态译编出来的代码更优秀，因为运行期可以收集很多编译器无法知道的信息，甚至可以采用一些很激进的优化手段，在优化条件不成立的时候再逆优化退回来。所以Java程序只要代码没有问题（主要是泄漏问题，如内存泄漏、连接泄漏），随着代码被编译得越来越彻底，运行速度应当是越运行越快的。Java的运行期编译最大的缺点就是它进行编译需要消耗程序正常的运行时间，这也就是上面所说的“编译时间”。
虚拟机提供了一个参数-Xint禁止编译器运作，强制虚拟机对字节码采用纯解释方式执行。如果读者想使用这个参数省下Eclipse启动中那2秒的编译时间获得一个“更好看”的成绩的话，那恐怕要失望了，加上这个参数之后，虽然编译时间确实下降到0，但Eclipse启动的总时间剧增到27秒。看来这个参数现在最大的作用似乎就是让用户怀念一下JDK 1.2之前那令人心酸和心碎的运行速度。
与解释执行相对应的另一方面，虚拟机还有力度更强的编译器：当虚拟机运行在-client模式的时候，使用的是一个代号为C1的轻量级编译器，另外还有一个代号为C2的相对重量级的编译器能提供更多的优化措施，如果使用-server模式的虚拟机启动Eclipse将会使用到C2编译器，这时从VisualGC可以看到启动过程中虚拟机使用了超过15秒的时间去进行代码编译。如果读者的工作习惯是长时间不关闭Eclipse的话，C2编译器所消耗的额外编译时间最终还是会在运行速度的提升之中赚回来，这样使用-server模式也是一个不错的选择。不过至少在本次实战中，我们还是继续选用-client虚拟机来运行Eclipse。
[1]http://www.oracle.com/technetwork/java/6-performance-137236.html。
[2]关于JDK 1.6与JDK 1.5在Eclipse启动时类加载速度差异的讨论：http://www.iteye.com/topic/826542。
[3]JDK 1.2之前也可以使用外挂JIT编译器进行本地编译，但只能与解释器二选其一，不能同时工作。
