1.理解可变性

1.1.理解测试结果如何随时间变化

1.2.可以通过多次运行测试后取平均值来解决

1.3.因代码改进而进行的测试叫作回归测试（regression testing）

  • 1.3.1.原本的代码叫作基线（baseline）

  • 1.3.2.新的代码叫作样本（specimen）

1.4.结果的变化越大，越难判断平均值的差异是由于真正的性能问题还是随机变化

1.5.正确判断两个测试的结果是否有差异需要进行一定程度的统计分析，以确保感知到的差异不是随机波动造成的

  • 1.5.1.要进行严谨的统计分析，可以使用T检验比较测试结果

  • 1.5.2.检验的结果表示出现性能倒退的概率，但是它并不能显示出哪些倒退应该忽略，哪些应该追踪。在这两者间找到平衡是一种性能工程艺术

2.早测试、常测试

2.1.性能测试作为开发周期中的必要部分

2.2.早期测试带来的问题

  • 2.2.1.受发布时间的限制，开发人员需要尽快检入代码

  • 2.2.2.代码的性能特征会随着代码的变化而变化

2.3.自动化一切

  • 2.3.1.所有的性能测试都应该脚本化（或者程序化，不过脚本化通常更容易）

2.4.测量一切

  • 2.4.1.自动化必须收集可以想到的每一份数据，以便用于以后的分析

2.5.在目标系统上运行

  • 2.5.1.很多重要的调优标志会基于JVM运行的底层硬件系统，计算出它们的默认值

  • 2.5.2.不同平台的代码编译方式不同

  • 2.5.3.软件缓存和更重要的硬件缓存，在不同的系统和不同的负载下的表现也不同

3.jmh提供微基准测试

3.1.适用于纳（nano）/微（micro）/毫（milli）/宏（macro）等规模的基准测试

3.2.随着Java 9一起发布的

  • 3.2.1.组成jmh的类库兼容JDK 8及之后的版本

  • 3.2.2.并没有与任何具体的Java版本绑定

  • 3.2.3.JDK中没有支持jmh的工具

3.3.Blackhole类是jmh的特性

  • 3.3.1.解决了微基准测试的一个重要问题：如果一个操作的值没有用到，那么编译器会直接优化这个操作

  • 3.3.2.所以把值传递给Blackhole的consume()方法可以确保值被使用

3.4.Setup注解的Level值

  • 3.4.1.Level.Trial

    • 3.4.1.1.在基准测试代码初始化时执行一次

  • 3.4.2.Level.Iteration

    • 3.4.2.1.在基准测试每次迭代前完成（每个测量期）

  • 3.4.3.Level.Invocation

    • 3.4.3.1.在每次测试方法执行之前完成

3.5.-f 5

  • 3.5.1.派生试验的运行次数（默认为5）

3.6.-wi 5

  • 3.6.1.每次试验的预热迭代次数（默认为5）

3.7.-i 5

  • 3.7.1.每次试验的测量迭代次数（默认为5）

3.8.-r 10

  • 3.8.1.每次迭代的最少时间（以秒为单位）

  • 3.8.2.迭代的时间可能比这个时间长，具体取决于目标方法的实际执行时间

3.9.对于更稳定的测试，降低这些参数的值一般可以缩短运行测试所需的时间

3.10.通常让Java代码变得更好、更快的方法是写出更好的算法，但这个实现与任何Java调优实践或者Java编码实践无关