原文地址译者：郭蕾 校对：丁一
本文是Java HotSpot VM and just-in-time(JIT) compilation系列的第一篇。
Java HotSpot虚拟机是Oracle收购Sun时获得的，JVM和开源的OpenJDK都是以此虚拟机为基础发展的。如同其它虚拟机，HotSpot虚拟机为字节码提供了一个运行时环境。实际上，它主要会做这三件事情：
- 执行方法所请求的指令和运算。
- 定位、加载和验证新的类型（即类加载）。
- 管理应用内存。
最后两点都是各自领域的大话题，所以这篇文章中只关注代码执行。
JIT编译
Java HotSpot是一个混合模式的虚拟机，也就是说它既可以解释字节码，又可以将代码编译为本地机器码以更快的执行。通过配置-XX:+PrintCompilation参数，你可以在log文件中看到方法被JIT编译时的信息。JIT编译发生在运行时 —— 方法经过多次运行之后。到方法需要使用到的时候，HotSpot VM会决定如何优化这些代码。
如果你好奇JIT编译带来的性能提升，可以使用-Djava.compiler=none将其关掉然后运行基准测试程序来看看它们的差别。
Java HotSpot虚拟机可以运行在两种模式下：client或者server。你可以在JVM启动时通过配置-client或者-server选项来选择其中一种。两种模式都有各自的适用场景，本文中，我们只会涉及到server模式。
两种模式最主要的区别是server模式下会进行更激进的优化 —— 这些优化是建立在一些并不永远为真的假设之上。一个简单的保护条件(guard condition)会验证这些假设是否成立，以确保优化总是正确的。如果假设不成立，Java HotSpot虚拟机将会撤销所做的优化并退回到解释模式。也就是说Java HotSpot虚拟机总是会先检查优化是否仍然有效，不会因为假设不再成立而表现出错误的行为。
在server模式下，Java HotSpot虚拟机会默认在解释模式下运行方法10000次才会触发JIT编译。可以通过虚拟机参数-XX:CompileThreshold来调整这个值。比如-XX:CompileThreshold=5000会让触发JIT编译的方法运行次数减少一半。(译者注：有关JIT触发条件可参考《深入理解Java虚拟机》第十一章以及《Java Performance》第三章HotSpot VM JIT Compilers小节)
这可能会诱使新手将编译阈值调整到一个非常低的值。但要抵挡住这个诱惑，因为这样可能会降低虚拟机性能，优化后减少的方法执行时间还不足以抵消花在JIT编译上的时间。
当Java HotSpot虚拟机能为JIT编译收集到足够多的统计信息时，性能会最好。当你降低编译阈值时，Java HotSpot虚拟机可能会在非热点代码的编译中花费较多时间。有些优化只有在收集到足够多的统计信息时才会进行，所以降低编译阈值可能导致优化效果不佳。
另外一方面，很多开发者想让一些重要方法在编译模式下尽快获得更好的性能。
解决此问题一般是在进程启动后，对代码进行预热以使它们被强制编译。对于像订单系统或者交易系统来说，重要的是要确保预热不会产生真实的订单。
Java HotSpot虚拟机提供了很多参数来输出JIT的编译信息。最常用的就是前文提到的PrintCompilation，也还有一些其它参数。
接下来我们将使用PrintCompilation来观察Java HotSpot虚拟机在运行时编译方法的成效。但先有必要说一下用于计时的System.nanoTime()方法。
计时方法
Java为我们提供了两个主要的获取时间值的方法：currentTimeMillis()和nanoTime().前者对应于我们在实体世界中看到的时间(所谓的钟表时间)，它的精度能满足大多数情况，但不适用于低延迟的应用。
纳秒计时器拥有更高的精度。这种计时器度量时间的间隔极短。1纳秒是光在光纤中移动20CM所需的时间，相比之下，光通过光纤从伦敦传送到纽约大约需要27.5毫秒。
因为纳秒级的时间戳精度太高，使用不当就会产生较大误差，因此使用时需要注意。
如，currentTimeMillis()能很好的在机器间同步，可以用于测量网络延迟，但nanoTime()不能跨机器使用。
接下来将上面的理论付诸实践，来看一个很简单(但极其强大)的JIT编译技术。
方法内联
方法内联是编译器优化的关键手段之一。方法内联就是把方法的代码“复制”到发起调用的方法里，以消除方法调用。这个功能相当重要，因为调用一个小方法可能比执行该小方法的方法体耗时还多。
JIT编译器可以进行渐进内联，开始时内联简单的方法，如果可以进行其它优化时，就接着优化内联后的较大的代码块。
Listing1，Listing1A以及Listing1B是个简单的测试，将直接操作字段和通过getter/setter方法做了对比。如果简单的getters和setters方法没有使用内联的话，那调用它们的代价是相当大的，因为方法调用比直接操作字段代价更高。
Listing1:
02 |
private static double timeTestRun(String desc, int runs, |
03 |
Callable<Double> callable) throws Exception { |
04 |
long start = System.nanoTime(); |
06 |
long time = System.nanoTime() - start; |
07 |
return (double) time / runs; |
11 |
private static long uptime() { |
12 |
return ManagementFactory.getRuntimeMXBean().getUptime() + 15; |
16 |
public static void main(String... args) throws Exception { |
18 |
for (int i : new int[] |
19 |
{ 100, 1000, 5000, 9000, 10000, 11000, 13000, 20000, 100000} ) { |
20 |
final int runs = i - iterations; |
26 |
Callable<Double> directCall = new DFACaller(runs); |
27 |
Callable<Double> viaGetSet = new GetSetCaller(runs); |
29 |
double time1 = timeTestRun("public fields", runs, directCall); |
30 |
double time2 = timeTestRun("getter/setter fields", runs, viaGetSet); |
32 |
System.out.printf("%7d %,7d\t\tfield access=%.1f ns, getter/setter=%.1f ns%n", |
33 |
uptime(), iterations, time1, time2); |
Listing1A:
01 |
public class DFACaller implements Callable<Double>{ |
02 |
private final int runs; |
04 |
public DFACaller(int runs_) { |
09 |
public Double call() { |
10 |
DirectFieldAccess direct = new DirectFieldAccess(); |
12 |
for (int i = 0; i < runs; i++) { |
20 |
public class DirectFieldAccess { |
Listing1B:
01 |
public class GetSetCaller implements Callable<Double> { |
02 |
private final int runs; |
04 |
public GetSetCaller(int runs_) { |
09 |
public Double call() { |
10 |
ViaGetSet getSet = new ViaGetSet(); |
12 |
for (int i = 0; i < runs; i++) { |
13 |
getSet.setOne(getSet.getOne() + 1); |
14 |
sum += getSet.getOne(); |
20 |
public class ViaGetSet { |
27 |
public void setOne(int one) { |
如果使用java -cp. -XX:PrintCompilation Main 运行测试用例，就能看到性能上的差异(见Listing2)。
Listing2
31 1 java.lang.String::hashCode (67 bytes)
36 100 field access=1970.0 ns, getter/setter=1790.0 ns
39 2 sun.nio.cs.UTF_8$Encoder::encode (361 bytes)
42 3 java.lang.String::indexOf (87 bytes)
141 1,000 field access=16.7 ns, getter/setter=67.8 ns
245 5,000 field access=16.8 ns, getter/setter=72.8 ns
245 4 ViaGetSet::getOne (5 bytes)
348 9,000 field access=16.0 ns, getter/setter=65.3 ns
450 5 ViaGetSet::setOne (6 bytes)
450 10,000 field access=16.0 ns, getter/setter=199.0 ns
553 6 Main$1::call (51 bytes)
554 7 Main$2::call (51 bytes)
556 8 java.lang.String::charAt (33 bytes)
556 11,000 field access=1263.0 ns, getter/setter=1253.0 ns
658 13,000 field access=5.5 ns, getter/setter=1.5 ns
760 20,000 field access=0.7 ns, getter/setter=0.7 ns
862 100,000 field access=0.7 ns, getter/setter=0.7 ns
这些是什么意思？Listing2中的第一列是程序启动到语句执行时所经过的毫秒数，第二列是方法ID(编译后的方法)或遍历次数。
注意：测试中没有直接使用String和UTF_8类，但它们仍然出现在编译的输出中，这是因为平台使用了它们。
从Listing2中的第二行可以发现，直接访问字段和通过getter/setter都是比较慢的，这是因为第一次运行时包含了类加载的时间，下一行就比较快了，尽管此时还没有任何代码被编译。
另外要注意下面几点：
- 在遍历1000和5000次时，直接操作字段比使用getter/setter方法快，因为getter 和setter还没有内联或优化。即便如此，它们都还相当地快。
- 在遍历9000次时，getter方法被优化了(因为每次循环中调用了两次)，使性能有小许提高。
- 在遍历10000次时，setter方法也被优化了，因为需要额外花费时间去优化，所以执行速度降下来了。
- 最终，两个测试类都被优化了：
- DFACaller直接操作字段，GetSetCaller使用getter和setter方法。此时它们不仅刚被优化，还被内联了。
- 从下一次的遍历中可以看到，测试用例的执行时间仍不是最快的。
- 在13000次遍历之后，两种字段访问方式的性能都和最后更长时间测试的结果一样好，我们已经达到了性能的稳定状态。
需要特别注意的是，直接访问字段和通过getter/setter访问在稳定状态下的性能是基本一致的，因为方法已经被内联到GetSetCaller中，也就是说在viaGetSet中所做的事情和directCall中完全一样。
JIT编译是在后台进行的。每次可用的优化手段可能随机器的不同而不同，甚至，同个程序的多次运行期间也可能不一样。
总结
这篇文章中，我所描述的只是JIT编译的冰山一角，尤其是没有提到如何写出好的基准测试以及如何使用统计信息以确保不会被平台的动态性所愚弄。
这里使用的基准测试非常简单,不适合做为真实的基准测试。在第二部分，我计划向您展示一个真实的基准测试并继续深入JIT编译的过程。
