橘子学JDK之JMH-02(BenchmarkModes)

这篇具有很好参考价值的文章主要介绍了橘子学JDK之JMH-02(BenchmarkModes)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

一、案例二代码

这次我们来搞一下官网文档的第二个案例,我删除了一些没用的注释,然后对代码做了一下注释的翻译,可以看一下意思。

package com.levi;

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.runner.Runner;
import org.openjdk.jmh.runner.RunnerException;
import org.openjdk.jmh.runner.options.Options;
import org.openjdk.jmh.runner.options.OptionsBuilder;

import java.util.concurrent.TimeUnit;

// 预热注解,修改为只预热一轮,每轮只跑一秒,默认是5,5这里改为1,1
@Warmup(iterations = 1,time = 1)
// 测试执行注解,修改为只执行一轮,每轮只跑一秒,默认是5,5这里改为1,1
@Measurement(iterations = 1,time = 1)
public class JMHSample_02_01_BenchmarkModes {

    /*
     * Mode.Throughput, as stated in its Javadoc, measures the raw throughput by
     * continuously calling the benchmark method in a time-bound iteration, and
     * counting how many times we executed the method.
     *
     * We are using the special annotation to select the units to measure in,
     * although you can use the default.
     *
     * AI直译:Mode.Throughput,如其Javadoc所述,通过在时间限制的迭代中连续调用基准方法,
     * 并计算我们执行该方法的次数来衡量原始吞吐量。我们正在使用特殊注解来选择要测量的单位,尽管你可以使用默认值。
     *
     * 我根据我的理解还是说几句人话吧,他的意思是我们之前不是在案例1中输出的是吞吐量的测试指标吗,这里的意思是你可以
     * 使用@BenchmarkMode这个注解,里面设置参数Mode.Throughput一样可以是通过吞吐量的指标的,或者说你不设置,默认
     * 本身就是吞吐量,我们第一个案例就是默认的。
     * 所以我们在第一个方法上看到新出现的两个注解
     * @BenchmarkMode:设置计算指标
     * @OutputTimeUnit:计算模式对应的单位
     */

    @Benchmark
    @BenchmarkMode(Mode.Throughput)
    @OutputTimeUnit(TimeUnit.SECONDS)
    public void measureThroughput() throws InterruptedException {
        TimeUnit.MILLISECONDS.sleep(100);
    }

    /*
     * Mode.AverageTime measures the average execution time, and it does it
     * in the way similar to Mode.Throughput.
     * 在性能测试或基准测试的背景下,Mode.AverageTime(平均时间模式)测量了给定操作或代码片段的平均执行时间。
     * 该模式计算了每次调用被测试代码所花费的平均时间。它与Mode.Throughput(吞吐量模式)相似,两种模式都专注于性能测量,
     * 但它们在优先考虑的性能方面存在差异。以下是Mode.AverageTime和Mode.Throughput之间的简要比较:
     * 平均时间:该模式计算每个操作或调用的平均执行时间。它提供了关于单个操作平均执行时间的信息。
     * 吞吐量:另一方面,Mode.Throughput关注的是在给定时间内完成的操作速率。它衡量每单位时间内可以执行多少操作,通常是每秒。
     * 它提供了系统在高负载下处理大量操作的效率信息。
     * 虽然两种模式都提供了有关性能的有价值的信息,但它们服务于不同的目的,可能适用于不同类型的性能分析。
     * Mode.AverageTime适用于了解单个操作的平均延迟或执行时间,而Mode.Throughput更适用于在指定时间范围内最大化完成的操作数量。
     *
     *
     * Some might say it is the reciprocal throughput, and it really is.
     * There are workloads where measuring times is more convenient though.
     * 有人说,这个指标是吞吐量的倒数,你也可以这么理解,不过有时候你测试的时候,统计时间维度是更加直观的。
     *
     * 换言之,这个是统计你方法的执行平均时间的,所以看起来比吞吐量更加直观,毕竟耗时是我们普遍关心的第一指标
     */
    @Benchmark
    @BenchmarkMode(Mode.AverageTime)
    @OutputTimeUnit(TimeUnit.MICROSECONDS)
    public void measureAvgTime() throws InterruptedException {
        TimeUnit.MILLISECONDS.sleep(100);
    }

    /*
     * Mode.SampleTime samples the execution time. With this mode, we are
     * still running the method in a time-bound iteration, but instead of
     * measuring the total time, we measure the time spent in *some* of
     * the benchmark method calls.
     *
     * Mode.SampleTime是用于对方法执行时间进行采样的一种模式。在这种模式下,我们仍然在一个有时间限制的迭代中运行方法,
     * 但不再测量总时间,而是测量一部分基准方法调用所花费的时间。使用Mode.SampleTime模式时,
     * 基准测试框架会定期中断方法的执行并记录经过的时间。通过只对部分调用进行采样,可以减少与连续时间测量相关的开销,
     * 同时仍能提供有关方法执行时间分布的有意义数据,而不仅仅关注整体持续时间。这种模式对于识别执行时间的变化非常有用,
     * 特别是如果方法的某些部分可能具有不同的性能特点或表现出间歇性行为。它使开发人员能够了解方法在不同条件下的性能表现,
     * 并帮助优化其性能。
     *
     * This allows us to infer the distributions, percentiles, etc.
     * JMH also tries to auto-adjust sampling frequency: if the method
     * is long enough, you will end up capturing all the samples.
     * 这样可以让我们推断出分布情况、百分位数等。JMH 还会尝试自动调整采样频率:如果方法足够长,你最终会捕获到所有的样本
     *
     * 这个解释的不明确,我们待会通过现象来看一下具体啥意思。
     */
    @Benchmark
    @BenchmarkMode(Mode.SampleTime)
    @OutputTimeUnit(TimeUnit.MICROSECONDS)
    public void measureSamples() throws InterruptedException {
        TimeUnit.MILLISECONDS.sleep(100);
    }

    /*
     * Mode.SingleShotTime measures the single method invocation time. As the Javadoc
     * suggests, we do only the single benchmark method invocation. The iteration
     * time is meaningless in this mode: as soon as benchmark method stops, the
     * iteration is over.
     *
     * Mode.SingleShotTime测量的是单个方法调用的时间。正如Javadoc所建议的,我们只进行一次基准方法的调用。
     * 在这种模式下,迭代时间是没有意义的:一旦基准方法停止,迭代就结束了。
     *
     * This mode is useful to do cold startup tests, when you specifically
     * do not want to call the benchmark method continuously.
     * 这种模式在进行冷启动测试时非常有用,当你不想连续调用基准方法时。
     *
     * 说白了就是只测试一次,就跟你跑main函数一样的,没有预热,就是冷启动的测试。
     */
    @Benchmark
    @BenchmarkMode(Mode.SingleShotTime)
    @OutputTimeUnit(TimeUnit.MICROSECONDS)
    public void measureSingleShot() throws InterruptedException {
        TimeUnit.MILLISECONDS.sleep(100);
    }

    /*
     * We can also ask for multiple benchmark modes at once. All the tests
     * above can be replaced with just a single test like this:
     *
     * 这个注解还能写数组,指定多种测试指标,一起生效
     */
    @Benchmark
    @BenchmarkMode({Mode.Throughput, Mode.AverageTime, Mode.SampleTime, Mode.SingleShotTime})
    @OutputTimeUnit(TimeUnit.MICROSECONDS)
    public void measureMultiple() throws InterruptedException {
        TimeUnit.MILLISECONDS.sleep(100);
    }

    /*
     * Or even...
     * 如果你懒得写很多模式,你还能直接用Mode.All来表示全部的模式
     */
    @Benchmark
    @BenchmarkMode(Mode.All)
    @OutputTimeUnit(TimeUnit.MICROSECONDS)
    public void measureAll() throws InterruptedException {
        TimeUnit.MILLISECONDS.sleep(100);
    }

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(JMHSample_02_01_BenchmarkModes.class.getSimpleName())
                .forks(1)
                .build();

        new Runner(opt).run();
    }
}

二、@BenchmarkMode

我们先不急着运行程序,我们在看完上面的例子之后可以看到这次出现了一个新的注解,就是
@BenchmarkMode

@Inherited
@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface BenchmarkMode {
    Mode[] value();
}

这个注解我们看到,作用的位置就是方法和类上面,你要是标注在类上,那就这个类所有的方法都按照这个配置生效了。
而且我们注意到他有一个变量,是Mode类型的数组,注意是数组,也就是可以传入多个。我们看一下这个Mode类型是啥。

public enum Mode {
    Throughput("thrpt", "Throughput, ops/time"),
    AverageTime("avgt", "Average time, time/op"),
    SampleTime("sample", "Sampling time"),
    SingleShotTime("ss", "Single shot invocation time"),
    All("all", "All benchmark modes");
}

就是个枚举类型,总共五个类型,我们上面的注释其实也标注了这五个类型的各自的作用。

三、 @OutputTimeUnit

与@BenchmarkMode 配套的还有一个注解就是@OutputTimeUnit。

@Inherited
@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface OutputTimeUnit {
    TimeUnit value();
}

他的作用就是你输出指标的时间单位,没别的了。OK,我们在大致有个了解之后,我们开始通过执行程序来看一下结果,加深我们对于注解的理解。

四、执行程序

鉴于我们这里这次一次写了N个方法测试,输出的报告巨长,我们这里就一个一个的测试,这样方便观察。

1、测试吞吐模式:measureThroughput

package com.levi;

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.runner.Runner;
import org.openjdk.jmh.runner.RunnerException;
import org.openjdk.jmh.runner.options.Options;
import org.openjdk.jmh.runner.options.OptionsBuilder;

import java.util.concurrent.TimeUnit;

// 预热注解,修改为只预热一轮,每轮只跑一秒,默认是5,5这里改为1,1
@Warmup(iterations = 1,time = 1)
// 测试执行注解,修改为只执行一轮,每轮只跑一秒,默认是5,5这里改为1,1
@Measurement(iterations = 1,time = 1)
public class JMHSample_02_01_BenchmarkModes {

    /*
     * Mode.Throughput, as stated in its Javadoc, measures the raw throughput by
     * continuously calling the benchmark method in a time-bound iteration, and
     * counting how many times we executed the method.
     *
     * We are using the special annotation to select the units to measure in,
     * although you can use the default.
     *
     * AI直译:Mode.Throughput,如其Javadoc所述,通过在时间限制的迭代中连续调用基准方法,
     * 并计算我们执行该方法的次数来衡量原始吞吐量。我们正在使用特殊注解来选择要测量的单位,尽管你可以使用默认值。
     *
     * 我根据我的理解还是说几句人话吧,他的意思是我们之前不是在案例1中输出的是吞吐量的测试指标吗,这里的意思是你可以
     * 使用@BenchmarkMode这个注解,里面设置参数Mode.Throughput一样可以是通过吞吐量的指标的,或者说你不设置,默认
     * 本身就是吞吐量,我们第一个案例就是默认的。
     * 所以我们在第一个方法上看到新出现的两个注解
     * @BenchmarkMode:设置计算指标
     * @OutputTimeUnit:计算模式对应的单位
     */

    @Benchmark
    @BenchmarkMode(Mode.Throughput)
    @OutputTimeUnit(TimeUnit.SECONDS)
    public void measureThroughput() throws InterruptedException {
        TimeUnit.MILLISECONDS.sleep(100);
    }

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(JMHSample_02_01_BenchmarkModes.class.getSimpleName())
                .forks(1)
                .build();

        new Runner(opt).run();
    }
}

运行结果为:
Benchmark :JMHSample_02_01_BenchmarkModes.measureThroughput
Mode :thrpt
Cnt : 因为我控制了1次,所以这里没东西
Score :9.160 这个分数在吞吐这里其实就是你执行的吞吐量,因为我写的@OutputTimeUnit(TimeUnit.SECONDS)单位是秒,所以意思就是一秒能执行9.16次。
Error :没输出
Units:ops/s
我们看到这个吞吐量其实和我们在第一个案例测试的差不多,其实他就是默认的。你不写就是他。

2、测试平均时间模式:measureAvgTime

package com.levi;

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.runner.Runner;
import org.openjdk.jmh.runner.RunnerException;
import org.openjdk.jmh.runner.options.Options;
import org.openjdk.jmh.runner.options.OptionsBuilder;

import java.util.concurrent.TimeUnit;

// 预热注解,修改为只预热一轮,每轮只跑一秒,默认是5,5这里改为1,1
@Warmup(iterations = 1,time = 1)
// 测试执行注解,修改为只执行一轮,每轮只跑一秒,默认是5,5这里改为1,1
@Measurement(iterations = 1,time = 1)
public class JMHSample_02_01_BenchmarkModes {

   
    /*
     * Mode.AverageTime measures the average execution time, and it does it
     * in the way similar to Mode.Throughput.
     * 在性能测试或基准测试的背景下,Mode.AverageTime(平均时间模式)测量了给定操作或代码片段的平均执行时间。
     * 该模式计算了每次调用被测试代码所花费的平均时间。它与Mode.Throughput(吞吐量模式)相似,两种模式都专注于性能测量,
     * 但它们在优先考虑的性能方面存在差异。以下是Mode.AverageTime和Mode.Throughput之间的简要比较:
     * 平均时间:该模式计算每个操作或调用的平均执行时间。它提供了关于单个操作平均执行时间的信息。
     * 吞吐量:另一方面,Mode.Throughput关注的是在给定时间内完成的操作速率。它衡量每单位时间内可以执行多少操作,通常是每秒。
     * 它提供了系统在高负载下处理大量操作的效率信息。
     * 虽然两种模式都提供了有关性能的有价值的信息,但它们服务于不同的目的,可能适用于不同类型的性能分析。
     * Mode.AverageTime适用于了解单个操作的平均延迟或执行时间,而Mode.Throughput更适用于在指定时间范围内最大化完成的操作数量。
     *
     *
     * Some might say it is the reciprocal throughput, and it really is.
     * There are workloads where measuring times is more convenient though.
     * 有人说,这个指标是吞吐量的倒数,你也可以这么理解,不过有时候你测试的时候,统计时间维度是更加直观的。
     *
     * 换言之,这个是统计你方法的执行平均时间的,所以看起来比吞吐量更加直观,毕竟耗时是我们普遍关心的第一指标
     */
    @Benchmark
    @BenchmarkMode(Mode.AverageTime)
    @OutputTimeUnit(TimeUnit.MICROSECONDS)
    public void measureAvgTime() throws InterruptedException {
        TimeUnit.MILLISECONDS.sleep(100);
    }
    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(JMHSample_02_01_BenchmarkModes.class.getSimpleName())
                .forks(1)
                .build();

        new Runner(opt).run();
    }
}

运行结果如下:
Benchmark :JMHSample_02_01_BenchmarkModes.measureAvgTime
Mode:avgt 平均统计模式
Cnt :同上
Score:108407.350
Error :没错误,不输出
Units:us/op 其实你能看出来,他是时间除以执行次数,所以就是吞吐量的倒数,吞吐量的意思是每秒能执行几次,这里就是执行一次需要几秒,不就是平均时间吗。只是我指定的时间单位是@OutputTimeUnit(TimeUnit.MICROSECONDS)微秒,所以这里自然也就是这个单位。
他主打的是一个平均耗时。

3、测试统计时间:measureSamples

package com.levi;

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.runner.Runner;
import org.openjdk.jmh.runner.RunnerException;
import org.openjdk.jmh.runner.options.Options;
import org.openjdk.jmh.runner.options.OptionsBuilder;

import java.util.concurrent.TimeUnit;

// 预热注解,修改为只预热一轮,每轮只跑一秒,默认是5,5这里改为1,1
@Warmup(iterations = 1,time = 1)
// 测试执行注解,修改为只执行一轮,每轮只跑一秒,默认是5,5这里改为1,1
@Measurement(iterations = 1,time = 1)
public class JMHSample_02_01_BenchmarkModes {
    /*
     * Mode.SampleTime samples the execution time. With this mode, we are
     * still running the method in a time-bound iteration, but instead of
     * measuring the total time, we measure the time spent in *some* of
     * the benchmark method calls.
     *
     * Mode.SampleTime是用于对方法执行时间进行采样的一种模式。在这种模式下,我们仍然在一个有时间限制的迭代中运行方法,
     * 但不再测量总时间,而是测量一部分基准方法调用所花费的时间。使用Mode.SampleTime模式时,
     * 基准测试框架会定期中断方法的执行并记录经过的时间。通过只对部分调用进行采样,可以减少与连续时间测量相关的开销,
     * 同时仍能提供有关方法执行时间分布的有意义数据,而不仅仅关注整体持续时间。这种模式对于识别执行时间的变化非常有用,
     * 特别是如果方法的某些部分可能具有不同的性能特点或表现出间歇性行为。它使开发人员能够了解方法在不同条件下的性能表现,
     * 并帮助优化其性能。
     *
     * This allows us to infer the distributions, percentiles, etc.
     * JMH also tries to auto-adjust sampling frequency: if the method
     * is long enough, you will end up capturing all the samples.
     * 这样可以让我们推断出分布情况、百分位数等。JMH 还会尝试自动调整采样频率:如果方法足够长,你最终会捕获到所有的样本
     *
     * 这个解释的不明确,我们待会通过现象来看一下具体啥意思。
     */
    @Benchmark
    @BenchmarkMode(Mode.SampleTime)
    @OutputTimeUnit(TimeUnit.MICROSECONDS)
    public void measureSamples() throws InterruptedException {
        TimeUnit.MILLISECONDS.sleep(100);
    }

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(JMHSample_02_01_BenchmarkModes.class.getSimpleName())
                .forks(1)
                .build();

        new Runner(opt).run();
    }
}

橘子学JDK之JMH-02(BenchmarkModes),# JDK,java
他是以一种分布统计的方式输出的测试指标,单位还是平均时间耗时,等于说百分之99的测试跑一次是109707.264us的耗时,他内部给你做了一个测试,拆分出来测的,测出这么个结果来。
能看出来一个波动,和你实现的代码稳定性,而且他是抽样测试,不会都给你统计,比如我们设置的跑1轮,每轮一秒。可能这一秒跑了一万次,他不会像吞吐和平均那个样都算进去,他是一个抽样,可能抽了前面后面,没取中间。可能压根就是抽了前面。是一个分布统计。

4、测试只跑一次:measureSingleShot

package com.levi;

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.runner.Runner;
import org.openjdk.jmh.runner.RunnerException;
import org.openjdk.jmh.runner.options.Options;
import org.openjdk.jmh.runner.options.OptionsBuilder;

import java.util.concurrent.TimeUnit;

// 预热注解,修改为只预热一轮,每轮只跑一秒,默认是5,5这里改为1,1
@Warmup(iterations = 1,time = 1)
// 测试执行注解,修改为只执行一轮,每轮只跑一秒,默认是5,5这里改为1,1
@Measurement(iterations = 1,time = 1)
public class JMHSample_02_01_BenchmarkModes {
    /*
     * Mode.SingleShotTime measures the single method invocation time. As the Javadoc
     * suggests, we do only the single benchmark method invocation. The iteration
     * time is meaningless in this mode: as soon as benchmark method stops, the
     * iteration is over.
     *
     * Mode.SingleShotTime测量的是单个方法调用的时间。正如Javadoc所建议的,我们只进行一次基准方法的调用。
     * 在这种模式下,迭代时间是没有意义的:一旦基准方法停止,迭代就结束了。
     *
     * This mode is useful to do cold startup tests, when you specifically
     * do not want to call the benchmark method continuously.
     * 这种模式在进行冷启动测试时非常有用,当你不想连续调用基准方法时。
     *
     * 说白了就是只测试一次,就跟你跑main函数一样的,没有预热,就是冷启动的测试。
     */
    @Benchmark
    @BenchmarkMode(Mode.SingleShotTime)
    @OutputTimeUnit(TimeUnit.MICROSECONDS)
    public void measureSingleShot() throws InterruptedException {
        TimeUnit.MILLISECONDS.sleep(100);
    }

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(JMHSample_02_01_BenchmarkModes.class.getSimpleName())
                .forks(1)
                .build();

        new Runner(opt).run();
    }
}

执行结果如下:
橘子学JDK之JMH-02(BenchmarkModes),# JDK,java
这就是测试冷启动的,没预热,就是直接跑,你也能看到单位是us/op。还是执行一次要多久。还是个平均值,只不过就是没预热直接开跑的。就跑一次。

5、测试多种模式组合:measureMultiple

package com.levi;

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.runner.Runner;
import org.openjdk.jmh.runner.RunnerException;
import org.openjdk.jmh.runner.options.Options;
import org.openjdk.jmh.runner.options.OptionsBuilder;

import java.util.concurrent.TimeUnit;

// 预热注解,修改为只预热一轮,每轮只跑一秒,默认是5,5这里改为1,1
@Warmup(iterations = 1,time = 1)
// 测试执行注解,修改为只执行一轮,每轮只跑一秒,默认是5,5这里改为1,1
@Measurement(iterations = 1,time = 1)
public class JMHSample_02_01_BenchmarkModes {

    /*
     * We can also ask for multiple benchmark modes at once. All the tests
     * above can be replaced with just a single test like this:
     *
     * 这个注解还能写数组,指定多种测试指标,一起生效
     */
    @Benchmark
    @BenchmarkMode({Mode.Throughput, Mode.AverageTime, Mode.SampleTime, Mode.SingleShotTime})
    @OutputTimeUnit(TimeUnit.MICROSECONDS)
    public void measureMultiple() throws InterruptedException {
        TimeUnit.MILLISECONDS.sleep(100);
    }
    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(JMHSample_02_01_BenchmarkModes.class.getSimpleName())
                .forks(1)
                .build();

        new Runner(opt).run();
    }
}

因为我们前面看了Mode是一个数组,所以可以传入多个模式。结果就是一起统计输出了。
橘子学JDK之JMH-02(BenchmarkModes),# JDK,java

6、测试全量模式:measureAll

package com.levi;

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.runner.Runner;
import org.openjdk.jmh.runner.RunnerException;
import org.openjdk.jmh.runner.options.Options;
import org.openjdk.jmh.runner.options.OptionsBuilder;

import java.util.concurrent.TimeUnit;

// 预热注解,修改为只预热一轮,每轮只跑一秒,默认是5,5这里改为1,1
@Warmup(iterations = 1,time = 1)
// 测试执行注解,修改为只执行一轮,每轮只跑一秒,默认是5,5这里改为1,1
@Measurement(iterations = 1,time = 1)
public class JMHSample_02_01_BenchmarkModes {
    /*
     * Or even...
     * 如果你懒得写很多模式,你还能直接用Mode.All来表示全部的模式
     */
    @Benchmark
    @BenchmarkMode(Mode.All)
    @OutputTimeUnit(TimeUnit.MICROSECONDS)
    public void measureAll() throws InterruptedException {
        TimeUnit.MILLISECONDS.sleep(100);
    }

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(JMHSample_02_01_BenchmarkModes.class.getSimpleName())
                .forks(1)
                .build();

        new Runner(opt).run();
    }
}

自然就是全部的统计都输出了:和上面一样。
橘子学JDK之JMH-02(BenchmarkModes),# JDK,java
你也可以看他的单位就知道他输出的计算方式了,次数除以时间,那就是平均时间的执行次数,就是吞吐。
时间除以次数,就是统计的某种模式下的平均时间。

五、总结

没啥总结的就是那两个注解,很详细了。

六、参考链接

1、JMH官方文档文章来源地址https://www.toymoban.com/news/detail-852948.html

到了这里,关于橘子学JDK之JMH-02(BenchmarkModes)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • JMH - Java代码基准测试工具,代码性能问题验证测试

    在日常开发工作当中,开发人员可能有这些困惑:自己写的这个方法性能到底怎么样?在原接口实现方法中添加了新的业务逻辑,对整个接口的性能影响有多少?有多种实现方式(或开源类库),到底哪一种性能更好? 当遇到类似困惑或者说问题的时候,怎么办呢?当然是测试

    2024年02月07日
    浏览(51)
  • Linux02(项目部署,手动和自动部署,JDK版本问题,安装软件,安装软件,安装JDK,Tomcat,MySQL,Irzsz)

    目录 一、安装软件 1. 安装准备工作 1 Linux里的软件安装方式 2 上传软件到Linux 3 拍照虚拟机快照 2. 安装JDK 1 卸载自带jdk 2 解压JDK 3 配置环境变量 4 测试JDK 3. 安装Tomcat 1 解压Tomcat 2 修改防火墙设置 3 测试Tomcat 启动Tomcat 访问Tomcat 查看Tomcat日志 4 关闭Tomcat 4. 安装MySQL 1 卸载自带

    2024年04月18日
    浏览(47)
  • Ubuntu22.04 Hadoop3.3.4 jdk18.02 安装配置

    阅读推荐(105条消息) 大数据安装之hadoop-3.3.4_x_y_z423的博客-CSDN博客 (112条消息) hadoop3.3.4集群安装部署_hwbays的博客-CSDN博客 加倍推荐,Hadoop集群配置内容讲的及其详细 基于docker的hadoop集群搭建 xshell Windows 10 Pro, 64-bit VMware® Workstation 16 Pro Ubuntu22.04 * 3 2、VMware tools安装 apt install

    2023年04月11日
    浏览(43)
  • 测试工具之JMH详解

    在日常开发中,我们对一些代码的调用或者工具的使用会存在多种选择方式,在不确定他们性能的时候,我们首先想要做的就是去测量它。大多数时候,我们会简单的采用多次计数的方式来测量,来看这个方法的总耗时。 但是,如果熟悉 JVM 类加载机制的话,应该知道 JVM 默

    2024年02月08日
    浏览(44)
  • 【精通性能优化:解锁JMH微基准测试】一基本用法

    1. 什么是JMH JMH是Java Micro Benchmark Harness的简写,是专门用于代码微基准测试的工具集。 JMH由实现Java虚拟你的团队开发,现代JVM已经变的越来越智能,在Java文件的编译阶段、类的加载阶段,以及运行阶段都可能进行了不同程度的优化,因此开发者编写的代码未必会像自己所预

    2024年02月12日
    浏览(37)
  • 【图论】Leetcode 994. 腐烂的橘子【中等】

    在给定的 m x n 网格 grid 中,每个单元格可以有以下三个值之一: 值 0 代表空单元格; 值 1 代表新鲜橘子; 值 2 代表腐烂的橘子。 每分钟,腐烂的橘子 周围 4 个方向上相邻 的新鲜橘子都会腐烂。 返回 直到单元格中没有新鲜橘子为止所必须经过的最小分钟数。如果不可能,

    2024年04月15日
    浏览(30)
  • 【LeetCode热题100】【图论】腐烂的橘子

    题目描述:994. 腐烂的橘子 - 力扣(LeetCode) 腐烂的橘子会污染周围的橘子,要求多少轮扩散才能把全部橘子污染,这就相当于滴墨水入清水,会扩散,其实就是广度遍历,看看遍历多少层可以遍历完可以遍历的 先遍历一次橘子,记录下腐烂橘子的位置和新鲜橘子的数目,然

    2024年04月23日
    浏览(41)
  • 【LeetCode-中等题】994. 腐烂的橘子

    该题值推荐用bfs,因为是一层一层的感染,而不是一条线走到底的那种,所以深度优先搜索不适合 广度优先搜索,就是从起点出发,每次都尝试访问同一层的节点,如果同一层都访问完了,再访问下一层,最后广度优先搜索找到的路径就是从起点开始的最短合法路径。 在该

    2024年02月10日
    浏览(35)
  • 【leetcode994】腐烂的橘子(BFS)

    首先将所有烂橘子入队,然后常规BFS遍历,注意 while 的截止条件除了队列为空, 新鲜橘子数量大于0 (没新鲜橘子也没必要继续遍历,保证时间计算的正确性),这两者一个不满足就可以停止 每分钟进行一次【腐烂扩散】,使用BFS对二维图进行遍历,注意和二叉树的层次遍

    2024年02月19日
    浏览(32)
  • 这个AI模型能识别出这个橘子吗?

    ☁️主页 Nowl 🔥专栏 《AI模型分享》 📑君子坐而论道,少年起而行之 ​​ 图像识别任务是人工智能计算机视觉领域一个重要的子任务,本篇文章将通过使用一个预训练模型来帮助读者快速上手图像识别任务,对应的文件可通过关注文章末尾的公众号领取 本篇文章需要一定

    2024年02月03日
    浏览(32)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包