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