读Java性能权威指南（第2版）笔记26_性能测试方法下

 

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编码实践无关