Linux)到硬件(硬件架构)分析互斥操作的本质

先上结论：

一切互斥操作的依赖是自旋锁（spin_lock），互斥量（semaphore）等其他需要队列的实现均需要自选锁保证临界区互斥访问。

而自旋锁需要xcmpchg等类似的可提供CAS操作的硬件指令提供原子性和可见性，（xcmpchg会锁总线或缓存行，一切会锁总线或缓存行的操作都会刷StoreBuffer，起到写屏障的操作）

所以，任意的互斥操作，无论是 java 层面，hotspot层面，linux层面的根本依赖都是 xcmpchg 等硬件指令。java算是上层，需要依赖hotspot和linux嵌入的汇编完成xcmpchg的调用。

所有同步手段的根本是硬件，软件是辅助手段，软件和硬件的交界面是用于并发控制的硬件指令（如 cmpchg, 带lock前缀的指令，lwsync, sfence 等）

整个依赖链条：

1. Java 的并发工具包 JUC 中大部分同步工具类依赖 AQS 为他们提供队列服务和资源控制服务。

2. AQS 依赖 LockSupport 的 park 和 unpark 为他提供线程休眠唤醒操作

3. LockSupport 的 park 和 unpark 是依赖 JVM（此处语境讨论 Hotspot）调用操作系统的 pthread_mutex_lock 和 pthread_cond_wait ，前者是保护后者和 counter 变量的互斥锁，保证只有一个线程操作 counter 变量和 condtion 上的等待队列

4. pthread_mutex_wait 依赖于操作系统的 futex 机制，多个用户态的线程（Java线程，即Mutator）通过用户空间相同，物理页共享，共同争抢受写屏障增强，线程可见性强的资源变量。如果抢不到，需要用 futex_wait 系统调用，具体是委托内核查看该变量是否还是 futex_wait 的入参（争抢失败后的值），如果是，则让内核将自己从 runqueue（Linux下的就绪进程队列）摘下来，并且状态设为 TASK_INTERRUABLE，表示不需要继续执行，但是可以用信号唤醒，如果不是，返回用户空间，再次争抢

5. futex_wait 和 futex_wakeup 依赖 spin_lock保护桶bucket，其实保护bucket上的一整条链表

6. 操作系统的 down , up 依赖 spin_lock 保护等待队列和资源变量

硬件层

预备知识：

写屏障：

简化微机架构（Intel X86）：

无写屏障：

　　1.假设有变量var

　　2. CPU A(进程/线程A) 修改 var = 1

　　3. CPU C(进程/线程C) 读取到 var = 3，无法立刻得到 A 的修改

有写屏障（A,B,C任意CPU在修改完某个变量后均使用写屏障）：

　　上面的微机架构可以简化成：

　　1.A修改var

　　2.C立刻可见

使用写屏障类似：

　　var = 1;

　　write_fence_here(); // 写屏障

作用只是将 storeBuffer中的内容马上刷出到自己的高速缓存中，因为高速缓存有MESI缓存一致性协议，所以其他CPU读取该变量，将是一直的新值（即使穿透缓存直接读取内存也是一样一致）

读屏障本文不讨论，其本身作用是将 Invalidate Queue 中的无效化请求应用到自己独享的缓存中，以便不去读之前的旧数据。而是因为缓存行已经 Invalidated，而去从其他CPU或内存读取最新数据。

操作系统层

自旋锁和队列锁（一般互斥量是队列锁）：

1.自旋锁简化：

　　　　while (true) {
            if (compareAndSet(期望的旧值, 新值)) {
                return;
            }
        }

自旋锁在Linux中写作 spin_lock ，spin 本身有“连轴转”的意思。自旋锁的本质是获取不到资源就一直空转。

compareAndSet : 类似下面代码，但是被包装成一条硬件指令，所以是原子的，在他执行的中间，不能有别的CPU插手这个内存的操作。

并且CAS要么全部完成，要么不执行，不能只执行一半，因为他是一条锁了总线或缓存行的硬件指令。在SMP条件下，如果不锁总线或缓存行，指令也不是原子的，比如ADD（read-write-read），只有微操作是原子的。

比如将某个值打入某个寄存器中(write)。

    boolean compareAndSet (期望的旧值, 新值) {
        if (变量值 == 期望的旧值) {
             变量 = 新值；
             return true;
        }
        return false;
    }

2. 队列锁简化：

addToQueue：将线程/进程的TCB/PCB(在linux是task_struct)，放入等待队列，当持有资源的线程释放资源的时候会唤醒等待队列中线程（PCB/TCP就是代表进程/线程的结构）。

　　　　　　并且将进程/线程的状态设为非运行状态（linux中一般使用TASK_INTERRUPTABLE）, 并从就绪队列上摘下来（Linux上是runqueue）

schedule ：当前线程已设置为非运行状态，所以会选择其他线程占用CPU，当前线程在此点睡眠

 　　while (true) {
        if (!compareAndSet(期望旧值,新值)) { // 尝试获取资源，如：compareAndSet(原资源数，原资源数 - 1)
            addToQueue(当前线程PCB/TCB); // 获取不到就进入等待队列
            schedule();// 睡眠，让出CPU
        }
    }

为什么说互斥量（队列锁）依赖自旋锁？

假设有以下情况：（互斥量对应资源初始值=1）

　如此一来，明明有资源，但是线程B却无法被唤醒。

究其原因，是因为B的检测资源-挂入等待队列-睡眠这三个阶段，不是原子的。线程A 可以修改资源，让资源变成1。

　线程A对资源的操作插入到了线程B的操作之中，使得B的操作集合中语句前后所处的状态不一致，即非原子的，受干扰的（区别于事物原子性）。

可以使用自旋锁保护资源，在读取资源时，其他线程不能修改资源，那么释放操作就会被放到睡眠之后：

　　为何可以使用自旋锁？因为自旋锁不涉及队列，如果线程无法获取自旋锁，就在CPU 上空转，直到获取为止，不需要队列去存储他们，所以不会出现多个线程修改一个队列的情况。

也不会睡眠，所以也不会出现因为睡眠而错过资源的情况，像上二张图就是错过资源的情况，自选锁一直都在争抢。

　　但是自旋锁的局限性也很大，空转，无意义的CPU时间被浪费。所以只有竞争不是很激烈，以及占用锁时间不长的情况，才使用自旋锁。

　　这里的对队列操作，只是简单地读取一下变量，和在链表上挂一个节点，很快。

　　在Linux（3.0.7）下的实现：

　　up 操作是释放互斥量资源，down 操作是获取互斥量资源

futex（fast user mutex）：之所以称为 user mutex，是因为多个用户态线程通过一块共享内存存储代表资源的变量，多个用户态线程对这个资源的操作是原子性的，这是在用户态的操作。

当用户线程发现自己争抢不到资源，才委托系统调用帮自己检查一下这个变量还是不是刚才读到的变量，如果是就当前线程休眠，所以是在用户态判断是否可以获取资源，不行再使用系统调用陷入内核态。比如说，我有一块内存页，被A,B两个线程共享，这个内存页里有个变量 var ，表示资源的个数，一开始是1。线程A和B都是通过CAS型的硬件指令去设置这个资源，即操作是原子性的。假如一开始A，CAS 抢夺成功，资源var 变成 0。资源B 直接通过自己的页面映射表去到这个共享的物理页，读取一下，发现是0，那么当前表示无资源可用。B将会使用系统调用，委托操作系统检查，这个资源是不是还是0，如果是就将自己休眠，否则B退出内核态回到用户态。为什么要委托操作系统再检查一次呢？因为有可能A已经释放资源了，B只要再CAS一次就能获得资源。

futex 机制的实现比较简单，基于散列表：

每一个futex_key代表一个共享变量，即资源。

每一个节点包裹着 futex_key

每一个futex_bucket代表一个hash桶，也就是hash表中的某个位置

一个 futex_bucket 的链表中，有不同节点，说明有不同资源。比如说，“萤石” 是一种资源，“红石”也是一种资源，他们的数量所代表的变量（地址）的节点会存在于下图的同一个链表上

每个bucket都有一个锁可以被自旋锁锁定，锁的单位是一个 bucket上的链表，所以当一种资源需要加锁，会锁到链表上的其他资源。

设计者这么做其实并不过分，因为一个桶中的链表长度并不是很长，而且spin_lock是短时间锁，将锁粒度控制在整个散列表一个锁和每个节点一个锁之间，是对空间和时间的权衡。

futex在线程处于内核态，读取资源之前，会用 spin_lock 锁住 bucket，读取资源后发现没有资源会把自己挂入等待队列，然后释放spin_lock 。

持有资源的线程在唤醒等待队列中线程之前，同样要用 spin_lock 锁住同样位置的 bucket。

下图是 futex 的互斥机制，可能会有疑问：获取资源不用算进去吗？

这和程序顺序有关，释放资源肯定在唤醒之前的，这是必须遵循的，因为释放完资源才会去唤醒进程去争夺

那么唤醒等待队列这个操作可能在被自旋锁保护区域的上面或者下面。

如果在上面，那么资源在唤醒之前就释放了，保护区里肯定可以得到资源，免于睡眠。

如果在下面，那么无论资源在唤醒之前的哪个位置，就算是在保护区里也好，只要是释放了就行。因为唤醒操作在保护区之后，而保护区里，要休眠进程已经挂到等待队列。

所以唤醒操作必能唤醒要休眠进程，因为他在入队操作之后，他能找到那些休眠的进程，从而唤醒他们。

再向上一层看， pthread_mutex_wait 和 pthread_cond_wait，这两个函数是 Hotspot 实现 park 函数依赖的操作系统层面接口。而park函数是 LockSupport.park 方法的本地方法实现。

其中 pthread_cond_wait 是把 Java线程（java应用线程，即Mutator）放入到一个等待队列，这个队列称为条件队列。对应LockSupport.park 方法。

还有一个与之对应的解锁方法，pthread_cond_signal ，是唤醒这个队列上的线程。那么怎么保证对这个等待队列的操作是互斥的呢？如果不互斥，就可能发生下面这钟典型的写覆盖并发问题：

依赖的是 pthread_mutex_lock, 要操作队列之前先获取互斥量，操作完释放互斥量

pthread_mutex_lock(&mutex);
pthread_cond_wait(&queue);
pthread_mutex_unlock(&mutex);

pthread_mutex_lock 依赖的是上面所说的，futex, 所以 pthread_mutex_lock 就是上面说的，先在用户态读取资源，如果没资源了，就调用 SYS futex 系统调用

jvm（hotspot）层

到这里，操作系统和java层面差不多要连起来了，我们再通过LockSupport向上走。

在调用LockSupport.unpark 之后调用LockSupport.park 的话，线程不会休眠。这个点很重要，没有这个点，JUC中的AQS无法正常工作。

伪代码：xchg相比xcmpchg不会比较，而是直接原子设置相应内存单元的值。

park () {
        // 之前有资源，直接返回，并且把资源消耗掉
        if (xchg(&counter ,1, 0) == 1) {
            return;
        }
        // 准备操作 票据和队列
        pthread_mutex_lock();
        // 可能之前 获取 mutex 的线程给予了 资源
        // 必须要有这一句，否则可能错过释放了的资源，永远无法被唤醒
        if (counter == 1) {
            counter = 0;
            pthread_mutex_unlock();
            return;
        }
        pthread_cond_wait();
        // 这句为什么在 pthread_cond_wait 之后呢？
        // 因为这里是线程被唤醒之后的地方，其他线程给了一个资源，当前线程才被唤醒
        // 既然被唤醒了，就要去消耗这个资源，这样一唤醒(资源+1)，一睡眠(资源-1)。
        // 扯平之后就是当前线程的 继续运行状态
        counter = 0;
        pthread_mutex_unlock();
    }

    unpark () {
        pthread_mutex_lock();
        counter = 1;
        writeBarrierHere();
        pthread_cond_signal();
        pthread_mutex_unlock();
    }