JMH-并发包分析

最新推荐文章于 2022-12-01 21:19:25 发布
最新推荐文章于 2022-12-01 21:19:25 发布
阅读量347 收藏
点赞数
分类专栏： JUC JAVA 文章标签： java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_43156556/article/details/126922882
版权
JAVA 同时被 2 个专栏收录
12 篇文章 0 订阅
订阅专栏
JUC
5 篇文章 0 订阅
订阅专栏

内容来源：Java 高并发编程详解~深入理解并发核心库汪文君

目的：复现书中使用 JMH 代码微基准测试工具基测试常见的并发包和集合类的过程，对并发性能问题做初步了解

内容：

① 了解 JMH ：ArrayList 和 LinkedList 的测试对比

② 常见并发包测试

1. JMH

JMH : Java Micro Benchmark Harness，专门用于代码微基准测试的工具集

1.1 JMH 测试 ArrayList 和 LinkedList

① 创建 maven 工程

② 引入 JMH 依赖

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

③ 测试代码

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MICROSECONDS)
@State(Scope.Thread)
public class JMHExample01 {

    private final static String DATA = "DUMMY DATA";

    private List<String> arrayList;

    private List<String> linkedList;

    @Setup(Level.Iteration)
    public void setUp(){
        this.arrayList = new ArrayList<>();
        this.linkedList = new LinkedList<>();
    }
    @Benchmark
    public List<String> arrayListAdd(){
        this.arrayList.add(DATA);
        return arrayList;
    }
    @Benchmark
    public List<String> linkedListAdd(){
        this.linkedList.add(DATA);
        return linkedList;
    }
    public static void main(String[] args) throws RunnerException {
       final Options opts = new OptionsBuilder().include(JMHExample01.class.getSimpleName())
           .forks(1)
           .measurementIterations(10)
           .warmupIterations(10)
           .build();
       new Runner(opts).run();
    }
}

④ 测试结果

...
# Run complete. Total time: 00:01:06

Benchmark                              Mode  Cnt  Score   Error  Units
MemoryTest.JMHExample01.arrayListAdd   avgt   10  0.019 ± 0.012  us/op
MemoryTest.JMHExample01.linkedListAdd  avgt   10  0.130 ± 0.092  us/op

测试结论：

ArrayList.add() 方法的调用平均响应时间为 0.019 us，误差在 0.012 us

LinkedList.add() 方法的调用平均响应时间为 0.013 us，误差在 0.092 us

1.2 参数说明

1.2.1 @Benchmark

JMH 使用 @Benchmark 对基准测试方法进行标记，区别于普通方法，被标记的方法会执行基准测试

@Benchmark 之于 JMH 等价于 @Test 之于 Junit4.x

返回到上述代码，@Benchmark 被用在两个测试方法 arrayListAdd() 和 linkedListAddd() 上

1.2.2 Warmup 及 Measurement

Warmup 及 Measurement 的作用：分批次执行基准测试方法

Warmup ：在基准测试代码正式度量前，对其进行预热，使得代码的执行经历过了类的早期优化、JVM 运行期编译、JIT 优化后的最终状态

Measurement ：度量操作，每轮的度量中，所有的度量数据会被纳入统计中

本例：构造 Optins 时设置 Warmup 和 Measurement 的执行批次

final Options opts = new OptionsBuilder().include(JMHExample01.class.getSimpleName())
           .forks(1)
           .measurementIterations(10) // 10 次调度批次对基准方法的执行和调用都会纳入统计
           .warmupIterations(10) // 进行真正的度量前，会对代码进行 3 个批次的热身
           .build();

1.2.3 forks()

基准测试方法间与其所在的测试类 JVM 进程共享，可能会存在干扰

将 fork 设置为 1，每次运行基准测试时都会开辟一个全新的 JVM 进程对其进行测试，多个基准测试间将不会存在干扰

1.2.4 @BenchcmarkMode(…)

JMH 使用 @BenchmarkMode 注解声明使用那种发模式来运行

四种模式：

  • AverageTime 平均响应时间：输出基准测试方法每次调用一次所耗费的时间
  • Throughput 方法吞吐量：输出单位时间内可对该方法调用多少次
  • SampleTime 时间采样：采用一种抽样的方式来统计基准测试方法的性能结果
  • SingleShotTime 冷测试：Warmup 和 Measurement 在每个批次中基准测试方法只会被执行一次

1.2.5 OutputTimeUnit

OutputTimeUnit 统计结果输出时的单位

@OutputTimeUnit(TimeUnit.MICROSECONDS)

可在 class 上设置，也可在基准方法上设置

1.2.6 State(…)

State 对应 Scope 的三个枚举值

  • Thread ：Thread 独享的 State ，每个运行基准测试方法的线程都会持有一个独立的对象实例
  • Benchmark ：Thread 共享的 State，多线程共享同一个实例
  • Group ：线程组共享的 State，多线程共享同一个实例，且允许多个基准测试方法并发并行允许

1.2.7 Setup(…)

@Setup 在每个基准测试方法执行前被调用，通常用于资源的初始化

@TearDown ：在基准测试方法被执行之后被调用，通常用于资源的回收清理工作

上述两个注解是JMH的套件测试，类似于 Junit 中的 @Before, @After, @BeforeClass, @AfterClass

@Setup(Level.Iteration)，其中的 Level 用于配置上述两个套件执行方式

  • Level.Trial ：在每个基准测试方法的所有批次执行的前后被执行
  • Level.Iteration ：在每个基准测试方法的每个批次执行的前后被执行
  • Level.Invocation ：在每个基准测试方法的每次度量执行的前后被执行

2. 并发包测试

2.1 AtomicInteger 性能测试

@Measurement(iterations = 10)
@Warmup(iterations = 10)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MICROSECONDS)
public class Synchronized_Lock_AtomicInteger {

    @State(Scope.Group)
    public static class IntMonitor{
        private int x;
        private final Lock lock = new ReentrantLock();
        // 使用显式锁 Lock 进行共享资源同步
        public void lockInc(){
            lock.lock();
            try{
                x++;
            }finally {
                lock.unlock();
            }
        }
        // 使用 synchronized 关键字进行共享资源同步
        public void synInc(){
            synchronized (this){
                x++;
            }
        }
    }
    @State(Scope.Group)
    public static class AtomicIntegerMonitor{
        private AtomicInteger x = new AtomicInteger();
        public void inc(){
            x.incrementAndGet();
        }
    }

    @GroupThreads(10)
    @Group("sync")
    @Benchmark
    public void syncInc(IntMonitor monitor){
        monitor.synInc();
    }

    @GroupThreads(10)
    @Group("lock")
    @Benchmark
    public void lockInc(IntMonitor monitor){
        monitor.lockInc();
    }

    @GroupThreads(10)
    @Group("atomic")
    @Benchmark
    public void atomicIntegerInc(AtomicIntegerMonitor monitor){
        monitor.inc();
    }

    public static void main(String[] args) throws RunnerException {
        Options opts = new OptionsBuilder()
            .include(Synchronized_Lock_AtomicInteger.class.getSimpleName())
            .forks(1)
            .timeout(TimeValue.seconds(10))
            .addProfiler(StackProfiler.class)
            .build();
        new Runner(opts).run();
    }
}

输出结果：

Benchmark                                                 Mode  Cnt  Score   Error  Units
MemoryTest.Synchronized_Lock_AtomicInteger.atomic         avgt   10  0.190 ± 0.002  us/op
MemoryTest.Synchronized_Lock_AtomicInteger.lock           avgt   10  0.218 ± 0.003  us/op
MemoryTest.Synchronized_Lock_AtomicInteger.sync           avgt   10  0.281 ± 0.034  us/op

即：表现情况
AtomicInteger > ReentrantLock > Synchronized

上面的示例中加入了 .addProfiler(StackProfiler.class)

可以通过 StackProfiler 输出线程堆栈信息，统计程序在执行过程中线程状态的数据，比如 RUNNING 状态、WAIT 状态所占的百分比

## AtomicInteger
....[Thread state distributions].............
 98.2%         RUNNABLE
  1.8%         WAITING
## ReentrantLock
....[Thread state distributions].............
 78.0%         WAITING
 22.0%         RUNNABLE
## Synchronized
....[Thread state distributions].............
 69.7%         BLOCKED
 29.5%         RUNNABLE
  0.8%         WAITING

即 AtomicInteger 的 RUNNABLE 状态高达 98.2%，并且没有 BLOCKED 状态，

而 synchronized 关键字则相反，BLOCK 状态高达 68.5%

本质上 AtomicInteger 是基于 Unsafe 类的 compareAndSwap 来实现的

Unsafe 由 C++ 实现，内部存在大量的汇编 CPU 指令等代码

此处需要补充一篇关于 Unsafe 类的解读

2.2 ReentrantLock - Synchronized

2.2.1 使用 Blackdhole

pg 30 基准测试方法中，需要将两个计算结果作为返回值

JMH 提供了一个称为 Blackhole 类，可以在不作任何返回的情况下避免 Dead Code 的发生

2.2.2 单线程读操作性能对比

@Measurement(iterations = 10)
@Warmup(iterations = 10)
@BenchmarkMode(Mode.AverageTime)
@Threads(1)
@OutputTimeUnit(TimeUnit.MICROSECONDS)
@State(Scope.Thread)
public class ReentrantLockExample4 {
    public static class Test{
        private int x = 10;
        private final Lock lock = new ReentrantLock();
        public int baseMethod(){
            return x;
        }

        public int lockMethod(){
            lock.lock();
            try{
                return x;
            }finally {
                lock.unlock();
            }
        }

        public int syncMethod(){
            synchronized (this){
                return x;
            }
        }
    }
    private Test test;
    @Setup(Level.Iteration)
    public void setUp(){
        this.test = new Test();
    }
    @Benchmark
    public void base(Blackhole hole){
        hole.consume(test.baseMethod());
    }
    @Benchmark
    public void testLockMethod(Blackhole hole){
        hole.consume(test.lockMethod());
    }
    @Benchmark
    public void testSyncMethod(Blackhole hole){
        hole.consume(test.syncMethod());
    }

    public static void main(String[] args) throws RunnerException {
        Options opts = new OptionsBuilder()
            .include(ReentrantLockExample4.class.getSimpleName())
            .forks(1)
            .build();
        new Runner(opts).run();
    }
}

测试结果

Benchmark                                        Mode  Cnt  Score    Error  Units
MemoryTest.ReentrantLockExample4.base            avgt   10  0.002 ±  0.001  us/op
MemoryTest.ReentrantLockExample4.testLockMethod  avgt   10  0.019 ±  0.001  us/op
MemoryTest.ReentrantLockExample4.testSyncMethod  avgt   10  0.004 ±  0.001  us/op

结论：单线程访问情况下，synchronized 关键字的性能远高于 lock 锁

2.2.3 多线程读操作性能对比

@Measurement(iterations = 10)
@Warmup(iterations = 10)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MICROSECONDS)

public class ReentrantLockExample5 {
    @State(Scope.Group)
    public static class Test{
        private int x = 10;
        private final Lock lock = new ReentrantLock();
        public int baseMethod(){
            return x;
        }

        public int lockMethod(){
            lock.lock();
            try{
                return x;
            }finally {
                lock.unlock();
            }
        }

        public int syncMethod(){
            synchronized (this){
                return x;
            }
        }
    }
    @GroupThreads(10)
    @Group("base")
    @Benchmark
    public void base(Test test, Blackhole hole){
        hole.consume(test.baseMethod());
    }
    @GroupThreads(10)
    @Group("lock")
    @Benchmark
    public void testLockMethod(Test test, Blackhole hole){
        hole.consume(test.lockMethod());
    }
    @GroupThreads(10)
    @Group("sync")
    @Benchmark
    public void testSyncMethod(Test test, Blackhole hole){
        hole.consume(test.syncMethod());
    }

    public static void main(String[] args) throws RunnerException {
        Options opts = new OptionsBuilder()
            .include(ReentrantLockExample5.class.getSimpleName())
            .forks(1)
            .build();
        new Runner(opts).run();
    }
}

测试结果：

Benchmark                              Mode  Cnt  Score    Error  Units
MemoryTest.ReentrantLockExample5.base  avgt   10  0.005 ±  0.001  us/op
MemoryTest.ReentrantLockExample5.lock  avgt   10  0.241 ±  0.003  us/op
MemoryTest.ReentrantLockExample5.sync  avgt   10  0.277 ±  0.004  us/op

测试结论：多线程读操作情况下，显式锁 Lock 的性能优于 synchronized 关键字

2.2.4 多线程下读写操作性能对比

设置 10 个线程，其中 5 个线程并发修改共享资源，5 个线程并发读取共享资源

@Measurement(iterations = 10)
@Warmup(iterations = 10)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MICROSECONDS)
public class ReentrantLockExample6 {
    @State(Scope.Group)
    public static class Test{
        private int x = 10;
        private final Lock lock = new ReentrantLock();
        public void lockInc(){
            lock.lock();
            try{
                x++;
            }finally {
                lock.unlock();
            }
        }
        public int lockGet(){
            lock.lock();
            try{
                return x;
            }finally {
                lock.unlock();
            }
        }
        public void syncInc(){
            synchronized (this){
                x++;
            }
        }
        public int syncGet(){
            synchronized (this){
                return x;
            }
        }
    }
    @GroupThreads(5)
    @Group("lock")
    @Benchmark
    public void lockInc(Test test){
        test.lockInc();
    }
    @GroupThreads(5)
    @Group("lock")
    @Benchmark
    public void lockGet(Test test, Blackhole blackhole){
        blackhole.consume(test.lockGet());
    }

    @GroupThreads(5)
    @Group("sync")
    @Benchmark
    public void syncInc(Test test){
        test.syncInc();
    }
    @GroupThreads(5)
    @Group("sync")
    @Benchmark
    public void syncGet(Test test, Blackhole blackhole){
        blackhole.consume(test.syncGet());
    }

    public static void main(String[] args) throws RunnerException {
        Options opts = new OptionsBuilder()
            .include(ReentrantLockExample6.class.getSimpleName())
            .forks(1)
            .build();
        new Runner(opts).run();
    }
}

测试结果

Benchmark                                      Mode  Cnt  Score   Error  Units
MemoryTest.ReentrantLockExample6.lock          avgt   10  0.224 ± 0.003  us/op
MemoryTest.ReentrantLockExample6.lock:lockGet  avgt   10  0.242 ± 0.020  us/op
MemoryTest.ReentrantLockExample6.lock:lockInc  avgt   10  0.207 ± 0.016  us/op
MemoryTest.ReentrantLockExample6.sync          avgt   10  0.268 ± 0.001  us/op
MemoryTest.ReentrantLockExample6.sync:syncGet  avgt   10  0.278 ± 0.005  us/op
MemoryTest.ReentrantLockExample6.sync:syncInc  avgt   10  0.257 ± 0.003  us/op

现在存在的问题是：里面的那个 lock 和 sync 是哪里的？

应该是 lock 对应的 10 个线程组【5个读线程，5 个写线程】的平均响应时间

2.3 ReentrantReadWriteLock

2.3.1 多线程只读性能比较

@Measurement(iterations = 10)
@Warmup(iterations = 10)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MICROSECONDS)
public class ReentrantReadWriteLockExample2 {

    @State(Scope.Group)
    public static class Test{
        private int x = 10;
        private final Lock lock = new ReentrantLock();
        public int baseMethod(){
            return x;
        }
        public int lockMethod(){
            lock.lock();
            try{
                return x;
            }finally {
                lock.unlock();
            }
        }
        public int syncMethod(){
            synchronized (this){
                return x;
            }
        }

        private final ReadWriteLock readWriteLock = new ReentrantReadWriteLock();
        private final Lock readLock = readWriteLock.readLock();
        public int readLockMethod(){
            readLock.lock();
            try{
                return x;
            }finally {
                readLock.unlock();
            }
        }
    }
    @GroupThreads(10)
    @Group("base")
    @Benchmark
    public void base(Test test, Blackhole hole){
        hole.consume(test.baseMethod());
    }
    @GroupThreads(10)
    @Group("lock")
    @Benchmark
    public void testLockMethod(Test test, Blackhole hole){
        hole.consume(test.lockMethod());
    }
    @GroupThreads(10)
    @Group("sync")
    @Benchmark
    public void testSyncMethod(Test test, Blackhole hole){
        hole.consume(test.syncMethod());
    }

    @GroupThreads(10)
    @Group("readLocks")
    @Benchmark
    public void testReadLockMethod(Test test, Blackhole hole){
        hole.consume(test.readLockMethod());
    }

    public static void main(String[] args) throws RunnerException {
        Options opts = new OptionsBuilder()
            .include(ReentrantReadWriteLockExample2.class.getSimpleName())
            .forks(1)
            .build();
        new Runner(opts).run();
    }
}

测试结果：

Benchmark                                            Mode  Cnt  Score   Error  Units
MemoryTest.ReentrantReadWriteLockExample2.base       avgt   10  0.007 ± 0.001  us/op
MemoryTest.ReentrantReadWriteLockExample2.lock       avgt   10  0.241 ± 0.006  us/op
MemoryTest.ReentrantReadWriteLockExample2.readLocks  avgt   10  1.809 ± 0.019  us/op
MemoryTest.ReentrantReadWriteLockExample2.sync       avgt   10  0.316 ± 0.016  us/op

结论：

10 个线程并发只读情况下，性能表现好坏程度：

ReentrantLock > synchronized > ReentrantReadWriteLock

即在没有任何写操作情况下，读锁效率反而是最差的，因此在 JDK 1.8 版本中引入 StampedLock

2.3.2 多线程读写性能比较

设置 5 个线程读 5 个线程写

@Measurement(iterations = 10)
@Warmup(iterations = 10)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MICROSECONDS)
public class ReentrantReadWriteLockExample3 {

    @State(Scope.Group)
    public static class Test{
        private int x = 10;
        private final Lock lock = new ReentrantLock();
        private final ReadWriteLock readWriteLock = new ReentrantReadWriteLock();
        private final Lock readLock = readWriteLock.readLock();
        private final Lock writeLock = readWriteLock.writeLock();
        public void lockInc(){
            lock.lock();
            try{
                x++;
            }finally {
                lock.unlock();
            }
        }
        public int lockGet(){
            lock.lock();
            try{
                return x;
            }finally {
                lock.unlock();
            }
        }
        public void syncInc(){
            synchronized (this){
                x++;
            }
        }
        public int syncGet(){
            synchronized (this){
                return x;
            }
        }
        public void writeLockInc(){
            writeLock.lock();
            try{
                x++;
            }finally {
                writeLock.unlock();
            }
        }
        public int readLockGet(){
            readLock.lock();
            try{
                return x;
            }finally {
                readLock.unlock();
            }
        }
    }
    @GroupThreads(5)
    @Group("lock")
    @Benchmark
    public void lockInc(Test test){
        test.lockInc();
    }
    @GroupThreads(5)
    @Group("lock")
    @Benchmark
    public void lockGet(Test test, Blackhole blackhole){
        blackhole.consume(test.lockGet());
    }

    @GroupThreads(5)
    @Group("sync")
    @Benchmark
    public void syncInc(Test test){
        test.syncInc();
    }
    @GroupThreads(5)
    @Group("sync")
    @Benchmark
    public void syncGet(Test test, Blackhole blackhole){
        blackhole.consume(test.syncGet());
    }

    @GroupThreads(5)
    @Group("rwlock")
    @Benchmark
    public void writeLockInc(Test test){
        test.writeLockInc();
    }
    @GroupThreads(5)
    @Group("rwlock")
    @Benchmark
    public void readLockGet(Test test, Blackhole blackhole){
        blackhole.consume(test.readLockGet());
    }

    public static void main(String[] args) throws RunnerException {
        Options opts = new OptionsBuilder()
            .include(ReentrantReadWriteLockExample3.class.getSimpleName())
            .forks(1)
            .build();
        new Runner(opts).run();
    }
}

测试结果：

Benchmark                                                      Mode  Cnt  Score   Error  Units
MemoryTest.ReentrantReadWriteLockExample3.lock                 avgt   10  0.229 ± 0.005  us/op
MemoryTest.ReentrantReadWriteLockExample3.lock:lockGet         avgt   10  0.252 ± 0.014  us/op
MemoryTest.ReentrantReadWriteLockExample3.lock:lockInc         avgt   10  0.207 ± 0.007  us/op
MemoryTest.ReentrantReadWriteLockExample3.rwlock               avgt   10  0.542 ± 0.033  us/op
MemoryTest.ReentrantReadWriteLockExample3.rwlock:readLockGet   avgt   10  0.842 ± 0.062  us/op
MemoryTest.ReentrantReadWriteLockExample3.rwlock:writeLockInc  avgt   10  0.242 ± 0.006  us/op
MemoryTest.ReentrantReadWriteLockExample3.sync                 avgt   10  0.277 ± 0.011  us/op
MemoryTest.ReentrantReadWriteLockExample3.sync:syncGet         avgt   10  0.297 ± 0.012  us/op
MemoryTest.ReentrantReadWriteLockExample3.sync:syncInc         avgt   10  0.256 ± 0.010  us/op

可以看到 ReentrantReadWriteLock 在并发情况下读锁的性能并不高，反而是写锁的性能稍好？

什么原因呢？

2.4 StampedLock

StampedLock 简要了解：

  1. 可使用 lock.writeLock() 替代 ReentrantLock
  2. 提供读锁，写锁两种模式可替代 ReentrantReadWriteLockc
  3. 乐观读模式 tryOptimisticRead() 方法获取一个非排他锁并且不会进入阻塞状态

2.4.1 可重入锁，读写锁，StampedLock 性能对比

比较 ReentrantLock, ReentrantReadWriteLock, StampedLock 的性能表现
测试吞吐量：每秒的方法吞吐量 / 调用次数，数值越大代表吞吐量越高

  1. 读写分离场景
  2. 乐观锁场景【不同读写线程】
@Measurement(iterations = 20)
@Warmup(iterations = 20)
@BenchmarkMode(Mode.Throughput)
@OutputTimeUnit(TimeUnit.SECONDS)
public class StampedLockExampled4 {
    @State(Scope.Group)
    public static class Test{
        private int x = 10;
        private final Lock lock = new ReentrantLock();
        private final ReadWriteLock readWriteLock = new ReentrantReadWriteLock();
        private final Lock readLock = readWriteLock.readLock();
        private final Lock writeLock = readWriteLock.writeLock();
        private final StampedLock stampedLock = new StampedLock();
        public void stampedLockInc(){
            long stamped = stampedLock.writeLock();
            try{
                x++;
            }finally {
                stampedLock.unlockWrite(stamped);
            }
        }

        public int stampedReadLockGet(){
            long stamped = stampedLock.readLock();
            try{
                return x;
            }finally {
                stampedLock.unlockRead(stamped);
            }
        }

        public int stampedOptimisticReadLockGet(){
            long stamped = stampedLock.tryOptimisticRead();
            if(!stampedLock.validate(stamped)){
                stamped = stampedLock.readLock();
                try{
                    return x;
                }finally {
                    stampedLock.unlockRead(stamped);
                }
            }
            return x;
        }

        public void lockInc(){
            lock.lock();
            try{
                x++;
            }finally {
                lock.unlock();
            }
        }

        public int lockGet(){
            lock.lock();
            try{
                return x;
            }finally {
                lock.unlock();
            }
        }

        public void writeLockInc(){
            writeLock.lock();
            try{
                x++;
            }finally {
                writeLock.unlock();
            }
        }

        public int readLockGet(){
            readLock.lock();
            try{
                return x;
            }finally {
                readLock.unlock();
            }
        }
    }

    @GroupThreads(5)
    @Group("lock")
    @Benchmark
    public void lockInc(Test test){
        test.lockInc();
    }

    @GroupThreads(5)
    @Group("lock")
    @Benchmark
    public void lockGet(Test test, Blackhole blackhole){
        blackhole.consume(test.lockGet());
    }

    @GroupThreads(5)
    @Group("rwlock")
    @Benchmark
    public void writeLockInc(Test test){
        test.writeLockInc();
    }

    @GroupThreads(5)
    @Group("rwlock")
    @Benchmark
    public void readLockGet(Test test, Blackhole blackhole){
        blackhole.consume(test.readLockGet());
    }

    @GroupThreads(5)
    @Group("stampedLock")
    @Benchmark
    public void writeStampedLockInc(Test test){
        test.stampedLockInc();
    }

    @GroupThreads(5)
    @Group("stampedLock")
    @Benchmark
    public void readStampedLockGet(Test test, Blackhole blackhole){
        blackhole.consume(test.stampedReadLockGet());
    }

    @GroupThreads(5)
    @Group("stampedLockOptimistic")
    @Benchmark
    public void writeStampedLockInc2(Test test){
        test.stampedLockInc();
    }

    @GroupThreads(5)
    @Group("stampedLockOptimistic")
    @Benchmark
    public void readStampedLockGet2(Test test, Blackhole blackhole){
        blackhole.consume(test.stampedOptimisticReadLockGet());
    }

    public static void main(String[] args) throws RunnerException {
        Options opts = new OptionsBuilder()
            .include(StampedLockExampled4.class.getSimpleName())
            .forks(1)
            .build();
        new Runner(opts).run();
    }
}

测试结果：
① 5 个读线程 5 个写线程总体性能对比【吞吐量】

ReentrantLockReentrantRWLockStampedLockOptimistic
34410694.19722397554.51123228158.44384757158.553

性能表现：Optimistic > ReentrantLock > StampedLock > ReentrantRWLock

② 5 个读线程 5 个写线程读性能对比【吞吐量】

ReentrantLockReentrantRWLockStampedLockOptimistic
16541110.9584797570.36864686.32559849633.846

性能表现：Optimistic > ReentrantLock > ReentrantRWLock > StampedLock

③ 5 个读线程 5 个写线程写性能对比【吞吐量】

ReentrantLockReentrantRWLockStampedLockOptimistic
17869583.23917599984.14323163472.11824907524.707

性能表现：Optimistic > StampedLock > ReentrantLock > ReentrantRWLock

这里 Optimistic 的写测试方法，实际上是和 StampedLock 一样的，测试结果与书上不同

差别仅体现在 StampedLock 分别调用 readLock() 和 trytryOptimisticRead() 转换到调用 writeLock() 的差别

扩展测试：

  1. 10 个读线程 10 个写线程：@GroupThreads(10)
  2. 16 个读线程 4 个写线程：读测试方法设置 @GroupThreads(16)写测试方法设置 @GroupThreads(4)

StampedLock 总结：

  1. 提供 乐观读 的方式
  2. 解决了读写锁中的 “饥饿写” 问题

2.5 ConcurrentQueue

2.5.1 七种阻塞队列

ArrayBlockingQueue:

阻塞写非阻塞写阻塞读非阻塞读
void put(E e)boolean add(E e)E take()E poll()
boolean offer(E e, Long timeout, TimeUnit unit)boolean offer(E e)E poll(Long timeout, TimeUnit unit)E peek()

PriorityBlockingQueue: 无边界阻塞队列，根据某种规则对插入队列尾部的元素进行排序

主要特点：头插和头删，每次插入删除都会进行调整

阻塞写非阻塞写阻塞读非阻塞读
offer(E e)E take()E poll()
E poll(Long timeout, TimeUnit unit)E peek()

LinkedBlockingQueue: 可选边界，基于链表实现 FIFO 队列

可选边界：有边界在构造函数中指明 capacity，无边界默认 Integer.MAX_VALUE

DelayQueue: 无边界阻塞队列，存入其中的数据元素会被延迟单位时间后才消费

存入其中的元素类型必须是 Delayed 接口的子类

SynchronousQueue: 无容量概念，每次对其写入操作必须等待(阻塞)其他线程进行对应的移除操作

LinkedBlockingDeque: 基于链表实现的双向阻塞队列，支持队尾写入数据，读取移除数据；队头写入数据，读取移除数据

LinkedTransferQueue: 是 TransferQueue 接口的实现类，无界队列，具有 FIFO 特性

2.5.2 并发队列的性能

以下程序：设置 10 个线程同时读写( 5 个线程向队列尾部插入数据， 5 个线程从队列头部读取数据)

对比：ConcurrentLinkedQueue 和自定义的使用 synchronized 封装 LinkedList 实现的并发队列 SynchronizedLinkedList

@Warmup(iterations = 10)
@Measurement(iterations = 10)
@Fork(1)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MICROSECONDS)
@State(Scope.Group)
public class ConcurrentLinkedQueueVsSynchronizedList {

    private SynchronizedLinkedList synchronizedList;
    private ConcurrentLinkedQueue<String> concurrentLinkedQueue;
    private final static String DATA = "TEST";
    private final static Object LOCK = new Object();

    private static class SynchronizedLinkedList{
        private LinkedList<String> list = new LinkedList<>();

        void addLast(String element){
            synchronized (LOCK){
                list.addLast(element);
            }
        }
        String removeFirst(){
            synchronized (LOCK){
                if(list.isEmpty()){
                    return null;
                }
                return list.removeFirst();
            }
        }
    }

    @Setup(Level.Iteration)
    public void setUp(){
        synchronizedList = new SynchronizedLinkedList();
        concurrentLinkedQueue = new ConcurrentLinkedQueue<>();
    }

    @Group("sync")
    @Benchmark
    @GroupThreads(5)
    public void synchronizedListAdd(){
        synchronizedList.addLast(DATA);
    }

    @Group("sync")
    @Benchmark
    @GroupThreads(5)
    public String synchronizedListGet(){
        return synchronizedList.removeFirst();
    }

    @Group("concurrent")
    @Benchmark
    @GroupThreads(5)
    public void concurrentLinkedQueueAdd(){
        concurrentLinkedQueue.offer(DATA);
    }

    @Group("concurrent")
    @Benchmark
    @GroupThreads(5)
    public String concurrentLinkedQueueGet(){
        return concurrentLinkedQueue.poll();
    }

    public static void main(String[] args) throws RunnerException {
        final Options opt = new OptionsBuilder()
            .include(ConcurrentLinkedQueueVsSynchronizedList.class.getSimpleName())
            .build();
        new Runner(opt).run();
    }
}

测试结果：

Benchmark                                                                               Mode  Cnt  Score   Error  Units
MemoryTest.ConcurrentLinkedQueueVsSynchronizedList.concurrent                           avgt   10  0.534 ± 0.051  us/op
MemoryTest.ConcurrentLinkedQueueVsSynchronizedList.concurrent:concurrentLinkedQueueAdd  avgt   10  0.643 ± 0.055  us/op
MemoryTest.ConcurrentLinkedQueueVsSynchronizedList.concurrent:concurrentLinkedQueueGet  avgt   10  0.425 ± 0.060  us/op
MemoryTest.ConcurrentLinkedQueueVsSynchronizedList.sync                                 avgt   10  0.773 ± 0.029  us/op
MemoryTest.ConcurrentLinkedQueueVsSynchronizedList.sync:synchronizedListAdd             avgt   10  0.508 ± 0.018  us/op
MemoryTest.ConcurrentLinkedQueueVsSynchronizedList.sync:synchronizedListGet             avgt   10  1.038 ± 0.043  us/op

测试结论：并发队列采用 无锁算法实现，因此在并发情况下其读写性能优于使用synchronized 实现同步的 LinkedList

无锁算法：

例如其中的 offer() 方法

if (p.casNext(null, newNode)) {
    // Successful CAS is the linearization point
    // for e to become an element of this queue,
    // and for newNode to become "live".
    if (p != t) // hop two nodes at a time
        casTail(t, newNode);  // Failure is OK.
    return true;
}
执霜
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
jmh-visualizer:直观地探索您的JMH基准
05-04
JMH可视化器 直观地查看您的基准！ 在线版本位于 ！ 带有2个配套项目： 特征 无服务器架构-所有操作均在您的浏览器中本地进行 可视化按基准测试类别分组的（一个JSON文件）的基准测试 带有分数和分数错误的垂直条形...
性能调优必备利器之 JMH
武培轩
06-01 838
if 快还是 switch 快？HashMap 的初始化 size 要不要指定，指定之后性能可以提高多少？各种序列化方法哪个耗时更短？无论出自何种原因需要进行性能评估，量化指标总是必要的...
性能调优之JMH必知必会2：JMH的基本用法
u014282578的博客
12-01 1860
性能调优之JMH的基本用法。
性能调优之JMH必知必会1：什么是JMH
u014282578的博客
12-01 7656
性能调优之什么是JMH。
并发编程之JMH
song1995924的博客
04-09 406
前言 这是我2021计划中的第一篇文章，今年准备深入探索JUC并发编程。 也准备梳理出整个体系的JUC相关知识，还请大家多多支持！ 第一篇文章为啥要选择JMH来展开学习呢？ 在后面的原子类体系、并发工具体系、并发容器体系、线程池体系、Stream体系等都会用到此工具进行测试，这也是JVM团队推荐我们使用的测量工具。 JMH简介 JMH是 Java Micro Benchmark Harness 的缩写，是专门用于代码微基准测试的工具集（toolkit） JMH是由现实的Java虚拟机的团队开发的，因此
使用JMH编写基准测试
赶路人儿
07-01 392
JMH 简介 if 快还是 switch 快？HashMap 的初始化 size 要不要指定，指定之后性能可以提高多少？各种序列化方法哪个耗时更短？ 无论出自何种原因需要进行性能评估，量化指标总是必要的。在大部分场合，简单地回答谁快谁慢是远远不够的，如何将程序性能量化呢？这就需要我们的主角 JMH 登场了！ JMH(Java Microbenchmark Harness)是用于代码微基准测试的工具套件，主要是基于方法层面的基准测试，精度可以达到纳秒级。该工具是由 Oracle 内部实现 JIT 的大牛
jmh-samples:一些 JMH - Java Microbenchmark Harness Samples
06-29
jmh-样本 一些 JMH - Java Microbenchmark Harness Samples 包含一些 JMH 示例代码。 地图推杆 比较 ConcurrentHashMap 与同步映射 原子基准 比较 AtomicLong 与 LongAdder 随机基准 比较 Random 与 ...
jmh-core-1.23.jar
08-05
OnJava8书中示例必须的jmh包。书中示例程序import了此包的类，如果没有此文件，OnJava8书中示例将无法在idea中顺利运行
idea-jmh-plugin.jar
06-16
IDEA JMH基准测试插件 微基准测试，他是测的某一个方法的性能到底是好或者不好，换了方法的实现之后他的性能到底好还是不好。
jmh-generator-bytecode-0.7.2.zip
10-12
fos-weka.zip,feedzai开放评分服务器-r实现feedzai开放评分服务器weka模块
JMH使用说明
lxbjkben的博客
03-01 2万+
JMH使用说明一、概述JMH，即Java Microbenchmark Harness，是专门用于代码微基准测试的工具套件。何谓Micro Benchmark呢？简单的来说就是基于方法层面的基准测试，精度可以达到微秒级。当你定位到热点方法，希望进一步优化方法性能的时候，就可以使用JMH对优化的结果进行量化的分析。
【高并发系列】24、JMH性能测试那些事儿
hellboy0621的博客
02-23 599
JMH官网 JMH is a Java harness for building, running, and analysing nano/micro/milli/macro benchmarks written in Java and other languages targetting the JVM. Java微基准测试框架JMH(Java Microbenchmark Harness)...
使用JMH进行并发测试
weixin_34034670的博客
07-24 518
为什么80%的码农都做不了架构师？>>> ...
Java 性能测试工具 JMH
冲吧，不要停！
05-23 9187
前言 最近在看《Java8函数式编程》时，发现了一个性能测试工具 JMH(Java Microbenchmark Harness)。这个工具方便了我们进行微基准测试。比如，在进行微基准测试时，我们想要测试的是“程序被JVM编译成机器代码（而不是直接执行字节码）”的执行速度。为了让JVM把要测试的代码编译成机器码，我们可能需要把要测试的代码进行“预热处理”（就是先跑几回，或十几回等，当运行的次多了
多线程与高并发（九）：单机压测工具JMH，单机最快MQ - Disruptor原理解析
热门推荐
寒泉
06-29 6万+
单机压测工具JMH JMH Java准测试工具套件 什么是JMH 官网 http://openjdk.java.net/projects/code-tools/jmh/ 创建JMH测试 1.创建Maven项目，添加依赖 <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/20
Java高并发(三.四)-JMH性能测试
Athazement的博客
10-30 656
性能测试的原因 部分并发程序是由串行程序改造而来,需要比较两种算法的性能 由于业务原因引入多线程,多线程并发控制导致性能损耗,评估损耗比重是否能够接受. 4.1 JMH JMH ( Java Microbenchmark Harness ) 是一个在 OpenJDK 项目中发布的， 专门用于性能 测试的框架， 其精度可以到达毫秒级. 4.2 JMH简单使用 导入JMH包 使用Maven导入,p...
使用JMH做Java微基准测试
weixin_33932129的博客
01-10 262
使用JMH做Java微基准测试 在使用Java编程过程中，我们对于一些代码调用的细节有多种编写方式，但是不确定它们性能时，往往采用重复多次计数的方式来解决。但是随着JVM不断的进化，随着代码执行次数的增加，JVM会不断的进行编译优化，使得重复多少次才能够得到一个稳定的测试结果变得让人疑惑，这时候有经验的同学就会在测试执行前先循环上万次并注释...
jmh gradle插件配置jfr输出
最新发布
06-06
implementation 'org.openjdk.jmh:jmh-core:1.27' implementation 'org.openjdk.jmh:jmh-generator-annprocess:1.27' implementation 'org.openjdk.jmh:jmh-generator-bytecode:1.27' annotationProcessor 'org....

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值