1. 测试真实的应用程序
1.1. 应该以实际产品的使用方式进行测试
1.2. 所有的基准测试通常都包括一个预热期，在这期间，JVM可以将代码编译到最佳状态
1.3. 微基准测试（microbenchmark）
1.3.1. 通过测量一小部分代码的性能来确定多种实现中哪个最好
-
1.3.2. 必须读取测试的结果
1.3.2.1. 从局部变量改为实例变量（用volatile关键字进行声明）即可测量这个方法的性能
1.3.2.2. 即使微基准测试是单线程的，也需要使用volatile变量
-
1.3.3. 必须测试一系列的输入值
- 1.3.3.1. 最好提前算好输入值
-
1.3.4. 必须测量正确的输入值
- 1.3.4.1. 捕获异常
-
1.3.5. 代码在生产环境中可能有不同表现
1.3.5.1. 对于不那么频繁的操作，修复微基准测试发现的纳秒级别的回归问题就会浪费时间，将这些时间用于优化其他操作必然更有益
1.3.5.2. 若一个集合被访问上百万次，那么每次访问节省的几纳秒就很重要
-
1.3.6. 必须包含一个预热期，让编译器有机会生成最佳代码
1.3.6.1. 必须有预热期，否则它测量的就是编译性能，而不是代码性能
1.3.6.2. Java的一个性能特点是，代码执行得越多，性能就越好
1.4. 宏基准测试（macrobenchmark）
1.4.1. 要测量一个应用程序的性能，最好的测量对象就是应用程序本身，外加它使用的任何外部资源
1.4.2. 资源分配
1.4.3. 在没测试整个应用程序的时候，不可能知道优化哪部分的性能会有效果
1.5. 介基准测试（mesobenchmark）
1.5.1. 介于微基准测试和宏基准测试之间
1.5.2. 比微基准测试的缺陷更少，也比宏基准测试更容易操作
1.5.3. 更容易使用多线程
1.5.4. 比完整的应用程序更有可能遇到同步瓶颈
1.5.5. 介基准测试的性能特点比微基准测试的更接近实际应用程序
1.5.6. 用介基准测试进行自动化测试也是很好的方法，特别是在模块级别的测试中
2. 理解吞吐量、批处理和响应时间
2.1. 测量批处理时间
2.2. 测量吞吐量
2.2.1. 基于一定时间内可以完成的工作量
2.2.2. 每秒事务数（TPS）
2.2.3. 每秒请求数（RPS）
2.2.4. 每秒操作数（OPS）
2.2.5. 吞吐量测试几乎都是在适当的预热期之后进行的
2.3. 响应时间
2.3.1. 从客户端发送请求到收到响应之间的时间
2.3.2. 在响应时间测试中，客户端线程会在操作之间有一段休眠时间，这被称为思考时间
2.3.3. 周期时间（并不是思考时间）
-
2.3.4. 平均响应时间
- 2.3.4.1. 将单个时间加在一起，再除以请求数
-
2.3.5. 百分位响应时间
- 2.3.5.1. 举例，如果90%的响应小于1.5秒，10%的响应大于1.5秒，那么1.5秒就是第90百分位响应时间
-
2.3.6. 平均响应时间和百分位响应时间的区别
2.3.6.1. 异常值会影响平均值计算。
2.3.6.2. 因为在计算平均值时会用到异常值，异常值越大，它对平均响应时间的影响就越大
-
2.3.7. 优化重点应该是降低异常值的影响（从而缩短平均响应时间）
2.3.7.1. GC引入的暂停时间会让Java程序更容易出现异常值
2.3.7.2. 通常关注第90百分位响应时间（或者第95百分位响应时间和第99百分位响应时间
2.3.7.3. 如果你只能测量一个数字，那么最好选择基于百分位响应时间的测试，因为减小这个数字将惠及大多数用户
2.3.7.4. 最好同时测量平均响应时间和至少一个百分位响应时间，这样你就不会错过异常值过大的情况了
-
2.3.8. 负载生成器
2.3.8.1. Faban就是基于Java的开源负载生成器
2.3.8.2. Apache JMeter
2.3.8.3. Gatling
2.3.8.4. Micro Focus LoadRunner
