Java理论和实践: 一个有缺陷的微基准的剖析 - 编程入门网
| 少次迭代取决于循环体中有多少代码，而 LockIncrementer.increment() 的循环体中的代码比 SyncIncrementer.increment() 的循环体中的代码“更多”。而且，当展开 SyncIncrementer.increment() 并内联该方法调用时，已展开循环的顺序将是“锁-递增-解锁”这样的顺序。由于这些都是同一个监视器上的锁，因此编译器可以执行锁合并（也叫锁粗化），将邻近的 synchronized 块合并，这意味着 SyncIncrementer 执行的同步将比预期的还要少。（更糟糕的还在后面；在合并锁之后，同步的代码块中只包含一个递增序列，因而可以降低强度，转换成一个单独的相加。而且，如果重复应用这个过程，整个循环将缩水成一个单独的同步块，这个同步块中只有一个 "counter=10000000" 操作。的确，现实中的 JVM 是可以执行这些优化的。）
同样，严格来说，问题并不在于优化器会优化掉我们的基准，而是优化器对于不同的基准会采用不同程度的优化，并且它对于每种基准所应用的优化在实际代码中很可能根本不适用。 有缺陷的评价标准 这里说得不够详尽，但是对于为什么这个基准没有像其作者期望的那样这个问题，这里给出了一些原因： 没有进行热身（warmup），没有考虑 JIT 执行所花的时间。 测试容易受到由单一调用转换引起的错误以及随后的反优化的影响。 受同步块或 ReentrantLock 保护的代码实际上是无用的，这扭曲了 JIT 优化代码的方式。编译器可能可以消除整个同步测试。 测试程序想要度量一个锁原语的性能，但是它在这样做的时候，没有考虑到竞争的影响，并且只是在一个单处理器系统上进行测试的。 没有在足够多类型的平台上运行测试程序。 编译器对同步测试的优化比对 ReentrantLock 测试的优化要更多一些，但是这种优化又不适用于现实当中使用同步的程序。 错误的问题，错误的答案 关于微基准，令人恐慌的事情是它总是产生一个数字，即使这个数字毫无意义。这些基准在度量某个事物，但我们又不确定这个事物到底是什么。通常，它们只度量特定微基准的性能，别无它物。但是您很容易误认为您的基准在度量一个特定结构体的性能，并错误地对结构体的性能下结论。 即使您编写了一个很好的基准，得到的结果可能也只是在运行基准的系统上才有效。如果在一个内存不足的单处理器手提电脑系统上进行测试，那么您恐怕不能对一个服务器系统上的性能下任何结论。至于低级硬件并发原语的性能，不同的硬件体系结构之间更是千差万别。 实际上，企图单凭一个数字来度量“同步性能”之类的东西是不可能的。同步性能会随着 JVM、处理器、工作负载、JIT 活动、处理器数量以及正同步执行的代码的数量和特征而变化。您最好是在一系列不同的平台上运行一系列的基准，然后寻找结果中的相似之处。只有这样，您才可以对同步的性能下结论。 在 JSR 166 (java.util.concurrent) 测试过程的基准运行中，性能曲线的形状随平台的不同而不同。硬件结构体（例如 CAS）的成本随平台和处理器数量的不同而不同（例如，单处理器系统不存在 CAS 调用）。一个超线程（一个模具上有两个处理器核心）Intel P4 的内存壁垒性能（memory barrier performance）要快于两个 P4，而两者的性能特征又不同于 Sparc。因此，您最好是尝试建立一些“典型”例子，然后将它们放在“典型”硬件上运行，并希望这样能在一定程度上揭示现实中的程序在现实中平台上的性能。那么，用什么构成一个“典型”例子呢？它的计算、IO、同步和竞争，它的内存局部性、分配行为、上下文切换、系统调用以及线程间通信都必须与现实当中的应用程序近似。也就是说，一个逼真的基准看上去非常像现实中的程序。 如何编写好的微基准 那么，如何编写好的微 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
