# Java Performance Analysis

# 为何要评估性能

• 实践出真知，理论要联系实习，认知的局限需要实验来验证和进步
• 学习新知识，深入框架或语言内部实现机制
• 吵架的时候有说服力，自省的时候有依据

# Java中使用Benchmark工具包

OpenJDK的JHM^[1]出品，benchmark工具包，通过使用Maven构建一个稳定的、可重复使用的测试包。 使用方式：

• 注解的方式(推荐)
• 命令行方式(便于集成)

# 引入相关依赖

在Maven文件中引入相关依赖：

    <dependency>
        <groupId>org.openjdk.jmh</groupId>
        <artifactId>jmh-core</artifactId>
        <version>1.18</version>
    </dependency>
    <dependency>
        <groupId>org.openjdk.jmh</groupId>
        <artifactId>jmh-generator-annprocess</artifactId>
        <version>1.18</version>
    </dependency>

# 一个简单的Demo测试

首先加入需要做对比测试的类，如StreamFilterPerf.class

@State(Scope.Thread)
@Warmup(iterations = 3)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
public class FilterPerf {

  private Integer[] collections = new Integer[1000 * 1000];

  @Setup
  public void InitCollection() {
    for (int i = 0; i < collections.length; i++) {
      collections[i] = i;
    }
  }

  @Benchmark
  public void measureStreamFilterOneByOne() {
    Arrays.stream(collections)
        .filter(i -> i % 2 == 0)
        .filter(i -> i % 5 == 0)
        .filter(i -> i % 3 == 0)
        .toArray();
  }

  @Benchmark
  public void measureStreamFilterOnlyOne() {
    Arrays.stream(collections).filter(i -> i % 5 == 0 && i % 2 == 0 && i % 3 == 0).toArray();
  }
}

注：测试中用到的注解大家先可以忽略，下面会详细的讲解。

然后，在main方法中加入需要运行的类在include方法中。

  public static void main(String[] args) throws RunnerException {
    SpringApplication.run(DemoApplication.class, args);
    // 构建Benchmark Build
    Options opt = new OptionsBuilder()
            .include(FilterPerf.class.getSimpleName())
            .forks(1)
            .build();
    new Runner(opt).run();
  }

这个简单的Demo是用于比较Java8中的Stream是否会做lambda演算^[2]优化（结果是否定的）, 通过使用一次Filter多个条件和多次Filter做性能对比。

# 如何评估测试结果

注解@BenchmarkMode(Mode.AverageTime)启用的是完成特定任务需要花费的平均时长，单位是毫秒，不难看出性能对比结果非常明显，多次Filter在执行1百万次循环之后花费了平均时长为8毫秒左右，而只有一次Filter的方法在执行同样任务的情况下花费的时长是3毫秒左右，结果证明Java8 Stream对Lambda表达式并没有更多"显而易见"的优化。

# 示例详细解释

# 1. 创建Main函数

    Options opt = new OptionsBuilder()
            .include(FilterPerf.class.getSimpleName()) // 指定需要执行的文件或者匹配的文件
            .forks(1) // 启动1个进程来执行测试
            .build();
    new Runner(opt).run();

note：为何fork指定为1，原因在于JVM使用了Profile-Guided Optimization(PGO)优化策略^[3]，为了保证测试结果的隔离性。

# 2. 注解的使用

基于注解的方式非常便于理解和配置测试基准项，其中不同注解包含的意义不同，同时为了"抵抗"JVM的优化，也有对应的注解来解决^[4]。

# 2.1 @State(Scope.Thread)

必须的一个注解，提供了三种选择：

• Benchmark，所有测试线程共享一个实例，用于测试有状态实例在多线程共享下的性能
• Group，线程组共享测试实例
• Thread（默认选项，推荐），每一个测试实例分配一个线程

# 2.2 @Warmup(iterations = 3)

预热次数，为了抵抗编译器优化导致的基准测试偏差。

# 2.3 @BenchmarkMode(Mode.AverageTime)

提供如下选择项：

• Throughput("thrpt", "Throughput, ops/time"), 一秒执行的次数，吞吐量
• AverageTime("avgt", "Average time, time/op"), 每次调用执行的时间
• SampleTime("sample", "Sampling time"), 随机取样，99%的调用在xxx毫秒以内，99.99%的调用在xxx毫秒以内
• SingleShotTime("ss", "Single shot invocation time"), 以上模式都是默认一次 iteration 是 1s，唯有 SingleShotTime 是只运行一次。往往同时把 warmup 次数设为0，用于测试冷启动时的性能。（ss）
• All("all", "All benchmark modes"), 以上都包含。

# 2.4 @OutputTimeUnit(TimeUnit.MILLISECONDS)

统计时间显示格式：纳秒 * 1000 => 毫秒 * 1000 => 秒

# 2.5 抵抗编译器对没有返回结果的变量或者方法的优化

• 使其有返回值，方法不是void类型
• 使用Blackhole bh， 调用bh.consume

# 更多资源

更多官方的例子^[5] 方便的Github例子^[6] 我的git仓库地址^[7]

# Reference