CAS-手写自旋锁

CAS与自旋锁，借鉴CAS思想

什么是自旋锁？

CAS是实现自旋锁的基础，CAS利用CPU指令保证了操作的原子性，以达到锁的效果，至于自旋

锁---字面意思自己旋转。是指尝试获取锁的线程不会立即阻塞，而是采用循环的方式去尝试获取

锁，当线程发现锁被占用时，会不断循环判断锁的状态，直到获取。这样的好处是减少线程上下文

切换的消耗，缺点是循环会消耗CPU。

底层是do...while循环：

扩展1.1：

理解自旋锁

自旋锁（spinlock）：是指当一个线程在获取锁的时候，如果锁已经被其它线程获取，那么该线程

将循环等待，然后不断的判断锁是否能够被成功获取，直到获取到锁才会退出循环。

获取锁的线程一直处于活跃状态，但是并没有执行任何有效的任务，使用这种锁会造成busy-

waiting，也就是线程空转。自旋锁优点是所有线程都是“运行”状态，不需要唤醒线程，速度较快；

不足则是线程的空转导致无谓的资源损耗。针对这类问题也有相关的等待策略进行优化，应对各种

场景，合理利用资源。 

扩展1.2：

所谓自旋锁就是通过while循环实现的，让拿到锁的线程进入临界区执行代码，让没有拿到锁的线

程一直进行while死循环，这其实就是线程自己“旋”在while循环了，因而这种锁就叫做自旋锁。

扩展1.3： 

自旋锁是指尝试获取锁的线程不会立即阻塞，而是采用循环的方式取尝试获取锁

• 这样做的好处是减少线程上下文切换的消耗
• 缺点是循环会消耗CPU。
• 循环比较获取，直到成功为止，没有类似wait的阻塞。

扩展2：

独占锁是一种悲观锁，synchronized就是一种独占锁，它假设最坏的情况，并且只有在确保其它线

程不会造成干扰的情况下执行，会导致其它所有需要锁的线程挂起，等待持有锁的线程释放锁。而

另一个更加有效的锁就是乐观锁。所谓乐观锁就是，每次不加锁而是假设没有冲突而去完成某项操

作，如果因为冲突失败就重试，直到成功为止

这种乐观的锁叫做无锁，与加锁而言对临界区域是无障碍，通过CAS算法（用多个线程尝试使用

CAS同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程

并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试）。CAS操作CPU的指令的操作，

只有一步原子操作，必须要考线程安全的。

---

自己实现一个自旋锁spinLockDemo

题目：实现一个自旋锁，借鉴CAS思想

通过CAS完成自旋锁，A线程先进来调用lock方法自己持有锁5秒钟，B随后进来后发现当前有

线程持有锁，所以只能通过自旋等待，直到A释放锁后B随后抢到。

public class SpinLockDemo {

    AtomicReference<Thread> atomicReference = new AtomicReference<>();

    public void lock() {
        Thread thread = Thread.currentThread();
        System.out.println(Thread.currentThread().getName() + "\t --------come in");
        //准备抢占
        while (!atomicReference.compareAndSet(null, thread)) {
                //空轮询-> 直到atomicReference为null时，执行CAS，并跳出循环
        }
    }

    public void unLock() {
        Thread thread = Thread.currentThread();
        atomicReference.compareAndSet(thread, null);
        System.out.println(Thread.currentThread().getName() + "\t --------task over,unLock.........");
    }

    public static void main(String[] args) {
        SpinLockDemo spinLockDemo = new SpinLockDemo();
        new Thread(() -> {
            spinLockDemo.lock();
            try {
                TimeUnit.SECONDS.sleep(5);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            spinLockDemo.unLock();
        }, "A").start();


        try {
            TimeUnit.MILLISECONDS.sleep(500);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        new Thread(() -> {
            spinLockDemo.lock();
            spinLockDemo.unLock();
        }, "B").start();
    }
}

/**
 * A	 --------come in
 * B	 --------come in
 * A	 --------task over,unLock.........
 * B	 --------task over,unLock.........
 */



//也可以这样new线程
public static void main(String[] args) {
    SpinLockDemo spinLockDemo = new SpinLockDemo();
    Thread t1 = new Thread(() -> {
        spinLockDemo.lock();
        try {
            TimeUnit.SECONDS.sleep(5);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        spinLockDemo.unLock();
    },"A");
    t1.start();


    try {
        TimeUnit.MILLISECONDS.sleep(500);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }

    Thread t2 = new Thread(() -> {
        spinLockDemo.lock();
        spinLockDemo.unLock();
    }, "B");
    t2.start();
}

扩展3：

线程安全之CAS机制详解 

背景介绍：假设现在有一个线程共享的变量c=0，让两个线程分别对c进行c++操作100次，那么我们最后得到的结果是200吗？

1.在线程不安全的方式下:结果可能小于200，比如当前线程A取得c的值为3，然后线程A阻塞了，线程B取得的c的值也是3，然后线程B也阻塞了，现在线程A被唤醒执行了++操作使得c=4，结果写回c值内存，线程A执行结束，线程B被唤醒执行了++操作使得3++=4，也写回了c值内存，现在问题来了，两个线程分别进行了一次++操作，最后c值却为4而不是5，所以c值最后的结果肯定是小于200的，产生这种情况的原因就是线程不安全！，两个线程在同一时间读取了c值，然后又没有各种先执行完++操作而被阻塞（就是没有同步）

2.在线程安全的方式下:比如++操作加上synchronized同步锁，结果一定是200，因为这样使得读取c值和++操作是一个原子性操作，不能被打断，所以线程是安全的，保证了同步

现在问题来了，我们要保证线程安全只有加synchorized同步锁这一种办法吗？synchorized同步锁又有什么缺点呢?

当然不仅只有synchorized这一种方法，还有原子操作类，关于原子操作类我们等下再说，先说说synchorized的缺点：

syschorized缺点：

synchorized的缺点关键在于性能！我们知道synchorized关键字会让没有得到锁资源的线程进入Blocked状态，而在得到锁的资源恢复为Runnable状态，这个过程涉及到操作系统用户模式和内核模式的切换，代价比较高！

现在我们来说说原子操作类，顾名思义，就是保证某个操作的原子性，那它是怎么实现的呢？这个我们就要垃圾原子操作类的底层：CAS机制了

CAS机制的英文缩写是Compare and Swap，翻译一下就是比较和交换

CAS机制中使用3个基本操作数：内存地址V，旧的预期值A，要修改的新值B，更新一个变量的时候，只有当变量的旧的预期值A和内存地址V中的值相同的时候，才会将内存地址V中的值更新为新值B

下面举个栗子：

1）内存地址V中存放着值为10的变量

2）此时线程1要把变量值加1，对线程1来说，旧的预期值A=10，要修改的新值B=11

3）在线程1提交更新之前，另外一个线程2提前一步将内存地址V中的变量值率先更新成了11

4）线程1此时开始提交更新，首先进行A和内存地址V中的值比较，发现A不等于此时内存地址V中的值11，提交失败

5）线程1尝试重新获取内存地址V的当前值，并重新计算想要修改的值，对线程1来说，此时旧的预期值A=11，要修改的新值B=12，这个重新尝试的过程叫做自旋

6）这一次比较幸运，没有其他线程更改内存地址V中的值，线程1进行compare，发现A和内存地址V中的值相同

7）线程1进行Swap，把内存地址V中的值替换为B，也就是12

这个过程涉及到以下几个问题：

问题1：如何保证获取的当前值是内存中的最新值？（如果每次获得的当前值不是内存中的最新值，那么CAS机制将毫无意义）

用volatile关键字修饰变量，使得每次对变量的修改操作完成后一定会先写回内存，保证了每次获取到值都是内存中的最新值！

问题2：如何保证Compare和Swap过程中的原子性（如果Compare和Swap过程不是原子性操作，那么CAS机制也毫无意义）？

Compare和Swap过程的原子性是通过unsafe类来实现的，unsafe类为我们提供了硬件级别的原子操作！

总结一下：从思想上来说，Synchorized属于悲观锁，悲观的认为程序中的并发多，所以严防死守，CAS机制属于乐观锁，乐观的认为程序中并发少，让线程不断的去尝试更新

那么现在又有一个问题来了，CAS机制有什么缺点呢？

CAS机制的缺点：

1.CPU开销过大：在并发量比较高的情况下，如果许多线程反复尝试去更新一个变量，却又一直更新失败，循环往复，会消耗CPU很多资源

2.ABA问题：假设在内存中有一个值为A的变量储存在内存地址V当中，此时有三个线程使用CAS机制更新这个变量的值，每个线程的执行时间都略有偏差，线程1和线程2已经获取当前值，线程3还没有获取当前值。接下来线程1先一步执行成功，把当前值成功从A更新为B，同时线程2因为某种原因被阻塞，没有做更新操作，线程3在线程1更新成功之后获取了当前值B，再之后线程2仍然阻塞，线程3继续执行，成功将当前值更新为A，最后，线程2终于恢复了运行状态，由于线程2之前获取了“当前值A”并且经过了Compare检测，内存地址中的实际值也是A，所以线程2最后把变量A更新成了B，在这个过程中，线程2获取的当前值是一个旧值，尽管和当前值一模一样，但是内存地址中V中的变量已经经历了A->B->A的改变

表面看没有什么影响，但是如果实际中理由CAS机制从取款机上取钱，假如账户开始有100元，在取款机上取走50，取款机出现问题一共提交了两次请求（线程1，线程2），第二次请求（线程2）在执行时因为某种原因被阻塞了，这时候有人往你的账户打了50元，线程2恢复了可执行状态，这个时候就会出现问题，原本线程2应该执行失败的，但是比较后仍然与旧值一致，这样就造成了账户实际上扣款了两次！

ABA问题解决的方案：在Compare阶段不仅比较预期值和此时内存中的值，还比较两个比较变量的版本号是否一致，只有当版本号一致才进行后续操作，这样就完美的解决了ABA问题！

3.不能保证代码块的原子性：CAS机制保证的是一个变量的原子性操作，若要保证多个变量的原子性操作，可以封装在一起，但是这样得不偿失，开销太大，还不如直接采用synchorized同步锁

扩展4：自旋锁Java实现

浅谈自旋锁的Java实现 - 知乎

从零开始自己动手写自旋锁 - 知乎

自旋锁的介绍，手写一个简单的自旋锁

并发开篇——带你从0到1建立并发知识体系的基石

【Java锁】（公平锁、非公平锁、可重入锁、递归锁、自旋锁）谈谈你的理解？手写一个自旋锁 - 简书