悲观锁、乐观锁、公平锁、非公平锁、独享锁、共享锁、可重入锁、自旋锁、偏向锁、轻量/重量级锁、读写锁、各种锁
面试必备:深入了解Java中乐观锁和悲观锁的秘密 (qq.com)
通俗易懂 悲观锁、乐观锁、可重入锁、自旋锁、偏向锁、轻量/重量级锁、读写锁、各种锁及其Java实现! (qq.com)
Java锁最全详解:乐观锁/悲观锁+公平锁/非公平锁+独享锁/共享锁 (qq.com)
Java中加锁方式有两种,一种是synchronized关键字,另一种是用Lock接口的实现类。
synchronized关键字是自动档,可以满足一切日常驾驶需求。但是如果你想要玩漂移或者各种骚操作,就需要手动档了——各种Lock的实现类。
ReentrantLock、ReadLock、WriteLock 是Lock接口最重要的三个实现类。对应了“可重入锁”、“读锁”和“写锁”。
ReadWriteLock是一个工厂接口,而ReentrantReadWriteLock是ReadWriteLock的实现类,它包含两个静态内部类ReadLock和WriteLock。这两个静态内部类又分别实现了Lock接口。
悲观锁&乐观锁
锁的一种宏观分类方式是悲观锁和乐观锁。悲观锁与乐观锁并不是特指某个锁,而是在并发情况下的两种不同策略。
乐观锁假设多个线程之间很少会发生冲突,因此在读取时不会加锁,而在更新数据时会检查是否有其他线程修改了数据。如果没有冲突就执行更新操作;
悲观锁假设多个线程之间经常会发生冲突,因此在读取数据时会加锁,防止其他线程修改数据,直到操作完成后才释放锁。
乐观锁的实现方式
乐观锁的实现方式常见的有版本号机制和CAS(比较并交换)机制
- 版本号机制:在数据库表中添加一个版本号字段,每次更新操作时都会将版本号+1。当线程要更新数据时,会先读取数据的版本号,然后进行更新操作。在提交更新时,若刚才读取到的version值等于当前数据库中的version值才会更新;否则重试更新操作,直到更新成功。
- CAS:Compare And Swap(比较与交换)。就是用一个预期值和要更新的变量进行比较,两值相等才会更新。CAS是一个原子操作,底层依赖于一条CPU对的原子指令。CAS包含三个操作数:内存地址V,旧的预期值A和新的值B。CAS操作首先读取内存地址V中的值,如果该值等于旧的预期值A,那么将内存地址V中的值更新为新的值B;否则,不进行任何操作。CAS操作失败会重试。
Java中的Atomic类就是基于CAS机制实现的乐观锁,比如AtomicInteger、AtomicLong等(java.util.concurrent.atomic
包里面的原子类都是利用乐观锁实现的。)。
悲观锁的实现方式
就是在读取数据时直接加锁,防止其他线程修改数据。常见的悲观锁实现方式包括:
-
synchronized关键字:synchronized关键字是Java中最基本的锁机制,他可以用来修饰方法或者代码块,保证同一时间只有一个线程可以执行被锁定的代码
-
ReentrantLock类:ReentrantLock是Java中高级的锁机制,他提供了更灵活的锁定方式,可以实现公平锁和非公平锁,支持可重入特性,同时还可以配合条件变量等功能进行更复杂的线程同步操作。
乐观锁与悲观锁的选择
乐观锁适用于并发写比较少的场景,因为乐观锁不会阻塞读操作,适合读多写少的场景。
悲观锁适合并发写比较多的场景,因为悲观锁可以有效地阻塞其他线程的读和写操作,保证数据的一致性。但是,悲观锁有可能会引起线程竞争、降低性能。
乐观锁存在的问题
CAS虽然是高效的原子操作,但是存在三大问题:
ABA问题:CAS在比较和替换时只考虑了值是否相等,而没有考虑到值的版本信息。如果一个值在操作过程中被修改了两次,从A->B->A,那么CAS会认为值没有变化,从而进行操作。
ABA问题的解决思路是在变量前追加上版本号或者时间戳。JDK1.5以后的AtomicStampedReference类就是用来解决ABA问题的,其中的CompareAndSet()方法就是首先检查当前饮用是否等于预期引用,并且当前标志是否等于预期标志,如果全部相等,则以原子方式将该引用和该标志设置为给定的更新值。
自旋时间过长:CAS算法在失败时会一直自旋,等待共享变量可用,如果共享变量一直不可用,就会出现自旋时间过长的问题,浪费CPU资源
如果JVM能支持处理器提供的pause指令,那么效率会有一定的提升。
只能保证单个变量的原子性:CAS只能保证单个变量的原子性
如果需要多个变量的原子操作,就需要使用锁等其他方式进行保护。
从JDK1.5开始提供了AtomicReference类来保证引用对象之间的原子性,你可以把多个变量放在一个对象里来进行CAS操作。
公平锁 VS 非公平锁
就是很公平,在并发环境中,每个线程在获取锁时会先查看此锁维护的等待队列,如果为空,或者当前线程是等待队列的第一个,就占有锁,否则就会加入到等待队列中,以后会按照FIFO的规则从队列中取到自己。
java jdk并发包中的ReentrantLock可以指定构造函数的boolean类型来创建公平锁,比如:公平锁可以使用new ReentrantLock(true)
实现。
非公平锁上来就直接尝试占有锁,如果尝试失败,就再采用类似公平锁那种方式。
非公平锁的优点是可以减少唤起线程的开销,整体的吞吐效率高,因为线程有几率不阻塞直接获得锁,CPU不必唤醒所有线程,缺点是处于等待队列中的线程可能会饿死,或者等很久才会获得锁。
java jdk并发包中的ReentrantLock的构造函数的默认就是采用非公平锁的实现,使用new ReentrantLock(false)
来实现,与上面的公平锁相反的声明方式。
独享锁 VS 共享锁
是指该锁一次只能被一个线程所持有,比如:刚刚谈到的ReentrantLock就是独享锁。
是指该锁可被多个线程所持有,Lock的另一个实现类ReadWriteLock,其读锁就是共享锁,其写锁却是独享锁。
ReadWriteLock的读锁(共享锁)可保证并发读非常高效,但读写,写读 ,写写的过程是互斥的。
这样设计的原因是:就是尽最大的解放并发读的操作,因为读占据了更大的访问请求,我只会在涉及少部分写的操作的时候,才考虑独享锁,从而提升并发的效率。
自旋锁
有一种锁叫自旋锁。所谓自旋,说白了就是一个 while(true)
无限循环。
刚刚的乐观锁就有类似的无限循环操作,那么它是自旋锁吗?
不是。尽管自旋与 while(true) 的操作是一样的,但还是应该将这两个术语分开。“自旋”这两个字,特指自旋锁的自旋。
synchronized锁升级:偏向锁 → 轻量级锁 → 重量级锁
前面提到,synchronized关键字就像是汽车的自动档,现在详细讲这个过程。一脚油门踩下去,synchronized会从无锁升级为偏向锁,再升级为轻量级锁,最后升级为重量级锁,就像自动换挡一样。那么自旋锁在哪里呢?这里的轻量级锁就是一种自旋锁。
初次执行到synchronized代码块的时候,锁对象变成偏向锁(通过CAS修改对象头里的锁标志位),字面意思是“偏向于第一个获得它的线程”的锁。执行完同步代码块后,线程并不会主动释放偏向锁。当第二次到达同步代码块时,线程会判断此时持有锁的线程是否就是自己(持有锁的线程ID也在对象头里),如果是则正常往下执行。由于之前没有释放锁,这里也就不需要重新加锁。如果自始至终使用锁的线程只有一个,很明显偏向锁几乎没有额外开销,性能极高。
一旦有第二个线程加入锁竞争,偏向锁就升级为轻量级锁(自旋锁)。这里要明确一下什么是锁竞争:如果多个线程轮流获取一个锁,但是每次获取锁的时候都很顺利,没有发生阻塞,那么就不存在锁竞争。只有当某线程尝试获取锁的时候,发现该锁已经被占用,只能等待其释放,这才发生了锁竞争。
在轻量级锁状态下继续锁竞争,没有抢到锁的线程将自旋,即不停地循环判断锁是否能够被成功获取。获取锁的操作,其实就是通过CAS修改对象头里的锁标志位。先比较当前锁标志位是否为“释放”,如果是则将其设置为“锁定”,比较并设置是原子性发生的。这就算抢到锁了,然后线程将当前锁的持有者信息修改为自己。
长时间的自旋操作是非常消耗资源的,一个线程持有锁,其他线程就只能在原地空耗CPU,执行不了任何有效的任务,这种现象叫做忙等(busy-waiting)。如果多个线程用一个锁,但是没有发生锁竞争,或者发生了很轻微的锁竞争,那么synchronized就用轻量级锁,允许短时间的忙等现象。这是一种折衷的想法,短时间的忙等,换取线程在用户态和内核态之间切换的开销。
显然,此忙等是有限度的(有个计数器记录自旋次数,默认允许循环10次,可以通过虚拟机参数更改)。如果锁竞争情况严重,某个达到最大自旋次数的线程,会将轻量级锁升级为重量级锁(依然是CAS修改锁标志位,但不修改持有锁的线程ID)。当后续线程尝试获取锁时,发现被占用的锁是重量级锁,则直接将自己挂起(而不是忙等),等待将来被唤醒。在JDK1.6之前,synchronized直接加重量级锁,很明显现在得到了很好的优化。
一个锁只能按照 偏向锁、轻量级锁、重量级锁的顺序逐渐升级(也有叫锁膨胀的),不允许降级。
可重入锁(递归锁)
可重入锁的字面意思是“可以重新进入的锁”,即允许同一个线程多次获取同一把锁。比如一个递归函数里有加锁操作,递归过程中这个锁会阻塞自己吗?如果不会,那么这个锁就是可重入锁(因为这个原因可重入锁也叫做递归锁)。
Java里只要以Reentrant开头命名的锁都是可重入锁,而且JDK提供的所有现成的Lock实现类,包括synchronized关键字锁都是可重入的。
可中断锁
可中断锁,字面意思是“可以响应中断的锁”。
这里的关键是理解什么是中断。Java并没有提供任何直接中断某线程的方法,只提供了中断机制。何谓“中断机制”?线程A向线程B发出“请你停止运行”的请求(线程B也可以自己给自己发送此请求),但线程B并不会立刻停止运行,而是自行选择合适的时机以自己的方式响应中断,也可以直接忽略此中断。也就是说,Java的中断不能直接终止线程,而是需要被中断的线程自己决定怎么处理。
这好比是父母叮嘱在外的子女要注意身体,但子女是否注意身体,怎么注意身体则完全取决于自己。
在Java中,synchronized就是不可中断锁,而Lock的实现类都是可中断锁,可以简单看下Lock接口。
/* Lock接口 */
public interface Lock {
void lock(); // 拿不到锁就一直等,拿到马上返回。
void lockInterruptibly() throws InterruptedException; // 拿不到锁就一直等,如果等待时收到中断请求,则需要处理InterruptedException。
boolean tryLock(); // 无论拿不拿得到锁,都马上返回。拿到返回true,拿不到返回false。
boolean tryLock(long time, TimeUnit unit) throws InterruptedException; // 同上,可以自定义等待的时间。
void unlock();
Condition newCondition();
}
标签:各种,Java,synchronized,CAS,线程,自旋,操作
From: https://blog.51cto.com/u_15872442/7334875