这篇文章主要介绍了Java 自旋锁(spinlock)相关知识总结,帮助大家更好的理解和使用Java,感兴趣的朋友可以了解下
一、前言
谈到『自旋锁』,可能大家会说,这有啥好讲的,不就是等待资源的线程"原地打转"嘛。嗯,字面理解的意思很到位,但能深入具体点吗?自旋锁的设计真就这么简单?
本文或者说本系列的目的,都是让大家不要停留在表面,而是深入分析,做到:
二、锁的优化:自旋锁
当多个线程想同时访问同一个资源时,就存在资源冲突,这时,大家最直接想到的就是加锁来互斥访问,加锁会有这么几个问题:
等待资源的线程进入睡眠,发生用户态向内核态的切换,有一定的性能开销;
占用资源的线程很快就用完并释放,这时等待的线程被唤醒,又要立即切换回用户态;
那么,如果有一种方式,使得等待的线程先短暂的等待一会儿,有可能有两种结果:
等待的时间超过了这一会儿,那没办法,只好进入睡眠;
等待的时间还未超过,占用资源的线程释放了,这时等待的线程就可以直接占用资源。
这就是锁的小优化:自旋锁! 自旋锁并不是真正的锁,而是让等待的线程先原地"小转"一下,小转一下,通常小转一下的实现方式很简单: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)的资料请关注CodeAE代码之家 其它相关文章!
原文链接:https://juejin.cn/post/6930427187237486605