1. 锁的类型⚓
1.1 互斥锁与自旋锁⚓
它俩是锁的最基本处理方式,更高级的锁都会选择其中一个来实现。
当已经有一个线程加锁后,其他线程加锁则就会失败,互斥锁和自旋锁对于加锁失败后的处理方式是不一样的:
- 互斥锁加锁失败后,会释放 CPU 给其它线程。
- 自旋锁加锁失败后,会忙等待,直到获取到锁。
对于互斥锁加锁失败而阻塞的现象,是由操作系统内核实现的。当加锁失败时,内核会将线程置为「睡眠」状态,等到锁被释放后,内核会在合适的时机唤醒线程,当这个线程成功获取到锁后,于是就可以继续执行。
所以,互斥锁加锁失败时,会从用户态陷入到内核态,让内核帮我们切换线程。这就增加了 两次线程上下文切换的成本:
- 当线程加锁失败时,内核会把线程的状态从「运行」状态设置为「睡眠」状态,然后把 CPU 切换给其他线程运行;
- 接着,当锁被释放时,之前「睡眠」状态的线程会变为「就绪」状态,然后内核会在合适的时间,把 CPU 切换给该线程运行。
上下切换的耗时大概在几十纳秒到几微秒之间,如果你锁住的代码执行时间比较短,那可能上下文切换的时间都比你锁住的代码执行时间还要长。
所以,如果能确定被锁住的代码执行时间很短,就不应该用互斥锁,而应该选用自旋锁,否则使用互斥锁。
自旋锁是通过 CPU 提供的 CAS 函数(Compare And Swap)
,在「用户态」完成加锁和解锁操作,不会主动产生线程上下文切换。
一般加锁的过程,包含两个步骤:
- 第一步,查看锁的状态,如果锁是空闲的,则执行第二步;
- 第二步,将锁设置为当前线程持有;
CAS 函数就把这两个步骤合并成一条硬件级指令,形成原子指令。
比如,设锁为变量 lock,整数 0 表示锁是空闲状态,整数 pid 表示线程 ID,那么 CAS(lock, 0, pid)
就表示自旋锁的加锁操作,CAS(lock, pid, 0)
则表示解锁操作。
自旋锁是最简单的一种锁,一直自旋,利用 CPU 周期,直到锁可用。需要注意,在单核 CPU 上,需要抢占式的调度器(即不断通过时钟中断一个线程,运行其他线程)。否则,自旋锁在单 CPU 上无法使用,因为一个自旋的线程永远不会放弃 CPU。
1.1.1 CAS【ChatGPT】⚓
CAS(Compare-And-Swap)操作是一种用于实现并发编程中的原子性操作。它通常用于多线程环境下的同步和数据更新,用于保证对共享变量的原子性操作。
CAS操作通常由三个参数组成:一个内存位置(或变量的引用),预期的值和新值。CAS操作的执行过程如下:
- 读取内存位置的当前值。
- 将当前值与预期的值进行比较。
- 如果两个值相等,说明内存位置的值与预期的值匹配,此时将新值写入内存位置。
- 如果两个值不相等,说明内存位置的值已经被其他线程更改,CAS操作失败,不进行写入操作。
CAS操作是一种乐观的并发控制方法,它避免了使用锁机制可能引起的性能开销和死锁等问题。CAS操作可以用于实现线程安全的共享变量的更新和同步。
在编程语言和平台中,CAS操作通常由特定的原子指令或函数提供支持。例如,Java中的java.util.concurrent.atomic包提供了AtomicInteger、AtomicLong等原子类,可以使用其中的compareAndSet()方法实现CAS操作。类似地,C++中的std::atomic模板类和C#中的System.Threading.Interlocked类也提供了CAS操作的支持。
CAS操作在并发编程中广泛应用于无锁算法和数据结构的实现,例如无锁队列、无锁哈希表等。它为多线程环境下的原子操作提供了一种高效且线程安全的解决方案。
1.2 读写锁⚓
读写锁适用于能明确区分读操作和写操作的场景。
工作原理:
- 当「写锁」没有被线程持有时,多个线程能够并发地持有读锁,这大大提高了共享资源的访问效率,因为「读锁」是用于读取共享资源的场景,所以多个线程同时持有读锁也不会破坏共享资源的数据。
- 但是,一旦「写锁」被线程持有后,读线程的获取读锁的操作会被阻塞,而且其他写线程的获取写锁的操作也会被阻塞。
写锁是独占锁,读锁是共享锁。适合读多写少的场景。
1.2.1 读优先锁⚓
当读线程 A 先持有了读锁,写线程 B 在获取写锁的时候,会被阻塞,并且在阻塞过程中,后续来的读线程 C 仍然可以成功获取读锁,最后直到读线程 A 和 C 释放读锁后,写线程 B 才可以成功获取写锁。
1.2.2 写优先锁⚓
当读线程 A 先持有了读锁,写线程 B 在获取写锁的时候,会被阻塞,并且在阻塞过程中,后续来的读线程 C 获取读锁时会失败,于是读线程 C 将被阻塞在获取读锁的操作,这样只要读线程 A 释放读锁后,写线程 B 就可以成功获取写锁。
1.2.3 公平读写锁⚓
公平读写锁比较简单的一种方式是:用队列把获取锁的线程排队,不管是写线程还是读线程都按照先进先出的原则加锁即可,这样读线程仍然可以并发,也不会出现「饥饿」的现象。
1.3 乐观锁与悲观锁⚓
前面提到的互斥锁、自旋锁、读写锁,都是属于悲观锁。
悲观锁
,它认为多线程同时修改共享资源的概率比较高,于是很容易出现冲突,所以访问共享资源前,先要上锁。
乐观锁
,它假定冲突的概率很低,它的工作方式是:先修改完共享资源,再验证这段时间内有没有发生冲突,如果没有其他线程在修改资源,那么操作完成,如果发现有其他线程已经修改过这个资源,就放弃本次操作。乐观锁也叫无锁编程。
乐观锁虽然去除了加锁解锁的操作,但是一旦发生冲突,重试的成本非常高,所以只有在冲突概率非常低,且加锁成本非常高的场景时,才考虑使用乐观锁。