一、前言
谈到『自旋锁』，可能大家会说，这有啥好讲的，不就是等待资源的线程"原地打转"嘛。嗯，字面理解的意思很到位，但能深入具体点吗？自旋锁的设计真就这么简单？
本文或者说本系列的目的，都是让大家不要停留在表面，而是深入分析，做到：
- 灵活使用
- 掌握原理
- 优缺点
二、锁的优化：自旋锁
当多个线程想同时访问同一个资源时，就存在资源冲突，这时，大家最直接想到的就是加锁来互斥访问，加锁会有这么几个问题：
- 等待资源的线程进入睡眠，发生用户态向内核态的切换，有一定的性能开销；
- 占用资源的线程很快就用完并释放，这时等待的线程被唤醒，又要立即切换回用户态；
那么，如果有一种方式，使得等待的线程先短暂的等待一会儿，有可能有两种结果：
- 等待的时间超过了这一会儿，那没办法，只好进入睡眠；
- 等待的时间还未超过，占用资源的线程释放了，这时等待的线程就可以直接占用资源。
这就是锁的小优化：自旋锁！ 自旋锁并不是真正的锁，而是让等待的线程先原地"小转"一下，小转一下，通常小转一下的实现方式很简单：
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）的资料请关注脚本之家其它相关文章！