电商网站建设如何,云开发,网站案例分析,外卖网站建设的策划书去年#xff0c;我们写过一篇关于JMH的入门使用的文章#xff1a;Java基准测试工具JMH使用#xff0c;今天我们再来聊一下关于JMH的高阶使用。主要我们会围绕着以下几点来讲#xff1a;
对称并发测试非对称并发测试阻塞并发测试Map并发测试
关键词
State 在很多时候我们…去年我们写过一篇关于JMH的入门使用的文章Java基准测试工具JMH使用今天我们再来聊一下关于JMH的高阶使用。主要我们会围绕着以下几点来讲
对称并发测试非对称并发测试阻塞并发测试Map并发测试
关键词
State 在很多时候我们需要维护一些状态内容比如在多线程的时候我们会维护一个共享的状态这个状态值可能会在每根线程中都一样也有可能是每根线程都有自己的状态JMH为我们提供了状态的支持。该注解只能用来标注在类上因为类作为一个属性的载体。State的状态值主要有以下几种
Scope.Benchmark 该状态的意思是会在所有的Benchmark的工作线程中共享变量内容。 Scope.Group 同一个Group的线程可以享有同样的变量 Scope.Thread 每个线程都享有一份变量的副本线程之间对于变量的修改不会相互影响
Group 执行组的识别号 GroupThreads 执行某个方法所需要的线程数量
对称并发测试
我们编写的所有基准测试都会被JMH框架根据方法名的字典顺序排序之后串行执行然而有些时候我们会想要对某个类的读写方法并行执行比如我们想要在修改某个原子变量的时候又有其他线程对其进行读取操作。
BenchmarkMode(Mode.AverageTime)
Fork(1)
Warmup(iterations 5, time 1)
Measurement(iterations 5, time 1)
OutputTimeUnit(TimeUnit.MICROSECONDS)
State(Scope.Group)
public class SymmetricBenchmark {private AtomicLong counter;Setuppublic void init() {this.counter new AtomicLong();}GroupThreads(5)Group(atomic)Benchmarkpublic void inc() {this.counter.incrementAndGet();}GroupThreads(5)Group(atomic)Benchmarkpublic long get() {return this.counter.get();}public static void main(String[] args) throws RunnerException {Options opt new OptionsBuilder().include(SymmetricBenchmark.class.getSimpleName()).build();new Runner(opt).run();}
}结果为:
Benchmark Mode Cnt Score Error Units
SymmetricBenchmark.atomic avgt 5 0.126 ± 0.009 us/op
SymmetricBenchmark.atomic:get avgt 5 0.062 ± 0.011 us/op
SymmetricBenchmark.atomic:inc avgt 5 0.190 ± 0.011 us/op我们在对AtomicLong进行自增操作的同时又会对其进行读取操作这就是我们经常见到的高并发环境中某些API的操作方式同样也是线程安全存在隐患的地方。5个线程对AtomicLong执行自增操作5个线程对AtomicLong执行读取时的性能输出说明如下
group atomic5个读线程5个写线程的平均响应时间为0.126 us误差为0.009。group atomic5个读线程同时读取AtomicLong变量的速度为0.062 us误差为0.011。group atomic5个写线程同时修改AtomicLong变量的速度为0.190 us误差为0.011 。
非对称并发测试
有时您需要达到非对称测试的目的。
Fork(1)
BenchmarkMode(Mode.AverageTime)
OutputTimeUnit(TimeUnit.MICROSECONDS)
Warmup(iterations 5, time 1)
Measurement(iterations 5, time 1)
State(Scope.Group)
public class AsymmetricBenchMark {private AtomicLong counter;Setuppublic void up() {counter new AtomicLong();}BenchmarkGroup(atomic)GroupThreads(3)public long inc() {return counter.incrementAndGet();}BenchmarkGroup(atomic)GroupThreads(1)public long get() {return counter.get();}public static void main(String[] args) throws RunnerException {Options opt new OptionsBuilder().include(AsymmetricBenchMark.class.getSimpleName()).build();new Runner(opt).run();}
}结果为:
Benchmark Mode Cnt Score Error Units
AsymmetricBenchMark.atomic avgt 5 0.053 ± 0.003 us/op
AsymmetricBenchMark.atomic:get avgt 5 0.025 ± 0.006 us/op
AsymmetricBenchMark.atomic:inc avgt 5 0.062 ± 0.005 us/op我们在对AtomicLong进行自增操作的同时又会对其进行读取操作这就是我们经常见到的高并发环境中某些API的操作方式同样也是线程安全存在隐患的地方。3个线程对AtomicLong执行自增操作1个线程对AtomicLong执行读取时的性能输出说明如下
group atomic1个读线程3个写线程的平均响应时间为0.053 us误差为0.003 。group atomic1个读线程同时读取AtomicLong变量的速度为0.025 us误差为0.006 。group atomic3个写线程同时修改AtomicLong变量的速度为0.062 us误差为0.005 。
阻塞并发测试
有些时候我们想要执行某些容器的读写操作时可能会引起阻塞比如blockqueue,在某些情况下程序会出现长时间的阻塞这就严重影响了我们测试的结果我们可以通过设置Options的timeout来强制让每一个批次的度量超时超时的基准测试数据将不会被纳入统计之中。 以下测试我们设置每批次如果超过10秒就被认为超时不计入统计。
Fork(1)
BenchmarkMode(Mode.AverageTime)
Warmup(iterations 5, time 1)
Measurement(iterations 5, time 1)
OutputTimeUnit(TimeUnit.NANOSECONDS)
State(Scope.Group)
public class InterruptBenchmark {private BlockingQueueInteger queue;private final static int VALUE Integer.MAX_VALUE;Setuppublic void init() {this.queue new ArrayBlockingQueue(10);}GroupThreads(5)Group(queue)Benchmarkpublic void put()throws InterruptedException {this.queue.put(VALUE);}GroupThreads(5)Group(queue)Benchmarkpublic int take()throws InterruptedException {return this.queue.take();}public static void main(String[] args) throws RunnerException {Options opt new OptionsBuilder().include(InterruptBenchmark.class.getSimpleName())// 将每个批次的超时时间设置为10秒.timeout(TimeValue.milliseconds(10000)).build();new Runner(opt).run();}
}
结果为:
Benchmark Mode Cnt Score Error Units
InterruptBenchmark.queue avgt 5 19204.384 ± 23024.739 ns/op
InterruptBenchmark.queue:put avgt 5 14049.887 ± 49670.027 ns/op
InterruptBenchmark.queue:take avgt 5 24358.880 ± 31679.280 ns/op
有些执行时被阻塞的结果就被忽略了报告中会如下所示:
Iteration 5: (benchmark timed out, interrupted 1 times) 27130.727 ±(99.9%) 53300.757 ns/op如果超时时间设置得过小那么会得到如下警告:
# Timeout: 1000 ms per iteration, ***WARNING: The timeout might be too low!***Map并发测试
对比几大线程安全Map的多线程下的读写性能,以后类似的操作可以按照这个模板来。
Fork(1)
BenchmarkMode(Mode.Throughput)
Warmup(iterations 5, time 1)
Measurement(iterations 5, time 1)
OutputTimeUnit(TimeUnit.SECONDS)
State(Scope.Group)
public class MapBenchMark {Param({ConcurrentHashMap, ConcurrentSkipListMap, Hashtable, Collections.synchronizedMap})private String type;private MapInteger, Integer map;Setuppublic void setUp() {switch (type) {case ConcurrentHashMap:this.map new ConcurrentHashMap();break;case ConcurrentSkipListMap:this.map new ConcurrentSkipListMap();break;case Hashtable:this.map new Hashtable();break;case Collections.synchronizedMap:this.map Collections.synchronizedMap(new HashMap());break;default:throw new IllegalArgumentException(Illegal map type.);}}Group(map)GroupThreads(5)Benchmarkpublic void putMap() {int random randomIntValue();this.map.put(random, random);}Group(map)GroupThreads(5)Benchmarkpublic Integer getMap() {return this.map.get(randomIntValue());}/*** 计算一个随机值用作Map中的Key和Value** return*/private int randomIntValue() {return (int) Math.ceil(Math.random() * 600000);}public static void main(String[] args) throws RunnerException {Options opt new OptionsBuilder().include(MapBenchMark.class.getSimpleName()).build();new Runner(opt).run();}
}结果如下:
Benchmark (type) Mode Cnt Score Error Units
MapBenchMark.map ConcurrentHashMap thrpt 5 4903943.211 ± 208719.270 ops/s
MapBenchMark.map:getMap ConcurrentHashMap thrpt 5 2442687.631 ± 251150.685 ops/s
MapBenchMark.map:putMap ConcurrentHashMap thrpt 5 2461255.580 ± 260557.472 ops/s
MapBenchMark.map ConcurrentSkipListMap thrpt 5 3471371.602 ± 334184.434 ops/s
MapBenchMark.map:getMap ConcurrentSkipListMap thrpt 5 1710540.889 ± 196183.472 ops/s
MapBenchMark.map:putMap ConcurrentSkipListMap thrpt 5 1760830.713 ± 263480.175 ops/s
MapBenchMark.map Hashtable thrpt 5 1966883.854 ± 197740.289 ops/s
MapBenchMark.map:getMap Hashtable thrpt 5 676801.687 ± 71672.436 ops/s
MapBenchMark.map:putMap Hashtable thrpt 5 1290082.167 ± 174730.435 ops/s
MapBenchMark.map Collections.synchronizedMap thrpt 5 1976316.282 ± 99878.457 ops/s
MapBenchMark.map:getMap Collections.synchronizedMap thrpt 5 655744.125 ± 73634.788 ops/s
MapBenchMark.map:putMap Collections.synchronizedMap thrpt 5 1320572.158 ± 75428.848 ops/s我们可以看到在 putMap 和 getMap 方法中通过随机值的方式将取值作为 key 和 value 存入 map 中同样也是通过随机值的方式将取值作为 key 从 map 中进行数据读取当然读取的值可能并不存在。还有我们在基准方法中进行了随机值的运算虽然随机值计算所耗费的CPU时间也会被纳入基准结果的统计中但是每一个 map 都进行了相关的计算因此我们可以认为大家还是站在了同样的起跑线上故而可以对其忽略不计。
基准测试的数据可以表明在5个线程同时进行 map 写操作5个线程同时进行读操作时参数 typeConcurrentHashMap 的性能是最佳的 。
下一篇将和大家介绍下JMH的profiler
