Java 锁策略、CAS、synchronized原理

Naion

已于 2022-11-10 09:03:33 修改

阅读量244

点赞数

分类专栏： JavaSE 多线程文章标签： java

于 2022-08-04 23:22:02 首次发布

本文链接：https://blog.csdn.net/Naion/article/details/126141780

版权

JavaSE 多线程专栏收录该内容

7 篇文章 0 订阅

订阅专栏

锁策略

乐观锁和悲观锁

乐观锁：假设接下来发生冲突的可能性很小，每一次数据在更新的时候，才会正式对数据是不是发生冲突检测。如果发生冲突了，返回错误信息让用户决定。

简单认为，加锁没有那么容易出现锁冲突。

悲观锁：假设接下来发生冲突的可能性很大，每一次的数据操作都要加锁，其他线程要拿到这个数据只能阻塞。

简单认为，只要加锁，就会出现锁冲突。

比如说，疫情时期，出现阳性的时候。我认为接下来封城的可能性很小，没必要做什么，要发生的事概率很小，这就是一个乐观锁；而有的人认为封城的可能性很大，赶紧去屯点吃的在家里。要发生的事的概率很大，就是一个悲观锁。

synchronized刚开始使用乐观锁，到后面发现锁的竞争比较频繁的时候，就会自动切换成悲观锁。synchronized锁是一个自适应锁。

读写锁和普通互斥锁

多线程之间，读数据的时候不会产生线程安全，但是写数据的时候会产生线程安全。如果这个时候只使用普通的锁（有互斥的功能），会产生大量的性能损耗。

读写锁在读的时候和写的时候执行不同的锁策略。对于同一个数据，

（1）线程a尝试加写锁，线程b尝试加写锁，ab产生了锁竞争。这个时候和普通的锁没有区别；

（2）线程a尝试加读锁，线程b尝试加读锁，ab不竞争，相当于每一次加锁，不涉及数据的修改，是线程安全的。这是多线程中的普遍情况；

（3）线程a尝试加读锁，线程b尝试加写锁，ab竞争，和普通锁没有区别。

读写锁把读操作和写操作区分开来对待，其中，读和写、写和写之间发生互斥。比较适合频繁读，不频繁写的场景。

synchronized不是读写锁。

重量级锁和轻量级锁

锁是基于内核的功能实现的。CPU提供了原子操作指令后，操作系统根据CPU原子指令，实现mutex互斥锁。JVM基于操作系统提供的互斥锁，实现了synchronized 和 ReentrantLock 等关键字和类。

重量级锁：要做更多的事，开销很大。加锁机制严重依赖操作系统提供的mutex，涉及到大量的内核态用户态切换，很容易引发线程的调度。涉及到用户态和内核态的切换，意味着开销比较大，很容易产生阻塞。

轻量级锁：要做的事很少，开销很小。加锁机制尽量不使用mutex，而是尽量在用户态代码完成。实在不行了，再使用mutex。涉及到少量的内核态用户切换，尽量避免了阻塞。

synchronized 开始是一个轻量级锁. 如果锁冲突比较严重, 就会变成重量级锁。

与乐观锁悲观锁的含义有一定的重叠。悲观锁一般都是重量级锁，而乐观锁一般都是轻量级锁。

挂起等待锁和自旋锁

挂起等待锁往往是通过内核来实现，而自旋锁往往是通过用户态的代码实现。线程在抢锁失败后进入阻塞状态，过不了多长时间，锁就会被释放。这个时候，可以使用自旋锁来处理这样的问题。自旋锁是典型的轻量级锁的实现方式。

自旋锁的特点：

（1）没有放弃CPU，不涉及线程的阻塞和调度。能够第一时间获取锁；

（2）如果锁被其他线程的持有时间比较长，就会持续消耗CPU资源。挂起等待锁不消耗资源。

synchronized中的轻量级锁策略大概率通过自旋锁的方式实现。

公平锁和非公平锁

公平锁：线程遵守先来后到的原则；

非公平锁：线程不遵守先来后到的原则；

假设有三个线程A、B、C。顺序是ABC。A先获取锁，其他的线程阻塞。当A释放锁的时候，如果是公平锁，那么接下来就是B获取，B释放后就是C获取。如果是非公平锁，那么B和C抢占，都有可能先获取锁。

操作系统内部的线程调度是随机的，如果不做任何额外的限制，锁就是非公平的锁。

synchronized 是非公平锁。

可重入锁和不可重入锁

可重入锁：可以重新进入的锁。允许同一个线程多次获取同一把锁。可重入锁会在内部记录这个锁是哪一个线程获取到的，如果当前的锁和加的锁是同一个锁，就不用挂起等待。

不可重入锁：对于同一个线程，第一次加锁，加锁成功。第二次加锁，就会重新阻塞，等待第一次的锁被释放，才能获取到第二个锁。但是释放第一个锁由该线程完成。

synchronized 是可重入锁。

CAS

CAS是操作系统/硬件，给JVM提供的另一种更加轻量级的原子操作的机制。字面意思是“比较并交换”。是CPU提供的特殊指令：compare and swap，虽然是涉及到多个操作，但是编译器认为是一条指令（原子性）。一个CAS涉及到一下的操作：假设内存中源数据是V，旧的预期值是A，需要修改的值是B。

（1）比较A和V是不是相等（比较）；

（2）如果比较相等，把B写入V（交换）；

（3）返回操作是否成功。

当多个线程对某一个资源进行CAS操作，只有一个线程能够成功，但是不会阻塞其他线程，其他线程会收到操作失败的信号。CAS可以看成一种乐观锁。

实现

（1）java 的 CAS 利用的的是 unsafe 这个类提供的 CAS 操作；

（2）unsafe 的 CAS 依赖了的是 jvm 针对不同的操作系统实现的 Atomic::cmpxchg；

（3）Atomic::cmpxchg 的实现使用了汇编的 CAS 操作，并使用 cpu 硬件提供的 lock 机制保证其原子性。

简而言之，是因为硬件予以了支持，软件层面才能做到。

应用场景

使用AtomicInteger实现i++操作。

//直接++，涉及原子性
public class demo {

    private static int SUM = 0;

    public static void main(String[] args) throws InterruptedException {
        Thread thread1 = new Thread(() -> {
            for (int i = 0; i < 5000; i++) {
                ++SUM;
            }
        });

        Thread thread2 = new Thread(() -> {
            for (int i = 0; i < 5000; i++) {
                ++SUM;
            }
        });

        thread1.start();
        thread2.start();

        thread1.join();
        thread2.join();
        System.out.println(SUM);
    }
}

//保证原子性
public class demo {

    private static AtomicInteger atomicInteger = new AtomicInteger(0);

    public static void main(String[] args) throws InterruptedException {
        Thread thread1 = new Thread(() -> {
            for (int i = 0; i < 5000; i++) {
                atomicInteger.getAndIncrement();
            }
        });

        Thread thread2 = new Thread(() -> {
            for (int i = 0; i < 5000; i++) {
                atomicInteger.getAndIncrement();
            }
        });

        thread1.start();
        thread2.start();

        thread1.join();
        thread2.join();
        System.out.println(atomicInteger);
    }
}

还可以实现自旋锁。基于CAS实现更加灵活的锁，获取更多的控制权。

//伪代码
public class SpinLock {
    private Thread owner = null;
    public void lock(){
        // 通过 CAS 看当前锁是否被某个线程持有. 
        // 如果这个锁已经被别的线程持有, 那么就自旋等待. 
        // 如果这个锁没有被别的线程持有, 那么就把 owner 设为当前尝试加锁的线程. 
        while(!CAS(this.owner, null, Thread.currentThread())){
       }
   }
    public void unlock (){
        this.owner = null;
   }
}