含义:所谓锁的策略就是一把锁的具体实现方式。Java、MySQL、Go、C++等等都有类似的锁策略。
一、乐观锁&悲观锁
1.1 定义
乐观锁:每次读写数据都认为不会发生冲突,线程不会阻塞,一般来说,只有在进行数据更新时才会检查是否发生冲突,若没有冲突,直接更新,只有冲突(多个线程都在更新数据)了才解决冲突问题。
当线程冲突不严重的时候,可以采用乐观锁策略来避免多次的加锁解锁操作。
悲观锁:每次去读写数据都会冲突,每次在进行数据读写时都会上锁(互斥),保证同一时间段只有一个线程在读写数据。
当线程冲突严重时,就需要加锁,来避免线程频繁访问共享数据失效带来的CPU空转问题。
1.2 举例
乐观锁策略
你认为每次找我的时候,我都闲着呢,直接就找我发消息要请我吃火锅(不上锁,直接访问数据),若我确实闲着呢(直接响应,避免了加锁和解锁的操作),如果我此时忙着呢,我就一直不回复,你一看我没及时回复你,你就跑去干别的事情了(线程不会阻塞,去干别的事情),过段时间再来。
乐观锁不是真的把线程阻塞了。乐观锁的实现一般都会采用版本号机制来实现~
悲观锁策略
每次你(线程)跑来找我(线程或者资源)都认为我忙着呢,先给我发个消息 “嗨嗨嗨,VIBE在吗?”(尝试加锁),我没回或者回了个”忙着呢“,你就得等待(线程阻塞),一直等到我回复你”我好了“ (CPU唤醒了等待线程,尝试重新加锁),此时你被唤醒,对我加锁,我们就可以愉快聊天了~
1.3 版本号机制
乐观锁的一个重要功能就是要检测出数据是否发生访问冲突,我们可以引入一个”版本号“来解决。
-
一般锁的实现都是乐观锁和悲观锁并用的策略。
-
synchronized最开始就是乐观锁,当竞争激烈再升级为悲观锁。
下图详细讲解版本号机制:
(1) 线程1和2从主内存读取到数据到自己的工作内存中,此时版本号都是 ”1“。
(2)线程1把自己的V值改成30,线程2把自己的V值改成70
(3)假如线程1先完成修改,将数据版本号+1(version = 2),然后一起写回主内存
(4)此时线程2想更新自己的工作内存值到主内存,发现不满足”提交版本必须大于记录当前版本才能执行更新“的乐观锁策略,就认为这次写回失败。
(5) 线程2写入失败,就从主存中读取最新的值和版本号到自己工作内存中,然后尝试在最新的数据上进行操作,若最后写回成功,主存和工作内存的值+1,否则执行CAS策略,不断重试写回,直到成功为止。
二、读写锁
2.1 介绍
多线程之间,数据的读取方之间不会产生线程安全问题,但数据的写入方互相之间以及和读者之间都需要进行互斥。如果两种场景下都用同一个锁,就会产生极大的性能损耗。所以读写锁因此而产生。
读写锁特别适用于线程基本都在读数据,很少有写数据的情况。
多线程访问数据时,并发读取数据不会有线程安全问题,只有在更新数据(增删改)时会有线程安全问题,将锁分为读锁和写锁。
-
多个线程并发访问读锁(读数据),则多个线程都能访问到数据,读锁和读锁是并发的,不互斥
-
两个线程都需要访问写锁(写数据),则这两个线程互斥,只有一个线程能成功获取到写锁,其他线程阻塞
-
当一个线程读,另一个线程写(也互斥,只有当写线程结束时,读线程才能继续执行)
注意:只要是涉及到 “互斥”, 就会产生线程的挂起等待. 一旦线程挂起, 再次被唤醒就不知道隔了多久了.
因此尽可能减少 “互斥” 的机会, 就是提高效率的重要途径
2.2 Java中的读写锁
读写锁就是把读操作和写操作区分对待.
Java 标准库提供了 ReentrantReadWriteLock 类, 实现了读写锁. ●ReentrantReadWriteLock.ReadLock 类表示一个读锁. 这个对象提供了 lock / unlock 方法进行 加锁解锁;
●ReentrantReadWriteLock.WriteLock 类表示一个写锁. 这个对象也提供了 lock / unlock 方法进行加锁解锁;
其中, 读加锁和读加锁之间, 不互斥. 写加锁和写加锁之间, 互斥. 读加锁和写加锁之间, 互斥
三、重量级锁&轻量级锁
3.1 定义
重量级锁:需要操作系统和硬件支持,线程获取重量级锁失败进入阻塞状态(os,用户态切换到内核态,开销非常大)
轻量级锁:尽量在用户态执行操作,线程不阻塞,不会进行状态切换。
3.2 举例
假如此时要去银行办理业务,窗口外部自己处理的业务就属于用户态,窗口内部需要工作人员协助的就处于内核态
重量级锁:若某个业务涉及到赚钱打款,就要频繁切换用户态和内核态,非常耗时。
轻量级锁:此时可以把这些操作业务都放在用户态解决
注意:synchronized开始是一个轻量级锁,如果锁冲突比较严重,就会变成重量级锁~
四、自旋锁(Spin Lock)
按之前的方式,线程在抢锁失败后进入阻塞状态,放弃 CPU,需要过很久才能再次被调度. 但实际上, 大部分情况下,虽然当前抢锁失败,但过不了很久,锁就会被释放。没必要就放弃 CPU. 这个 时候就可以使用自旋锁来处理这样的问题。
轻量级锁的常用实现就是自旋锁
自旋锁就是循环,以下是伪代码:
while (抢锁(lock) == 失败) {//循环}
如果获取锁失败, 立即再尝试获取锁, 无限循环, 直到获取到锁为止. 第一次获取锁失败, 第二次的尝试会在极短的时间内到来. 一旦锁被其他线程释放, 就能第一时间获取到锁。
比如等红绿灯:
-
如果每次等都熄火,当绿灯再打火启动,这就是挂起等待锁
-
如果每次发动机不熄火,踩着刹车,等绿灯亮了可以直接走,这就是自旋锁
注意:synchronized开始是一个轻量级锁,如果锁冲突比较严重,就会变成重量级锁,而synchronized中的轻量级锁策略往往是通过自旋锁的方式实现的。
五、公平锁&非公平锁
公平锁:遵守 "先来后到",B 比 C 先来的. 当 A 释放锁的之后, B 就能先于 C 获取到锁.
非公平锁:不遵守 "先来后到",B 和 C 都有可能获取到锁.
-
synchronized锁就是非公平锁
-
ReentrantLock默认是非公平锁,可以在构造方法中传入true开启公平锁
六、可重入锁(不死锁)&不可重入锁(死锁)
可重入锁:可以从字面意思理解就是 “可以重新进入的锁” ,也叫递归锁,即允许同一个线程多次获取同一把锁。java中以Reentrant开头命名的锁、JDK提供的所有Lock实现类——都是可重入锁,而Linux系统提供的mutex是不可重入锁。
实现方式:在锁中记录该线程持有者的线程身份以及一个计数器(记录加锁次数),若果发现当前加锁的线程就是持有锁的线程,则直接计数自增。
不可重入锁:从字面意思理解就是 “不可以重复进入的锁” ,不允许同一个线程连续多次获取同一把锁。当第一次线程A锁未释放,第二次线程A又要重新加锁的时候就要阻塞等待,显然此时线程A既不能获取到锁还必须一直阻塞等待,这就是所谓的 ”死锁”现象。
实现方式:在锁中记录该线程持有者的线程身份以及一个计数器(记录加锁次数),若果发现当前加锁的线程就是持有锁的线程,且计数器的次数为2时,立刻停止,这就出现了死锁。
如何解决"死锁"现象?
加锁的时候判定一下,看当前尝试申请锁的线程是不是已经就是锁的持有者了,如果是,直接解锁放行~
注意:synchronized是可重入锁。
七、死锁
1. 死锁的四个必要条件(同时满足)
①互斥作用——一个线程拿到一把锁之后,另一个线程不能使用。(锁的基本特点,原子性,为锁特征)
②不可抢占——一个线程拿到锁,只能自己主动释放,不能被其他线程强行占有。(不可挖墙脚,为锁特征)
③请求和保持——当一个线程占据多把锁后,除非显式释放锁,否则锁一直被该线程锁占用(碗里的锅里的都得到,为代码特征)
④循环等待——多个线程等待关系闭环了(房间钥匙锁车里了,车钥匙锁房间里,为代码特征)
2. 死锁的三种典型情况
①一个线程,一把锁,这把锁是可重入锁不影响,是不可重入锁会死锁。
②两个线程两把锁,即使是可重入锁,也会出现死锁。
③N个线程,M把锁,直接是死锁——”类比于哲学家就餐“。
3.如何避免死锁?
破坏循环等待——针对锁进行编号,如果需要同时获取到多把锁,约定加锁顺序(务必是先对小的编号加锁,后对大的编号加锁)
synchronized(locker1){
synchronized(locker2){
//........代码
}
}
//先对1号加锁,再对2号加锁,先释放1号的锁,2号的锁才能释放。