【IT168 分析评论】Brent Boyer是Elliptic Group的一名程序员，他在IBM开发者网站上发表了一篇名为“健壮的Java基准(Robust Java Benchmarking)”的文章。这篇文章包含两个部分，主要探究了如何实现有效的Java基准。首先，他论述了当前编译器下不同JVM有着不同的特性和优化，而这些特性或是优化有可能会对性能测试产生负面影响。举例来说，假如有一段复杂的代码段，最后计算得到的是一个从未使用的值，那么强势编译器就会对这段代码进行优化，基准则会忽略这段计算。为了说明这一点，他在他哦个一台计算机上连续运行了很多次相同的代码段，结果运行时都是4.9秒，但当他删除了打印结果的println 语句之后，运行时间则缩短到0.08秒。他还指出，时间度量的粒度在不同的操作系统下是不一样的，因此在基准测试的时候，一定要弄清楚当前系统的时间度量粒度。他说，和System.nanoTime()相比，System.currentTimeMillis()就不是一个度量运行时间的好方法()，因为它在Windows XP上只有15ms的精度(但在具有2.6内核的Linux上却可以达到1ms的精度)。

　　在阐述了这些特别的行为之后，Boyer提到了一些在做典型的基准测试时容易忽略的一些问题，比如JVM缓存、资源回收(如垃圾收集、对象清理)。他认为避免这些问题的唯一有效方式是“预热(warm up)”代码直到代码达到一个稳定态。“预热”过程很耗时间并且很具挑战，因为有些JVM在其触发编译之前可能已经将一个函数执行了10,000次(但在编译触发前，代码还处于解析状态)。代码达到稳定状态之后，基准必须对这段代码运行多次，然后才能对结果做出有效的统计分析。

　　此外，Boyer还建议采用基准框架来做基准测试，他本人就编写了这样一个框架。该框架能够展示以不同数目的元素来访问数据结构(原生数组、 ArrayLists、Vectors、HashMap、TreeMap等等)中的数据的差异。Boyer向大家展示了两个有趣的分析结果：(1)即使运行时短暂到以纳秒计数，其基准框架仍能计算出平均访问时间。(2)不同负载下，某些数据结构的反应令人非常吃惊。其中一个特别的例子是 ConcurrentHashMaps与TreeMap的比较：在同样拥有1024个元素时，CurrentHashMaps的表现要远远好于 TreeMap，但当元素数量上升到1024x1024的时候，两者表现就相差不大。这很出乎意料，因为hash map的搜索时间是常量，但trees的搜索时间却是log(n)。除却这些令人吃惊的奇怪的结果，这篇文章还是非常值得一读的，尤其是在对Java代码进行基准评测时，Boyer提出的建议还是值得参考的。