河北省建设项目环境官网网站,网站备案 个体工商户,广告推广app,资源网站写在前面: 很多时候想要测试代码运行时间#xff0c;或者比较2个运行的效率。 最简单的方法就是Sytem.currentTimeMillis记录2开始和结束时间来算 但是Java 代码越执行越快#xff0c;放在后面的方法会有优势#xff0c;这个原因受留个眼#xff0c;以后研究。大概有受类加… 写在前面: 很多时候想要测试代码运行时间或者比较2个运行的效率。 最简单的方法就是Sytem.currentTimeMillis记录2开始和结束时间来算 但是Java 代码越执行越快放在后面的方法会有优势这个原因受留个眼以后研究。大概有受类加载缓存预热 jit 编译优化等原因。
简单点的StopWatch
//创建对象
StopWatch s new StopWatch();
//计时
s.start(这一次的名字);
....程序
//结束
s.stop();
//生成一个字符串其中包含描述所有已执行任务的表。
System.out.println(s.prettyPrint());多个对象
需要有参构造
//使用给定的 ID 构造一个新 StopWatch 。
//当我们有来自多个秒表的输出并需要区分它们时该 ID 很方便。
public StopWatch(String id) 其他的应该不太用的着
JMH
一款一款官方的微基准测试工具 - JMH. JMH(Java Microbenchmark Harness)是用于代码微基准测试的工具套件主要是基于方法层面的基准测试精度可以达到纳秒级。使用 JMH 可以让你方便快速的进行一次严格的代码基准测试并且有多种测试模式多种测试维度可供选择而且使用简单、增加注解便可启动测试。
加入依赖
他们说高版本jdk自带我用的jdk17不知道为啥没有也没有找到有教程。 dependencygroupIdorg.openjdk.jmh/groupIdartifactIdjmh-core/artifactIdversion1.35/version/dependencydependencygroupIdorg.openjdk.jmh/groupIdartifactIdjmh-generator-annprocess/artifactIdversion1.35/version/dependency插件
这里可以使用JMH Java Microbenchmark Harness插件快速生成。而且可以像 JUnit 一样运行单独的 Benchmark 方法\运行类中所有的 Benchmark 方法. 生成代码
右边可以直接运行
第一个案列
将要测试的方法添加Benchmark注解即可。 然后用main方法启动就可以了。
public class JMHSample_01_HelloWorld {Benchmarkpublic void wellHelloThere() {// this method was intentionally left blank.}public static void main(String[] args) throws RunnerException {Options opt new OptionsBuilder().include(JMHSample_01_HelloWorld.class.getSimpleName()).forks(1).build();new Runner(opt).run();}
}最后的结果前面还有一大堆在结果进行分析
结果分析(逐行分析)
结果输出有这样几个部分 版本和参数
// JMH版本号
# JMH version: 1.35
//jdk的版本和路径参数
# VM version: JDK 17, Java HotSpot(TM) 64-Bit Server VM, 1735-LTS-2724
# VM invoker: D:\study\app\jdk\bin\java.exe
# VM options: -javaagent:D:\idea\IntelliJ IDEA 2021.3.3\lib\idea_rt.jar9272:D:\idea\IntelliJ IDEA 2021.3.3\bin -Dfile.encodingUTF-8//黑洞模式
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetectfalse to disable)//预热的次数和每一次的时间
# Warmup: 5 iterations, 10 s each //5次每次10s
// 测试的次数和时间
# Measurement: 5 iterations, 10 s each
// 超时每次迭代10分钟
# Timeout: 10 min per iteration
//线程
# Threads: 1 thread, will synchronize iterations
//输出结果打印方式
# Benchmark mode: Throughput, ops/time//吞吐量
//执行的类
# Benchmark: org.openjdk.jmh.samples.JMHSample_01_HelloWorld.wellHelloThere每次的统计
# Run progress: 0.00% complete, ETA 00:01:40
# Fork: 1 of 1
# Warmup Iteration 1: 1895950720.598 ops/s
# Warmup Iteration 2: 1906625977.172 ops/s
# Warmup Iteration 3: 2580159163.977 ops/s
# Warmup Iteration 4: 2564641382.865 ops/s
# Warmup Iteration 5: 2561493559.473 ops/s
Iteration 1: 2529900034.146 ops/s
Iteration 2: 2497119600.056 ops/s
Iteration 3: 2512703440.984 ops/s
Iteration 4: 2568341912.143 ops/s
Iteration 5: 2574424415.895 ops/s
这一部分是总体的统计 有最小值平均值和最大值 、标准差、置信区间 Result org.openjdk.jmh.samples.JMHSample_01_HelloWorld.wellHelloThere:2536497880.645 ±(99.9%) 130763529.779 ops/s [Average](min, avg, max) (2497119600.056, 2536497880.645, 2574424415.895), stdev 33958873.426CI (99.9%): [2405734350.865, 2667261410.424] (assumes normal distribution)一些介绍没啥用
# Run complete. Total time: 00:01:41REMEMBER: The numbers below are just data. To gain reusable insights, you need to follow up on
why the numbers are the way they are. Use profilers (see -prof, -lprof), design factorial
experiments, perform baseline and negative tests that provide experimental control, make sure
the benchmarking environment is safe on JVM/OS/HW level, ask for reviews from the domain experts.
Do not assume the numbers tell you what you want them to tell.NOTE: Current JVM experimentally supports Compiler Blackholes, and they are in use. Please exercise
extra caution when trusting the results, look into the generated code to check the benchmark still
works, and factor in a small probability of new VM bugs. Additionally, while comparisons between
different JVMs are already problematic, the performance difference caused by different Blackhole
modes can be very significant. Please make sure you use the consistent Blackhole mode for comparisons.这里比较重要一般都会看
属性介绍benchmark执行的mod执行模式cnt轮次score执行的结果平均值error误差units单位
Benchmark Mode Cnt Score Error Units
JMHSample_01_HelloWorld.wellHelloThere thrpt 5 2536497880.645 ± 130763529.779 ops/s进程已结束,退出代码0使用介绍
只打算简单介绍对象的配置注解肯定用的更舒服。
对象配置
创建对象后在后面逐个添加属性然后在使用Runner类启动。
Benchmark
为该方法生成基准代码在基准列表中将该方法注册为基准从注释中读出默认值并大致为基准测试运行准备环境。
适用ElementType.METHOD后面用注解表示了BenchmarkMode
基准测试模式声明运行此基准测试的默认模式。有关可用的基准测试模式
Target({ElementType.METHOD, ElementType.TYPE})Mode[] value:模式必须的AverageTime - 调用的平均时间SampleTime - 随机取样最后输出取样结果的分布输出会比较多但是不会全部统计SingleShotTime - 只会执行一次通常用来测试冷启动时候的性能。All - 所有的benchmark modes。Fork
执行次数除了value默认就好了
Target({ElementType.METHOD,ElementType.TYPE})int BLANK_FORKS -1;String BLANK_ARGS blank_blank_blank_2014;/** return 表示该benchMark执行多少次 */
int value() default BLANK_FORKS;/** return 线束应分叉并忽略结果的次数 */
int warmups() default BLANK_FORKS;/** return 要运行的 JVM 可执行文件 */
String jvm() default BLANK_ARGS;/** return 要在命令行中替换的 JVM 参数 */
String[] jvmArgs() default { BLANK_ARGS };/** return 要在命令行中预置的 JVM 参数*/
String[] jvmArgsPrepend() default { BLANK_ARGS };/** return :要在命令行中追加的 JVM 参数*/
String[] jvmArgsAppend() default { BLANK_ARGS };fork(0)同一个进程执行一次 fork(1)新建一个进程执行一次 fork(n)新建n个进程 默认的-1等同于传5
Warmup
允许为基准设置默认预热参数
Target({ElementType.METHOD,ElementType.TYPE})/** return 预热迭代次数 */
int iterations() default BLANK_ITERATIONS;/** return每次预热迭代的时间 */
int time() default BLANK_TIME;/** return 预热迭代持续时间的时间单位 */
TimeUnit timeUnit() default TimeUnit.SECONDS;/** return 批大小每个操作的基准方法调用数*/
int batchSize() default BLANK_BATCHSIZE;Measurement
设置默认测量参数。 这个和上面一样就换成翻译了
Target({ElementType.METHOD,ElementType.TYPE})/** return Number of measurement iterations */
int iterations() default BLANK_ITERATIONS;/** return Time of each measurement iteration */
int time() default BLANK_TIME;/** return Time unit for measurement iteration duration */
TimeUnit timeUnit() default TimeUnit.SECONDS;/** return Batch size: number of benchmark method calls per operation */
int batchSize() default BLANK_BATCHSIZE;OutputTimeUnit
为统计结果的时间单位
Target({ElementType.METHOD,ElementType.TYPE})value: 时间单位State
状态对象通常作为参数注入到方法中Benchmar。 State 可以被继承使用如果父类定义了该注解子类则无需定义。由于 JMH 允许多线程同时执行测试不同的选项含义如下
Target(ElementType.TYPE)Scope.Benchmark所有测试线程共享一个实例测试有状态实例在多线程共享下的性能
Scope.Group同一个线程在同一个 group 里共享实例
Scope.Thread默认的 State每个测试线程分配一个实例感觉这个不太好理解这里看官方示例 这个代码中measureShared多个线程会同时操作这个x。 如2线程轮流那么x是1 2 3 4 5 6 measureUnshared同时操作那么就是 1 1 2 2 3 3 State(Scope.Benchmark)public static class BenchmarkState {volatile double x Math.PI;}State(Scope.Thread)public static class ThreadState {volatile double x Math.PI;}Benchmarkpublic void measureUnshared(ThreadState state) {// 所有基准测试线程都将调用此方法。//// 但是由于 ThreadState 是 Scope.Thread因此每个线程将拥有自己的状态副本此基准将衡量未共享的情况。state.x;}Benchmarkpublic void measureShared(BenchmarkState state) {// 由于 BenchmarkState 是 Scope.Benchmark所有线程都将共享状态实例我们最终将测量共享案例。state.x;}如果标记到类我们看第四个代码. 那么我们相当于可以调用这个类的属性而不用注入了。
State(Scope.Thread)
public class JMHSample_04_DefaultState {double x Math.PI;Benchmarkpublic void measure() {x;}
Setup and TearDown
会在执行 benchmark 之前/后被执行主要用于初始化/资源处理。
Target(ElementType.METHOD)此方法的级别。
Level value() default Level.Trial;
参数Level.TrialBenchmark级别benchmark执行完执行最大的。Level.Iteration执行迭代级别每次执行完都会Level.Invocation每次方法调用级别每次方法调用就都执行类型结果TrialIteration 2:x 1.059139639E9Iteration# Warmup Iteration x 3.54500352E8Iteration 1: x 7.0472257E8Iteration 2:x 1.059033135E9Invocation每次都调用一下TearDown(Level.Iteration)public void check() {System.out.println(---------------------------------);System.out.println(x x);}Benchmarkpublic void measureRight() {x;}死码消除问题
介绍
在第8给示例中主要介绍了死码优化的问题。 如果一个方法调用后没有什么用就在编译器被消除了但这给我做基准测试带了一些麻烦
我们看第八个 讲道理来演示的意思是measureWrong比rigth应该慢超级多但是我怎么测试都测试不出来不知道为什么。而且第九个也测试不出来。 private double x Math.PI;Benchmarkpublic void baseline() {// do nothing, this is a baseline}Benchmarkpublic void measureWrong() {// This is wrong: result is not used and the entire computation is optimized away.Math.log(x);}Benchmarkpublic double measureRight() {// This is correct: the result is being used.return Math.log(x);}解决
第九个示例告诉我们解决。 不过我测不出来。
使用他注入Blackhole bh 对象使用consume方法调用 Benchmarkpublic void measureRight_2(Blackhole bh) {bh.consume(Math.log(x1));bh.consume(Math.log(x2));}同一个进程会互相影响
众所周知JVM擅长按配置文件优化。这对基准测试不利因为不同的测试可以将它们的配置文件混合在一起然后为每个测试呈现“统一错误”的代码。分叉在单独的进程中运行每个测试都有助于避免此问题。默认情况下JMH 将分叉测试。 BenchmarkFork(0)public int measure_1_c1() {return measure(c1);}/** Then Counter2...*/BenchmarkFork(0)public int measure_2_c2() {return measure(c2);}/** Then Counter1 again...*/BenchmarkFork(0)public int measure_3_c1_again() {return measure(c1);}请注意C1 更快C2 更慢但 C1 又慢了这是因为 C1 和 C2 的配置文件已合并在一起。请注意分叉运行的测量是多么完美。
还有些案例不过不想学了这些够现在的用了以后需要在学
