Java 性能优化实战——工具介绍_java alwayspretouch-CSDN博客

本文链接：https://blog.csdn.net/vincent_wen0766/article/details/111359450

哪些资源，容易成为瓶颈？

计算机各个组件之间的速度往往很不均衡，比如 CPU 和硬盘，比兔子和乌龟的速度差还大，那么按照木桶理论，可以说这个系统是存在着短板的。当系统存在短板时，就会对性能造成较大的负面影响，比如当 CPU 的负载特别高时，任务就会排队，不能及时执行。而其中，CPU、内存、I/O 这三个系统组件，又往往容易成为瓶颈

CPU

首先是计算机中最重要的计算组件中央处理器 CPU，围绕 CPU 一般我们可以

通过 top 命令，来观测 CPU 的性能；
通过负载，评估 CPU 任务执行的排队情况；
通过 vmstat，看 CPU 的繁忙程度

1.top 命令 —— CPU 性能

当进入 top 命令后，按 1 键即可看到每核 CPU 的运行指标和详细性能

CPU 的使用有多个维度的指标，下面分别说明

us 用户态所占用的 CPU 百分比，即引用程序所耗费的 CPU；
sy 内核态所占用的 CPU 百分比，需要配合 vmstat 命令，查看上下文切换是否频繁；
ni 高优先级应用所占用的 CPU 百分比；
wa 等待 I/O 设备所占用的 CPU 百分比，经常使用它来判断 I/O 问题，过高输入输出设备可能存在非常明显的瓶颈；
hi 硬中断所占用的 CPU 百分比；
si 软中断所占用的 CPU 百分比；
st 在平常的服务器上这个值很少发生变动，因为它测量的是宿主机对虚拟机的影响，即虚拟机等待宿主机 CPU 的时间占比，这在一些超卖的云服务器上，经常发生；
id 空闲 CPU 百分比

2.负载 —— CPU 任务排队情况

如果我们评估 CPU 任务执行的排队情况，那么需要通过负载（load）来完成。除了 top 命令，使用 uptime 命令也能够查看负载情况，load 的效果是一样的，分别显示了最近 1min、5min、15min 的数值

如上图所示，以单核操作系统为例，将 CPU 资源抽象成一条单向行驶的马路，则会发生以下三种情况：

马路上的车只有 4 辆，车辆畅通无阻，load 大约是 0.5；
马路上的车有 8 辆，正好能首尾相接安全通过，此时 load 大约为 1；
马路上的车有 12 辆，除了在马路上的 8 辆车，还有 4 辆等在马路外面，需要排队，此时 load 大约为 1.5

load 为 1 代表的是啥？

很多人看到 load 的值达到 1，就认为系统负载已经到了极限。这在单核的硬件上没有问题，但在多核硬件上，这种描述就不完全正确，它还与 CPU 的个数有关。例如

单核的负载达到 1，总 load 的值约为 1；
双核的每核负载都达到 1，总 load 约为 2；
四核的每核负载都达到 1，总 load 约为 4

所以，对于一个 load 到了 10，却是 16 核的机器，你的系统还远没有达到负载极限

3.vmstat —— CPU 繁忙程度

要看 CPU 的繁忙程度，可以通过 vmstat 命令，下图是 vmstat 命令的一些输出信息

比较关注的有下面几列

b 如果系统有负载问题，就可以看一下 b 列（Uninterruptible Sleep），它的意思是等待 I/O，可能是读盘或者写盘动作比较多；
si/so 显示了交换分区的一些使用情况，交换分区对性能的影响比较大，需要格外关注；
cs 每秒钟上下文切换（Context Switch）的数量，如果上下文切换过于频繁，就需要考虑是否是进程或者线程数开的过多

每个进程上下文切换的具体数量，可以通过查看内存映射文件获取，如下代码所示

[root@localhost ~]# cat /proc/2788(进程号)/status

...

voluntary_ctxt_switches: 93950

nonvoluntary_ctxt_switches: 171204

内存

我们在平常写完代码后，比如写了一个 C++ 程序，去查看它的汇编，如果看到其中的内存地址，并不是实际的物理内存地址，那么应用程序所使用的，就是逻辑内存

逻辑地址可以映射到两个内存段上：物理内存和虚拟内存，那么整个系统可用的内存就是两者之和。比如你的物理内存是 4GB，分配了 8GB 的 SWAP 分区，那么应用可用的总内存就是 12GB

1. top 命令

如上图所示，我们看一下内存的几个参数，从 top 命令可以看到几列数据，注意方块框起来的三个区域，解释如下

VIRT 这里是指虚拟内存，一般比较大，不用做过多关注；

RES 我们平常关注的是这一列的数值，它代表了进程实际占用的内存，平常在做监控时，主要监控的也是这个数值；

SHR 指的是共享内存，比如可以复用的一些 so 文件等

2. CPU 缓存

由于 CPU 和内存之间的速度差异非常大，解决方式就是加入高速缓存。实际上，这些高速缓存往往会有多层，如下图所示

Java 有大部分知识点是围绕多线程的，那是因为，如果一个线程的时间片跨越了多个 CPU，那么就会存在同步问题，在 Java 中，和 CPU 缓存相关的最典型的知识点，就是在并发编程中，针对 Cache line 的伪共享（False Sharing）问题

伪共享指的是在这些高速缓存中，以缓存行为单位进行存储，哪怕你修改了缓存行中一个很小很小的数据，它都会整个刷新。所以，当多线程修改一些变量的值时，如果这些变量都在同一个缓存行里，就会造成频繁刷新，无意中影响彼此的性能

CPU 的每个核，基本是相同的，我们拿 CPU0 来说，可以通过以下的命令查看它的缓存行大小，这个值一般是 64

cat /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size

cat /sys/devices/system/cpu/cpu0/cache/index1/coherency_line_size

cat /sys/devices/system/cpu/cpu0/cache/index2/coherency_line_size

cat /sys/devices/system/cpu/cpu0/cache/index3/coherency_line_size

当然，通过 cpuinfo 也能得到一样的结果

# cat /proc/cpuinfo | grep cache

cache size   : 33792 KB
cache_alignment   : 64
cache size   : 33792 KB
cache_alignment   : 64

在 JDK8 以上的版本，通过开启参数 -XX:-RestrictContended，就可以使用注解 @sun.misc.Contended 进行补齐，来避免伪共享的问题

3. HugePage

上图有一个 TLB 组件，它的速度很快，但容量有限，在普通的 PC 机上没有什么瓶颈。但如果机器配置比较高，物理内存比较大，那就会产生非常多的映射表，CPU 的检索效率也会随之降低

传统的页大小是 4KB，在大内存时代这个值偏小了，解决的办法就是增加页的尺寸，比如将其增加到 2MB，这样，就可以使用较少的映射表来管理大内存。而这种将页增大的技术，就是 Huge Page

同时，HugePage 也伴随着一些副作用，比如竞争加剧，但在一些大内存的机器上，开启后在一定程度上会增加性能

4. 预先加载

一些程序的默认行为也会对性能有所影响，比如 JVM 的 -XX:+AlwaysPreTouch 参数

默认情况下，JVM 虽然配置了 Xmx、Xms 等参数，指定堆的初始化大小和最大大小，但它的内存在真正用到时，才会分配；但如果加上 AlwaysPreTouch 这个参数，JVM 会在启动的时候，就把所有的内存预先分配。这样，启动时虽然慢了些，但运行时的性能会增加

I/O

I/O 设备可能是计算机里速度最慢的组件了，它指的不仅仅是硬盘，还包括外围的所有设备，普通磁盘的随机写与顺序写相差非常大，但顺序写与 CPU 内存依旧不在一个数量级上

缓冲区依然是解决速度差异的唯一工具，但在极端情况下，比如断电时，就产生了太多的不确定性，这时这些缓冲区，都容易丢

1. iostat

最能体现 I/O 繁忙程度的，就是 top 命令和 vmstat 命令中的 wa%。如果你的应用写了大量的日志，I/O wait 就可能非常高

iostat

指标详细介绍如下所示

%util：我们非常关注这个数值，通常情况下，这个数字超过 80%，就证明 I/O 的负荷已经非常严重了

Device：表示是哪块硬盘，如果你有多块磁盘，则会显示多行

avgqu-sz：平均请求队列的长度，这和十字路口排队的汽车也非常类似。显然，这个值越小越好

awai：响应时间包含了队列时间和服务时间，它有一个经验值。通常情况下应该是小于 5ms 的，如果这个值超过了 10ms，则证明等待的时间过长了

svctm：表示操作 I/O 的平均服务时间。svctm 和 await 是强相关的，如果它们比较接近，则表示 I/O 几乎没有等待，设备的性能很好；但如果 await 比 svctm 的值高出很多，则证明 I/O 的队列等待时间太长，进而系统上运行的应用程序将变慢

2. 零拷贝

硬盘上的数据，在发往网络之前，需要经过多次缓冲区的拷贝，以及用户空间和内核空间的多次切换。如果能减少一些拷贝的过程，效率就能提升，所以零拷贝应运而生

零拷贝是一种非常重要的性能优化手段，比如常见的 Kafka、Nginx 等，就使用了这种技术。来看一下有无零拷贝之间的区别

（1）没有采取零拷贝手段

如下图所示，传统方式中要想将一个文件的内容通过 Socket 发送出去，则需要经过以下步骤

将文件内容拷贝到内核空间；

将内核空间内存的内容，拷贝到用户空间内存，比如 Java 应用读取 zip 文件；

用户空间将内容写入到内核空间的缓存中；

Socket 读取内核缓存中的内容，发送出去

（2）采取了零拷贝手段

零拷贝有多种模式，我们用 sendfile 来举例。如下图所示，在内核的支持下，零拷贝少了一个步骤，那就是内核缓存向用户空间的拷贝，这样既节省了内存，也节省了 CPU 的调度时间，让效率更高

磁盘的速度这么慢，为什么 Kafka 操作磁盘，吞吐量还能那么高？

磁盘之所以慢，主要就是慢在寻道的操作上面。Kafka 官方测试表明，这个寻道时间长达 10ms。磁盘的顺序写和随机写的速度比，可以达到 6 千倍，Kafka 就是采用的顺序写的方式

如何获取代码性能数据？

nmon —— 获取系统性能数据

nmon 便是一个老牌的 Linux 性能监控工具，它不仅有漂亮的监控界面，还能产出细致的监控报表

Nmon下载安装

首先查看Linux系统内核版本（两种方式）

1，cat /proc/version

2，uname -a

接着下载nmon软件包

1、wget方式下载，地址： https://nchc.dl.sourceforge.net/project/nmon/nmon16d_x86.tar.gz

2、官网手动下载，地址：http://nmon.sourceforge.net/pmwiki.php?n=Site.Download

解压安装

下载完成后，可以新建一个目录，作为解压后存放的目录，这里为 nmon16d，如果是手工下载的，需要拷贝到虚拟机

mkdir nmon16d

输入解压命令：tar -zxvf nmon16d_x86.tar.gz -C nmon16d ，-C 是指定解压目录

tar -zxvf nmon16d_x86.tar.gz -C nmon16d

在nmon6d目录中，可以找到nmon_x86_64_centos7这个文件，并对它添加执行权限

chmod +x nmon_x86_64_centos7

启动：./nmon_x86_64_centos7

按 C 键可加入 CPU 面板；按 M 键可加入内存面板；按 N 键可加入网络；按 D 键可加入磁盘等

通过下面的命令，表示每 5 秒采集一次数据，共采集 12 次，它会把这一段时间之内的数据记录下来。比如本次生成了 localhost_202012-21.nmon 这个文件，把它从服务器上下载下来

./nmon_x86_64_centos7 -f -s 5 -c 12 -m /地址/

jvisualvm —— 获取 JVM 性能数据

jvisualvm 原是随着 JDK 发布的一个工具，Java 9 之后开始单独发布。通过它，可以了解应用在运行中的内部情况。我们可以连接本地或者远程的服务器，监控大量的性能数据

通过插件功能，jvisualvm 能获得更强大的扩展。如下图所示，建议把所有的插件下载下来进行体验

要想监控远程的应用，还需要在被监控的 App 上加入 jmx 参数

// 开启 JMX 连接端口 14000
-Dcom.sun.management.jmxremote.port=14000
// 配置不需要 SSL 安全认证方式连接
-Dcom.sun.management.jmxremote.authenticate=false 

-Dcom.sun.management.jmxremote.ssl=false

对于性能优化来说，我们主要用到它的采样器。注意，由于抽样分析过程对程序运行性能有较大的影响，一般我们只在测试环境中使用此功能

对于一个 Java 应用来说，除了要关注它的 CPU 指标，垃圾回收方面也是不容忽视的性能点，我们主要关注以下三点

CPU 分析：统计方法的执行次数和执行耗时，这些数据可用于分析哪个方法执行时间过长，成为热点等

内存分析：可以通过内存监视和内存快照等方式进行分析，进而检测内存泄漏问题，优化内存使用情况

线程分析：可以查看线程的状态变化，以及一些死锁情况

JMC —— 获取 Java 应用详细性能数据

对于我们常用的 HotSpot 来说，有更强大的工具，那就是 JMC。 JMC 集成了一个非常好用的功能：JFR（Java Flight Recorder）

Flight Recorder 源自飞机的黑盒子，是用来录制信息然后事后分析的。在 Java11 中，它可以通过 jcmd 命令进行录制，主要包括 configure、check、start、dump、stop 这五个命令，其执行顺序为，start — dump — stop，例如

jcmd <pid> JFR.start

jcmd <pid> JFR.dump filename=recording.jfr

jcmd <pid> JFR.stop

JFR 功能是建在 JVM 内部的，不需要额外依赖，可以直接使用，它能够监测大量数据。比如，我们提到的锁竞争、延迟、阻塞等；甚至在 JVM 内部，比如 SafePoint、JIT 编译等，也能去分析

JMC 集成了 JFR 的功能，介绍一下 JMC 的使用

1.概览

2.线程

3.内存

4.代码

5.I/O

6.系统

7.事件

Arthas —— 获取单个请求的调用链耗时

Arthas 是一个 Java 诊断工具，可以排查内存溢出、CPU 飙升、负载高等内容，可以说是一个 jstack、jmap 等命令的大集合

输入dashboard，回车，仪表盘显示当前进程相关信息

wrk —— 获取 Web 接口的性能数据

wrk（点击进入 GitHub 网站查看）是一款 HTTP 压测工具，和 ab 命令类似，它也是一个命令行工具

Running 30s test @ http://127.0.0.1:8080/index.html

  12 threads and 400 connections

  Thread Stats   Avg      Stdev     Max   +/- Stdev

    Latency   635.91us    0.89ms  12.92ms   93.69%

    Req/Sec    56.20k     8.07k   62.00k    86.54%

  22464657 requests in 30.00s, 17.76GB read

Requests/sec: 748868.53

Transfer/sec:    606.33MB

wrk 统计了常见的性能指标，对 Web 服务性能测试非常有用。同时，wrk 支持 Lua 脚本，用来控制 setup、init、delay、request、response 等函数，可以更好地模拟用户请求

总结

nmon 获取系统性能数据；

jvisualvm 获取 JVM 性能数据；

jmc 获取 Java 应用详细性能数据；

arthas 获取单个请求的调用链耗时；

wrk 获取 Web 接口的性能数据

这些工具有偏低层的、有偏应用的、有偏统计的、有偏细节的，在定位性能问题时，你需要灵活地使用这些工具，既从全貌上掌握应用的属性，也从细节上找到性能的瓶颈，对应用性能进行全方位的掌控

基准测试 JMH，精确测量方法性能

但有时候，想要测量某段具体代码的性能情况，这时经常会写一些统计执行时间的代码，这些代码穿插在我们的逻辑中，进行一些简单的计时运算。比如下面这几行：

long start = System.currentTimeMillis(); 

//logic 

long cost = System.currentTimeMillis() - start; 

System.out.println("Logic cost : " + cost);

这段代码的统计结果，并不一定准确。举个例子来说，JVM 在执行时，会对一些代码块，或者一些频繁执行的逻辑，进行 JIT 编译和内联优化，在得到一个稳定的测试结果之前，需要先循环上万次进行预热。预热前和预热后的性能差别非常大

JMH—基准测试工具

JMH（the Java Microbenchmark Harness）就是这样一个能做基准测试的工具，它的测量精度非常高，可达纳秒级别

JMH 已经在 JDK 12中被包含，其他版本的需要自行引入 maven

<dependencies> 
        <dependency> 
            <groupId>org.openjdk.jmh</groupId> 
            <artifactId>jmh-core</artifactId> 
            <version>1.23</version> 
        </dependency> 
        <dependency> 
            <groupId>org.openjdk.jmh</groupId> 
            <artifactId>jmh-generator-annprocess</artifactId> 
            <version>1.23</version> 
            <scope>provided</scope> 
        </dependency> 
</dependencies>

JMH 是一个 jar 包，它和单元测试框架 JUnit 非常像，可以通过注解进行一些基础配置。这部分配置有很多是可以通过 main 方法的 OptionsBuilder 进行设置的

上图是JMH 程序执行的内容。通过开启多个进程，多个线程，先执行预热，然后执行迭代，最后汇总所有的测试数据进行分析。在执行前后，还可以根据粒度处理一些前置和后置操作

示例

@BenchmarkMode(Mode.Throughput) 
@OutputTimeUnit(TimeUnit.MILLISECONDS) 
@State(Scope.Thread) 
@Warmup(iterations = 3, time = 1, timeUnit = TimeUnit.SECONDS) 
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS) 
@Fork(1) 
@Threads(2) 
public class BenchmarkTest { 

    @Benchmark 
    public long shift() { 
        long t = 455565655225562L; 
        long a = 0; 
        for (int i = 0; i < 1000; i++) { 
            a = t >> 30; 
        } 
        return a; 
    } 

    @Benchmark 
    public long div() { 
        long t = 455565655225562L; 
        long a = 0; 
        for (int i = 0; i < 1000; i++) { 
            a = t / 1024 / 1024 / 1024; 
        } 
        return a; 
    } 

    public static void main(String[] args) throws Exception { 
        Options opts = new OptionsBuilder() 
                .include(BenchmarkTest.class.getSimpleName()) 
                .resultFormat(ResultFormatType.JSON) 
                .build(); 
        new Runner(opts).run(); 
    } 
}

关键注解介绍

1. @Warmup

@Warmup( 
iterations = 5, 
time = 1, 
timeUnit = TimeUnit.SECONDS)

我们不止一次提到预热 warmup 这个注解，可以用在类或者方法上，进行预热配置。可以看到，它有几个配置参数

timeUnit：时间的单位，默认的单位是秒；

iterations：预热阶段的迭代数；

time：每次预热的时间；

batchSize：批处理大小，指定了每次操作调用几次方法

上面的注解，意思是对代码预热总计 5 秒（迭代 5 次，每次一秒）。预热过程的测试数据，是不记录测量结果的

执行效果

# Warmup: 3 iterations, 1 s each

# Warmup Iteration   1: 0.281 ops/ns

# Warmup Iteration   2: 0.376 ops/ns

# Warmup Iteration   3: 0.483 ops/ns

一般来说，基准测试都是针对比较小的、执行速度相对较快的代码块，这些代码有很大的可能性被 JIT 编译、内联，所以在编码时保持方法的精简，是一个好的习惯

说到预热，就不得不提一下在分布式环境下的服务预热。在对服务节点进行发布的时候，通常也会有预热过程，逐步放量到相应的服务节点，直到服务达到最优状态。如下图所示，负载均衡负责这个放量过程，一般是根据百分比进行放量

2. @Measurement

@Measurement( 
iterations = 5,
time = 1,
timeUnit = TimeUnit.SECONDS)

Measurement 和 Warmup 的参数是一样的，不同于预热，它指的是真正的迭代次数

我们能够从日志中看到这个执行过程

# Measurement: 5 iterations, 1 s each

Iteration   1: 1646.000 ns/op

Iteration   2: 1243.000 ns/op

Iteration   3: 1273.000 ns/op

Iteration   4: 1395.000 ns/op

Iteration   5: 1423.000 ns/op

虽然经过预热之后，代码都能表现出它的最优状态，但一般和实际应用场景还是有些出入。如果你的测试机器性能很高，或者你的测试机资源利用已经达到了极限，都会影响测试结果的数值

所以，通常情况下，都会在测试时，给机器充足的资源，保持一个稳定的环境。在分析结果时，也会更加关注不同代码实现方式下的性能差异 ，而不是测试数据本身

3. @BenchmarkMode

此注解用来指定基准测试类型，对应 Mode 选项，用来修饰类和方法都可以。这里的 value，是一个数组，可以配置多个统计维度。比如

@BenchmarkMode({Throughput,Mode.AverageTime})，统计的就是吞吐量和平均执行时间两个指标

所谓的模式，其实就是我们说的一些指标，在 JMH 中，可以分为以下几种

Throughput： 整体吞吐量，比如 QPS，单位时间内的调用量等；

AverageTime： 平均耗时，指的是每次执行的平均时间。如果这个值很小不好辨认，可以把统计的单位时间调小一点；

SampleTime： 随机取样，这和 TP 值是一个概念；

SingleShotTime： 如果你想要测试仅仅一次的性能，比如第一次初始化花了多长时间，就可以使用这个参数，其实和传统的 main 方法没有什么区别；

All： 所有的指标，都算一遍，你可以设置成这个参数看下效果

拿平均时间，看一下一个大体的执行结果

Result "com.github.xjjdog.tuning.BenchmarkTest.shift":

2.068 ±(99.9%) 0.038 ns/op [Average]

(min, avg, max) = (2.059, 2.068, 2.083), stdev = 0.010

CI (99.9%): [2.030, 2.106] (assumes normal distribution)

由于我们声明的时间单位是纳秒，本次 shift 方法的平均响应时间就是 2.068 纳秒

我们也可以看下最终的耗时时间

Benchmark            Mode Cnt Score   Error Units

BenchmarkTest.div    avgt    5 2.072 ± 0.053 ns/op

BenchmarkTest.shift avgt    5 2.068 ± 0.038 ns/op

由于是平均数，这里的 Error 值的是误差（或者波动）的意思

可以看到，在衡量这些指标的时候，都有一个时间维度，它就是通过 @OutputTimeUnit 注解进行配置的，这个就比较简单了，它指明了基准测试结果的时间类型。可用于类或者方法上，一般选择秒、毫秒、微秒，纳秒那是针对的速度非常快的方法

举个例子，@BenchmarkMode(Mode.Throughput) 和 @OutputTimeUnit(TimeUnit.MILLISECONDS) 进行组合，代表的就是每毫秒的吞吐量

如下面的关于吞吐量的结果，就是以毫秒计算的：

Benchmark             Mode Cnt       Score       Error   Units

BenchmarkTest.div    thrpt    5 482999.685 ± 6415.832 ops/ms

BenchmarkTest.shift thrpt    5 480599.263 ± 20752.609 ops/ms

OutputTimeUnit 注解同样可以修饰类或者方法，通过更改时间级别，可以获取更加易读的结果

4. @Fork

fork 的值一般设置成 1，表示只使用一个进程进行测试；如果这个数字大于 1，表示会启用新的进程进行测试；但如果设置成 0，程序依然会运行，不过是这样是在用户的 JVM 进程上运行的，可以看下下面的提示，但不推荐这么做

# Fork: N/A, test runs in the host VM

# *** WARNING: Non-forked runs may silently omit JVM options, mess up profilers, disable compiler hints, etc. ***

# *** WARNING: Use non-forked runs only for debugging purposes, not for actual performance runs. ***

那么 fork 到底是在进程还是线程环境里运行呢？

通过阅读 JMH 的源码，发现每个 fork 进程是单独运行在 Proccess 进程里的，这样就可以做完全的环境隔离，避免交叉影响

它的输入输出流，通过 Socket 连接的模式，发送到我们的执行终端

其实 fork 注解有一个参数叫作 jvmArgsAppend，我们可以通过它传递一些 JVM 的参数

@Fork(value = 3, jvmArgsAppend = {"-Xmx2048m", "-server", "-XX:+AggressiveOpts"})

在平常的测试中，也可以适当增加 fork 数，来减少测试的误差

5. @Threads

fork 是面向进程的，而 Threads 是面向线程的。指定了这个注解以后，将会开启并行测试。如果配置了 Threads.MAX，则使用和处理机器核数相同的线程数

这个和我们平常编码中的习惯也是相同的，并不是说开的线程越多越好。线程多了，操作系统就需要耗费更多的时间在上下文切换上，造成了整体性能的下降

6. @Group

@Group 注解只能加在方法上，用来把测试方法进行归类。如果你单个测试文件中方法比较多，或者需要将其归类，则可以使用这个注解

与之关联的 @GroupThreads 注解，会在这个归类的基础上，再进行一些线程方面的设置。这两个注解都很少使用，除非是非常大的性能测试案例

7. @State

@State 指定了在类中变量的作用范围，用于声明某个类是一个“状态”，可以用 Scope 参数用来表示该状态的共享范围。这个注解必须加在类上，否则提示无法运行

Scope 有如下三种值

Benchmark ：表示变量的作用范围是某个基准测试类

Thread ：每个线程一份副本，如果配置了 Threads 注解，则每个 Thread 都拥有一份变量，它们互不影响

Group ：联系上面的 @Group 注解，在同一个 Group 里，将会共享同一个变量实例

在 JMHSample_DefaultState 测试代码中，演示了变量 x 的默认作用范围是 Thread，关键代码如下

@State(Scope.Thread) 
public class JMHSample_DefaultState { 
    double x = Math.PI; 
    @Benchmark 
    public void measure() { 
        x++; 
    } 
}

8. @Setup 和 @TearDown

和单元测试框架 JUnit 类似，@Setup 用于基准测试前的初始化动作，@TearDown 用于基准测试后的动作，来做一些全局的配置

这两个注解，同样有一个 Level 值，标明了方法运行的时机，它有三个取值

Trial ：默认的级别，也就是 Benchmark 级别

Iteration ：每次迭代都会运行

Invocation ：每次方法调用都会运行，这个是粒度最细的

如果你的初始化操作，是和方法相关的，那最好使用 Invocation 级别。但大多数场景是一些全局的资源，比如一个 Spring 的 DAO，那么就使用默认的 Trial，只初始化一次就可以

9. @Param

@Param 注解只能修饰字段，用来测试不同的参数，对程序性能的影响。配合 @State 注解，可以同时制定这些参数的执行范围

@BenchmarkMode(Mode.AverageTime) 
@OutputTimeUnit(TimeUnit.NANOSECONDS) 
@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS) 
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS) 
@Fork(1) 
@State(Scope.Benchmark) 
public class JMHSample_Params { 

    @Param({"1", "31", "65", "101", "103"}) 
    public int arg; 

    @Param({"0", "1", "2", "4", "8", "16", "32"}) 
    public int certainty; 

    @Benchmark 
    public boolean bench() { 
        return BigInteger.valueOf(arg).isProbablePrime(certainty); 
    } 

    public static void main(String[] args) throws RunnerException { 
        Options opt = new OptionsBuilder() 
                .include(JMHSample_Params.class.getSimpleName()) 
//                .param("arg", "41", "42") // Use this to selectively constrain/override parameters 
                .build(); 
        new Runner(opt).run(); 
    } 
}

值得注意的是，如果你设置了非常多的参数，这些参数将执行多次，通常会运行很长时间。比如参数 1 M 个，参数 2 N 个，那么总共要执行 M*N 次

10. @CompilerControl

Java 中方法调用的开销是比较大的，尤其是在调用量非常大的情况下。拿简单的getter/setter 方法来说，这种方法在 Java 代码中大量存在。我们在访问的时候，就需要创建相应的栈帧，访问到需要的字段后，再弹出栈帧，恢复原程序的执行

如果能够把这些对象的访问和操作，纳入目标方法的调用范围之内，就少了一次方法调用，速度就能得到提升，这就是方法内联的概念。如下图所示，代码经过 JIT 编译之后，效率会有大的提升

这个注解可以用在类或者方法上，能够控制方法的编译行为，常用的有 3 种模式：

强制使用内联（INLINE），禁止使用内联（DONT_INLINE），甚至是禁止方法编译（EXCLUDE）等

将结果图形化

使用 JMH 测试的结果，可以二次加工，进行图形化展示。结合图表数据，更加直观。通过运行时，指定输出的格式文件，即可获得相应格式的性能测试结果

比如下面这行代码，就是指定输出 JSON 格式的数据

Options opt = new OptionsBuilder() 
    .resultFormat(ResultFormatType.JSON) 
    .build();

1. JMH 支持 5 种格式结果

TEXT 导出文本文件

CSV 导出 csv 格式文件

SCSV 导出 scsv 等格式的文件

JSON 导出成 json 文件

LATEX 导出到 latex，一种基于 ΤΕΧ 的排版系统

一般来说，我们导出成 CSV 文件，直接在 Excel 中操作，生成如下相应的图形就可以了