Java 自旋锁（spinlock）相关知识总结

一、前言

谈到『自旋锁』，可能大家会说，这有啥好讲的，不就是等待资源的线程'原地打转'嘛。嗯，字面理解的意思很到位，但能深入具体点吗？自旋锁的设计真就这么简单？

本文或者说本系列的目的，都是让大家不要停留在表面，而是深入分析，做到：

灵活使用 掌握原理 优缺点二、锁的优化：自旋锁

当多个线程想同时访问同一个资源时，就存在资源冲突，这时，大家最直接想到的就是加锁来互斥访问，加锁会有这么几个问题：

等待资源的线程进入睡眠，发生用户态向内核态的切换，有一定的性能开销； 占用资源的线程很快就用完并释放，这时等待的线程被唤醒，又要立即切换回用户态；

那么，如果有一种方式，使得等待的线程先短暂的等待一会儿，有可能有两种结果：

等待的时间超过了这一会儿，那没办法，只好进入睡眠； 等待的时间还未超过，占用资源的线程释放了，这时等待的线程就可以直接占用资源。

这就是锁的小优化：自旋锁！ 自旋锁并不是真正的锁，而是让等待的线程先原地'小转'一下，小转一下，通常小转一下的实现方式很简单：

int SPIN_LOCK_NUM = 64;int i = 0;boolean wait = true;do { wait = // 尝试获取资源锁} while (wait && (++i) < SPIN_LOCK_NUM);

我们通过循环一定的次数来自旋。 color{red}{但是我们也应该知道，不进入休眠而原地打转，是会一直消耗 CPU 资源的，因此，才有了自旋限制！}但是我们也应该知道，不进入休眠而原地打转，是会一直消耗CPU资源的，因此，才有了自旋限制！

看下面的JDK源码：

public final class Unsafe { public final int getAndSetInt(Object var1, long var2, int var4) { int var5; do { var5 = this.getIntVolatile(var1, var2); } while(!this.compareAndSwapInt(var1, var2, var5, var4)); return var5; }}

我们可以看到，CAS就是采用的自旋锁方式，持续的尝试读取最新的 volatile 修饰的变量的值，并尝试去用期望的值去比较，然后更新。

不过这里我们要注意，因为是无限循环，因此我们要保证占用资源的线程很快就能释放，而不是长时间占用（当然，因为这里的源码系统也设定了 int 型变量，因此，占用该变量的线程很快就会使用完而释放）。

三、自旋锁的死锁

啥？怎么会有死锁？ 自旋锁虽然好用，若我们只是停留在上面的分析，那么还是很肤浅的；虽然自旋锁有很大的优势，但同样缺点也不少，除了上面说的，原地打转（忙等待）会一直消耗CPU资源，同时，还会有一个潜在的可能缺陷：死锁。

3.1、系统中断

在聊死锁之前，我们需要先了解一下系统中断事件（大学课本里有这一章节，ASM汇编中也涉及到系统中断向量表）：

中断是指，CPU正常运行期间，由于有内/外部事件，或者由程序预先安排的事件，引起CPU暂停当前工作，转而去处理该事件，当处理完该事件后再返回继续运行被中断（暂停）的程序。通常，操作系统将中断分为两类：外部中断（硬件中断）和内部中断（异常中断，即软件引起的）；

例如：由IO设备引起的中断为硬件中断，比如，键盘输入，硬盘/光驱读写等；异常中断很好理解，比如 NullPointerException 等。

3.2、中断处理程序

系统提供了一个API使得我们的程序能够向系统申请注册一个中断处理程序（例如：程序接收用户的输入事件）。

request_irq(unsigned int irq, irq_handler_t handler, unsigned long flags, const char *name, void *dev)

参数含义如下：

irq: 中断号，系统定义好，具体可查看中断向量表； handler: 中断后发生的ISR（Interrupt Service Routines），直接翻译为：中断服务路由；实际类似，是响应中断服务的程序； flags: 中断标志； name: 中断相关的设备的ASCII，如：'keyboard'，这些名字会在 /proc/irq 和 /proc/interrupts 中使用； dev: 用于共享中断线，传递驱动程序的设备结构。非共享类型的中断，直接设置成为 NULL

中断标志（flags）：

IRQF_DISABLED： 内核处理该ISR期间，禁止其它中断（一般很少使用）； IRQF_SAMPLE_RANDOM： 表明该设备产生的中断对内核熵池有贡献； IRQF_TIMER： 系统定时器； IRQF_SHARED： 多个ISR共享中断线，即一个中断，可存在多个ISR；

调用 request_irq 成功时返回0，常见错误是 -EBUSY，表示给定的中断线已经在使用（没有指定IRQF_SHARED）。

注：

该函数可能引起睡眠，所以不允许在中断上下文或者不允许睡眠的程序中使用！ Linux 中的中断处理程序是无须重入的。当给定的中断处理程序正在执行的时候，其中断线在所有的处理器上都会被屏蔽掉，以防在同一个中断线上又接收到另一个新的中断。通常情况下，除了该中断的其他中断都是打开的，也就是说其他的中断线上的重点都能够被处理，但是当前的中断线总是被禁止的，故，同一个中断处理程序是绝对不会被自己嵌套的。

那这和死锁有何关系呢？额，下一小节会谈到。但这里之所有提到中断，是因为我们还要知道一件事，当系统产生中断，程序被暂停时，程序是不能进入休眠的，此时程序只能采用一种方式：自旋，来保证不会睡眠。

为何不能睡眠？这里就涉及到『中断上下文 context』！

3.3、中断上下文 Context

上面说了，request_irq 可能引起睡眠，所以不允许在中断上下文中使用，也就是说，中断上下文不允许睡眠！

中断上下文：它与进程上下文不一样，中断上下文是内核正在执行ISR。ISR没有自己独立的栈，而是使用内核栈，大小一般是有限制的（32位是8KB大小）。同时，ISR是打断了正常的程序流程，因此必须保证ISR执行速度快。正因为要执行速度快，所以，中断上下文不允许睡眠，且不允许被阻塞！

大家可能会说了，执行速度快不允许睡眠，这解释不合理，我睡眠个1ms不行么？嗯，下面我们就来分析下不能睡眠的真正原因：

1.中断处理时，不会发生进程切换。

因为能打断当前中断的只可能是更高优先级的中断，其它进程的优先级是不会比中断优先级更高的； 如果中断上下文休眠，则没有办法唤醒它，因为所有的 wake_up_xxx 是针对进程而言，而中断没有进程的概念； 只要是中断（硬中or软中，不是香烟），都发生在内核，如果中断上下文睡眠了，内核就阻塞了，系统能阻塞么？不能！阻塞了你就只能重启机器了；

2.schedule 在切换进程时，会保存当前的进程上下文（CPU寄存器的值、状态、堆栈SP内容）以便以后恢复再运行。中断发生后，内核会保存当前被中断进程的上下文。在ISR中，是中断上下文，如果休眠或阻塞，则会调用 schedule，保存的进程上下文不是当前进程的上下文，所以不能在ISR中调用 schedule；3.内核中 schedule 在进入时会判断是否处于中断上下文：

if(unlikely(in_interrupt()))) ..... crash!!!

4.中断 handler 会使用被中断的进程内核堆栈，但不会对其有任何影响，因为 handler用之前会保存，用完后会清除并恢复原貌；5.处理中断上下文中，内核是不可抢占的，如果休眠，则内核....一定会被挂起，同样，你只能重启机器了；所以，被中断的程序也不能睡眠！那么只能使用『自旋锁』来原地打转。

那还是没有说自旋为何会死锁？

自旋锁是不能递归，否则自己等待自己已经获取的锁，将会导致死锁！

一个线程获取了一个自旋锁，在执行这程中被中断处理程序打断，因此该线程只是暂停执行，并未退出，仍持有自旋锁；而中断处理程序尝试获取自旋锁而获取不到，只能自旋；这就造成一个事实：ISR拿不到自旋锁，导致自旋而无法退出，该线程被中断无法恢复执行至退出释放自旋锁，此时就造成了死锁，导致系统崩溃。

四、死锁解决

发生自旋锁死锁，往往因为单CPU这个临界资源发生了抢占，使得一方持有自旋锁被中断暂停，一方不断自旋来尝试获取自旋锁。因此，在多CPU架构下，两方如果分别运行在不同CPU上，是不会发生死锁的。

因此，自旋锁有几个重要特性需要掌握（精髓）：

持有自旋锁的线程（此时肯定在临界区）不能休眠，休眠会引起进程切换，CPU就会被另一个进程占用等无法使用； 持有自旋锁的线程不允许被中断，哪怕是ISR也不行，否则就存在ISR自旋； 持有自旋锁的线程，其内核不能被抢占，否则等同于CPU被抢占；

所以，根据以上总结一点：持有自旋锁的线程，不能因为任何原因而放弃CPU！ 也因此基于上述问题，自旋也需要添加一个上限时间以防死锁。

linux上的自旋锁有三种实现：

在单cpu，不可抢占内核中，自旋锁为空操作。 在单cpu，可抢占内核中，自旋锁实现为“禁止内核抢占”，并不实现“自旋”。(注意) 在多cpu，可抢占内核中，自旋锁实现为“禁止内核抢占” + “自旋”。

以上就是Java 自旋锁（spinlock）相关知识总结的详细内容，更多关于Java 自旋锁（spinlock）的资料请关注好吧啦网其它相关文章！