Java理论和实践: 一个有缺陷的微基准的剖析 - 编程入门网
| 那以后无竞争的同步的性能从本质上已经有了很大的提高。（请参阅参考资料中列出的描述 JVM 用来优化无竞争同步性能的一些技术的文章）。另一方面，有竞争的同步比起无竞争同步来仍然要慢得多。当一个锁处于争用状态下时，JVM 不但要维护一个等待线程队列，而且还必须使用系统调用来阻塞和消除阻塞不能立即得到锁的线程。而且，在高度竞争环境下的应用程序表现出来的吞吐量通常会更低，这不仅是因为花在调度线程上的时间更多了，花在做实际工作上的时间更少了，而且当线程为了等待某一个锁而被阻塞时，CPU 可能处于空闲状态。用来度量同步性能的基准应该考虑实际的竞争程度。
方法上的缺陷 除了设计上的失败，在执行方面至少也有两大败笔 —— 它只在单处理器系统（对于高并发性程序来说，这是一种不寻常的系统，其同步性能与在多处理器系统上可能有本质上的差别）上，并且只在一个平台上执行。在测试一个给定的原语或惯用语的时候，特别是与底层硬件交互很多的原语或惯用语时，在得出关于性能方面的结论之前，需要在很多平台运行基准。当测试像并发这样复杂的东西时，为了得到给定惯用语的总体性能情况，建议采用十来种不同的系统，应用多个处理器（更不用说内存配置和处理器的代数（generation）了）。 实现上的缺陷 至于实现方面，SyncLockTest 忽略了动态编译的很多方面。在12 月份的文章中可以看到，HotSpot JVM 首先以解释的方式执行代码路径，然后在经过一定量的执行后，才将其编译成机器代码。如果没有让 JVM 适当地“热身”，那么 JVM 可能在两个方面导致性能度量上的偏差。首先，测试的运行时间当中包含了 JIT 用于分析和编译代码路径所花的时间。最重要的是，如果编译是在测试运行的过程当中进行的，那么测试结果就变成一定量的解释执行，加上 JIT 编译时间，再加上一定量的优化执行的总时间和，这些并不能让您清楚代码的真正性能。而且，如果在运行测试之前代码没有经过编译，在测试的过程当中也没有进行编译，那么整个测试运行都需要解释，这样就不能体现所要测试的惯用语的真正性能。 SyncLockTest 还沦为在12 月份的文章中所讨论的内联（inlining）和反优化（deoptimization）问题的牺牲品，在这些篇文章中，第一个计时度量的是那些已经与单一调用转换（monomorphic call transformation）内联的代码，而第二个计时所度量的代码，由于 JVM 要装载另一个扩展相同基类或接口的类，因而经过了反优化。当使用 SyncIncrementer 的一个实例来调用计时测试方法时，运行库将认为只装载了一个实现 Incrementer 的类，并且会把对 increment() 的虚方法调用转换为对 SyncIncrementer 的调用。然后，当使用 LockIncrementer 的一个实例调用计时测试方法时，test() 将被重新编译成使用虚方法调用，这意味着与第一个计时相比，通过 test() 来管理方法的第二个计时在每次迭代中要做更多的工作，就好像把测试变成了苹果与橙子之间的比较。这样做会严重扭曲结果，致使无论哪种基准首先执行，看起来都会更快些。 基准代码看上去并不像实际中的代码 通过合理地重写代码，引入一些测试参数（例如竞争程度），并在更多类型的系统中、给测试参数赋予多种不同的值来运行代码，前面所讨论的那些缺陷是可以更正的。但是，对于方法上的一些缺陷，不管如何挽回，都是无法解决的。如果想知道为什么，就应该像 JVM 那样去思考，理解在编译 SyncLockTest 的时候会发生哪些情况。 Heisenbenchmark 原则 编写用于度量一个语言原语（例如同步）的性能的微基准的过程实际上是与 Heisenberg 原则作斗争的过程。您想要度量操作 X 有多快，所以除了 X 外您不想做其他任何事。但是，这样做得到的往往是一个不做任何事的基准，在您不 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
