一个比较悲观锁和 CAS 乐观锁性能的简单实例引发的问题

大家周末好！

线程安全和锁这一块一直是我想理解清楚的问题，今天看了 https://www.v2ex.com/t/574995#reply13 的问题，再次引发了我对 java 锁这块知识的疑问。

我从网络上得知，使用 synchronized 包裹方法来实现悲观锁，这是重量级的，是性能不高的。使用 CAS 实现乐观锁，这是轻量级的，一定场合下性能高于前者。

所以我就想自己测下验证下这个结论，但是验证过程中遇到了和结论不匹配的结果，所以希望请教下大家

我的示例代码如下

public class Demo1 {
    private static final Sheep sheep = new Sheep(0);

    static class Sheep{
        private AtomicInteger size;

        public Sheep(int size) {
            this.size = new AtomicInteger(0);
        }

        public AtomicInteger getSize() {
            return size;
        }

        public void setSize(int size) {
            this.size.set(size);
        }

    }

    //悲观
    public synchronized static void increase1() {
        int value = sheep.getSize().intValue();
        sheep.setSize(value + 1);
    }

    //乐观(CAS)
    public static void increase2() {
        while (true){
            int expect = sheep.getSize().intValue();
            if(sheep.getSize().compareAndSet(expect,expect+1)){
                break;
            }
        }
    }
}

我使用如下代码来做耗时测试：

//10 个线程模拟 10 个用户，它们同时调用递增方法修改 size 属性,记录每次的耗时结果
public static void main(String[] args)  throws InterruptedException{
        long start = System.currentTimeMillis();
        long end = 0;

        ExecutorService executor = Executors.newFixedThreadPool(10);
        int callTime = 10000000;
        CountDownLatch countDownLatch = new CountDownLatch(callTime);
        
        for(int i=0; i<callTime; i++) {
            executor.execute(new Runnable() {
                @Override
                public void run() {
                    increase1();
                    //increase2();
                    countDownLatch.countDown();
                }
            });
        }
        
        countDownLatch.await();
        end = System.currentTimeMillis();
        executor.shutdown();
        
        System.out.println("调用次数：" + sheep.getSize().intValue());
        System.out.println("调用耗时: " + (end - start) );
    }

我的记录结果如下：

 *      总共操作 1000w 次，两者的耗时差不多,记录了 5 次运行的耗时：
 *      悲观递增耗时记录(毫秒)：6923，7030，6987，7353，7125
 *      乐观递增耗时记录(毫秒)：7149，7044，6937，6777，6717
 *
 *      总共操作 5000w 次，两者的耗时差不多,记录了 5 次运行的耗时：
 *      悲观递增耗时记录(毫秒)：49843，49807，51404，49143，49543
 *      乐观递增耗时记录(毫秒)：49762，48950，49376，48918，50324
 *
 *      测试环境是 IDEA，跑 main 方法

可以看到，这个案例下，悲观锁和 CAS 乐观锁在效率上没有很大的区别！为什么在这个案例下这两种实现在效率上没有区别呢？

mind3x

2019-06-23 18:37:46 +08:00

前 JVM 开发者，建议谨慎应用你的结论 :)

简单说 synchronized 并不一定就是悲观锁，JVM 会先尝试基于 CAS 的瘦锁，发现有 contention 再升级为重量级的悲观锁。

实际用哪种锁，取决于你并发的规模和读 /写比例。多数情况下，因为 synchronized 的自适应性，其实综合表现更好。不然为什么 Java 8 的 concurrenthashmap 仍然用 synchronized 来锁 slot。

你可以看下 https://blog.overops.com/java-8-stampedlocks-vs-readwritelocks-and-synchronized/，你的 CAS 实现大致对应里面的 StampedLock 版本。然后他里面的 optimistic 版本是 fail fast 的，其实没有比较意义。

另外要做 Java 的 microbenchmark，必须要考虑 JIT 的介入，还是得用 JMH，自己写个大循环加 current time millis 远远不够。

manecocomph

2019-06-23 23:42:22 +08:00

一点点建议:
1. JVM 慢热, 所以最好之前有个热身, 比如你要对比的代码在真正测试之前, 先运行 3000 遍, 热身之后会, 很多运行时优化都做完了, 才能真正反映性能;
2. increase1() 里面也是使用的 AtomicInteger, 这个里面使用的是 volatile int value, volatile 变量前后都要写回主存, 之前的 Synchronize 也有刷回主存的含义, 所以可能导致 synchronize 前后和 volatile 变量前后 2 次刷回主存, 影响部分性能.
3. 微观测试, 计时选用 System.nanoTime() 会更精确, 它经度更高.

如上面所说, Synchronize 现在是自适应, 从偏向锁开始, 轻量级, 到重量级, 不过你这里 10 个线程竞争很激烈, 估计很快升级到重量级锁.

另外如果你机器有 10 个以上 CPU, 这里的 CAS 竞争也异常激烈, 为了缓存一致性, 迫使 CPU 指令不断从主存拿数据, 更新主存, 导致 CPU 流水线不是那么顺畅. 另外是不是 CPU NUME aware 也会有部分影响.

zazalu

2019-06-23 23:48:08 +08:00

@mind3x
首先，非常感谢您的回答，让我见识匪浅！我也对自己草率的测试和草率的理解表示歉意！同时也对同步，锁这方面的技术研究感觉涉及范围之广，考虑要素之多而有点望而却步！（只负责写过小项目 crud 的 coder 再次感受到了 coder 与 coder 之间的差距！）

下面是我的一些小总结，也算是对自己的提问的初衷做一个交代。

假设有一个计数器，由于在计算机中，线程是可以同时“执行“的缘故，所以会容易发生少记一次的问题发生。于是人们想出了[线程同步]，它就像是一个门的锁，可以让线程执行到一个位置的时候停下来等候前一个线程执行完毕。通过这种思想，就可以解决前面发生的少记一次的问题。

但是这种思想带来了一个副作用，那就是使得程序的效率下降了。所以我们在尽可能达到目的的同时。推出了各种锁的实现来弱化这个副作用。目前来看，锁的实现思想有很多，下面是我个人可以 get 到的一些，
1. 最原始的思想，让线程串行，所谓的悲观（？），缺点就是效率不好
2. 基于 1 的优化思想，让读写操作分离处理，不是让全部线程单纯的等待，而是符合一定安全条件的线程可以继续执行代码，比如 RWLock，对于读读读操作可以让他们并行执行，使得当读写比例中读占绝大多数比重的时候，RWLock 的效率是相当高的。这种优化思想的缺点是：优点就是他的缺点，是一种双刃剑，符合一种条件，那么肯定会违背另一个对立面，导致其性能大大降低
3. 基于 CAS （ Compare And Swap ）和原子性的思想，是非堵塞的，故为乐观锁的一种实现方式。它先检查我们读取的 count 的值是否是最新的，如果是最新的，那么进行更新（这整个过程必须符合原子性）。比如 Atomic 类的 compareAndSet 方法，其本身通过 CAS 指令（硬件指令集）达到了原子性，直接从内存中取出数据比较并赋值。如果不是最新的（存在 contention ），则进行第二步操作，这个第二步操作目前我 get 到的有如下三种：

3.1 升级为重量级的悲观锁，缺点可想而知
3.2 再查一次，直到最新为止（本文的 increase2 就是这个思想），缺点是当竞争激烈的时候，在循环上的开销会很大
3.3 不继续查询，在当前线程内存中记录冲突次数（英文貌似叫 delta ），当读取 count 的时候，返回 count+sum(delta)的值，比如 LongAddr 类。这似乎是三种思路里面最好的方法，不过也有缺点就是读取的时候要做相加的额外操作以及多余的空间开销。

那么其实说了这么多，都是在为下面的结论做铺垫：
"使用哪种锁策略是不能随便纸上谈兵的，必须要根据实际情况，根据实际的竞态条件来决定哪种思想更适合，最好是能模拟出实际环境，随后使用 JMH 来做下 microbenchmark ！并且不要小看 synchronized 的实力，其背后到底使用哪种思想去实现锁不是我们非底层实现人员可以随便猜想的，synchronized 作为 java 实现同步的主力军，有自己的努力，综合上来说，synchronized 的性能是非常稳定的，这肯定得益于其背后的优化算法，正如 mind3x 所说的那样！"

mind3x

2019-06-24 04:10:48 +08:00

@zazalu 说歉意言重了，大家都是参加讨论互相学习，我不是搞高并发的专家，也很业余的。而且我觉得你总结得比我好多了。

另外我举例子的那个网页，之前我没有细看他的代码和结论，需要道歉的是我 XD
其实他本身的方法和结论有很大的问题。像 RWLock，本来就是为多读少写的情况下提高读吞吐量而存在，他的 benchmark 反而显示多读少写的情况下 RWLock 最慢，是因为他统计的是读写线程全部完成以后的最大耗时，而不是读 /写各自的吞吐量。在多读少写的情况下，写线程会因为大量读锁而等待，所以按他的测量方式反而会大幅拖慢总运行时间。