清单2 循环中包含不变式

int A = 1; 　 int B = 2; 　 int sum = 0; 　 int invariant = A + B; 　 for (int i =　0; i < someThing; i++) sum += invariant;

Java 6中的线程优化真的有效么？——第二部分(3)

清单3 不变式已抽取到循环之外

这些优化真的应该允许么？还是我们应该做一些事情防止它的发生？这个有待 商榷。但至少，我们应该知道是否应用了这些优化。我们绝对要避免“死代码消 除”这种优化的出现，否则它会彻底扰乱我们的测试！Hotspot能够识别出我们没 有使用concatBuffer和concatBuilder操作的结果。或者可以说，这些操作没有边 界效应。因此没有任何理由执行这些代码。一旦代码被标识为已“死亡”，JIT就 会除去它。好在我的基准测试迷惑了Hotspot，因此它并没有识别出这种优化，至 少目前还没有。

如果由于锁的存在而抑制了内联，反之没有锁就可能出现内联，那么我们要确 保在测试结果中没有包含额外的方法调用。现在可以用到的一种技术是引入一个 接口（清单4）来迷惑Hotspot。

public interfaceConcat { 　　 String concatBuffer(String s1, String s2, String s3); 　　 String concatBuilder(String s1, String s2, String s3); public class LockTest implements Concat { ...}

清单4 使用接口防止方法内联

防止内联的另一种方法是使用命令行选项-XX:-Inline。我已经验证，方法内 联并没有给基准测试的报告带来任何不同。

执行栈输出

最后，请看下面的输出结果，它使用了下面的命令行标识。

>java -server -XX:+DoEscapeAnalysis -XX:+PrintCompilation -XX:+EliminateLocks -XX:+UseBiasedLocking -XX:+TraceBiasedLocking LockTest

图1 基准测试的执行栈输出

JVM默认会启动12个线程，包括：主线程、对象引用处理器、Finalize、 Attach******等等。上图中第一个灰色段显示的是这些线程的对齐，它们可以使 用偏向锁（注意所有地址都以00结尾）。你尽管忽略可以忽略它们。接下来的黄 色段包含了已编译方法的信息。我们看一下第5行和12行，能够发现它们都标记了 一个额外的“s”。表1的信息告诉我们这些方法都是同步的。包含了“%”的各行 已经使用了OSR。红色的行是偏向锁被激活的地方。最底下的蓝绿色框是基准测试 开始计时的地方。从记录基准测试开始时间的输出中可以看到，所有编译都已经 发生了。这说明前期的预热阶段足够长了。如果你想了解日志输出规范的更多细 节，可以参考这个页面和这篇文章。

表1 编译示例码

Java 6中的线程优化真的有效么？——第二部分(4)

单核系统下的结果

尽管我的多数同事都在使用Intel Core 2 Duo处理器，但还是有一小部分人使 用陈旧的单核机器。在这些陈旧的机器上，StringBuffer基准测试的结果和 StringBuilder实现的结果几乎相同。由于产生这种不同可能是多种因素使然，因 此我需要另外一个测试，尝试忽略尽可能多的可能性。最好的选择是，在BIOS中 关闭Core 2 Duo中的一个核，然后重新运行基准测试。运行的结果如图2所示。

图2 单核系统的性能

在多核环境下运行的时候，关闭了三种优化行为后获得了一个基准值。这

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!