目录
乐观锁 vs 悲观锁
悲观锁:
乐观锁:
重量级锁 vs 轻量级锁
⾃旋锁(Spin Lock)
公平锁 vs 非公平锁
可重⼊锁 vs 不可重入锁
读写锁
乐观锁 vs 悲观锁
悲观锁:
乐观锁:
同学 B 认为 "⽼师是⽐较闲的, 我来问问题, ⽼师⼤概率是有空解答的". 因此同学 B 直接就来找⽼师.(没加锁, 直接访问资源) 如果⽼师确实⽐较闲, 那么直接问题就解决了. 如果⽼师这会确实很忙, 那么同学 B也不会打扰⽼师, 就下次再来(虽然没加锁, 但是能识别出数据访问冲突). 这个是乐观锁.
这两种思路不能说谁优谁劣, ⽽是看当前的场景是否合适.如果当前⽼师确实⽐较忙, 那么使⽤悲观锁的策略更合适, 使⽤乐观锁会导致 "⽩跑很多趟", 耗费额外的资源.如果当前⽼师确实⽐较闲, 那么使⽤乐观锁的策略更合适, 使⽤悲观锁会让效率⽐较低.
Synchronized 初始使用乐观锁策略. 当发现锁竞争比较频繁的时候, 就会自动切换成悲观锁策略.
就好⽐同学 C 开始认为 "⽼师⽐较闲的", 问问题都会直接去找⽼师.但是直接来找两次⽼师之后, 发现⽼师都挺忙的, 于是下次再来问问题, 就先发个消息问问⽼师忙不忙, 再决定是否来问问题
重量级锁 vs 轻量级锁
- CPU 提供了 "原⼦操作指令".
- 操作系统基于 CPU 的原⼦指令, 实现了 mutex 互斥锁.
- JVM 基于操作系统提供的互斥锁, 实现了 synchronized 和 ReentrantLock 等关键字和类.
注意, synchronized 并不仅仅是对 mutex 进⾏封装, 在 synchronized 内部还做了很多其
他的⼯作
- ⼤量的内核态⽤⼾态切换
- 很容易引发线程的调度
这两个操作, 成本⽐较⾼. ⼀旦涉及到⽤⼾态和内核态的切换, 就意味着 "沧海桑⽥"
轻量级锁: 加锁机制尽可能不使⽤ mutex, ⽽是尽量在⽤⼾态代码完成. 实在搞不定了, 再使⽤ mutex.
- 少量的内核态⽤⼾态切换.
- 不太容易引发线程调度.
理解⽤⼾态 vs 内核态想象去银⾏办业务.在窗⼝外, ⾃⼰做, 这是⽤⼾态. ⽤⼾态的时间成本是⽐较可控的.在窗⼝内, ⼯作⼈员做, 这是内核态. 内核态的时间成本是不太可控的.如果办业务的时候反复和⼯作⼈员沟通, 还需要重新排队, 这时效率是很低的.
synchronized 开始是⼀个轻量级锁. 如果锁冲突⽐较严重, 就会变成重量级锁
自旋锁(Spin Lock)
理解⾃旋锁 vs 挂起等待锁想象⼀下, 去追求⼀个⼥神. 当男⽣向⼥神表⽩后, ⼥神说: 你是个好⼈, 但是我有男朋友了~~挂起等待锁: 陷⼊沉沦不能⾃拔.... 过了很久很久之后, 突然⼥神发来消息, "咱俩要不试试?" (注意, 这个很⻓的时间间隔⾥, ⼥神可能已经换了好⼏个男票了).⾃旋锁: 死⽪赖脸坚韧不拔. 仍然每天持续的和⼥神说早安晚安. ⼀旦⼥神和上⼀任分⼿, 那么就能⽴刻抓住机会上位.
- 优点: 没有放弃 CPU, 不涉及线程阻塞和调度, ⼀旦锁被释放, 就能第⼀时间获取到锁.
- 缺点: 如果锁被其他线程持有的时间⽐较久, 那么就会持续的消耗 CPU 资源. (⽽挂起等待的时候是不消耗 CPU 的)
synchronized 中的轻量级锁策略⼤概率就是通过⾃旋锁的⽅式实现的.
公平锁 vs 非公平锁
假设三个线程 A, B, C. A 先尝试获取锁, 获取成功. 然后 B 再尝试获取锁, 获取失败, 阻塞等待; 然后 C 也尝试获取锁, C 也获取失败, 也阻塞等待.当线程 A 释放锁的时候, 会发⽣啥呢?
这就好⽐⼀群男⽣追同⼀个⼥神. 当⼥神和前任分⼿之后, 先来追⼥神的男⽣上位, 这就是公平锁; 如果是⼥神不按先后顺序挑⼀个⾃⼰看的顺眼的, 就是⾮公平锁.
- 操作系统内部的线程调度就可以视为是随机的. 如果不做任何额外的限制, 锁就是⾮公平锁. 如果要想实现公平锁, 就需要依赖额外的数据结构, 来记录线程们的先后顺序.
- 公平锁和⾮公平锁没有好坏之分, 关键还是看适⽤场景.
synchronized 是⾮公平锁.
可重入锁 vs 不可重入锁
理解 "把⾃⼰锁死"⼀个线程没有释放锁, 然后⼜尝试再次加锁.
// 第⼀次加锁, 加锁成功
lock();
// 第⼆次加锁, 锁已经被占⽤, 阻塞等待.
lock();
按照之前对于锁的设定, 第⼆次加锁的时候, 就会阻塞等待. 直到第⼀次的锁被释放, 才能获取到第⼆个锁. 但是释放第⼀个锁也是由该线程来完成, 结果这个线程已经躺平了, 啥都不想⼲了, 也就⽆法进⾏解锁操作. 这时候就会 死锁.
这样的锁称为 不可重⼊锁.
synchronized 是可重入锁
读写锁
- 两个线程都只是读⼀个数据, 此时并没有线程安全问题. 直接并发的读取即可.
- 两个线程都要写⼀个数据, 有线程安全问题.
- ⼀个线程读另外⼀个线程写, 也有线程安全问题.
- ReentrantReadWriteLock.ReadLock 类表⽰⼀个读锁. 这个对象提供了 lock / unlock ⽅法 进⾏加锁解锁.
- ReentrantReadWriteLock.WriteLock 类表⽰⼀个写锁. 这个对象也提供了 lock / unlock ⽅法进⾏加锁解锁
- 读加锁和读加锁之间, 不互斥.
- 写加锁和写加锁之间, 互斥.
- 读加锁和写加锁之间, 互斥.
注意, 只要是涉及到 "互斥", 就会产⽣线程的挂起等待. ⼀旦线程挂起, 再次被唤醒就不知道隔了多久了.因此尽可能减少 "互斥" 的机会, 就是提⾼效率的重要途径
读写锁特别适合于 "频繁读, 不频繁写" 的场景中. (这样的场景其实也是⾮常⼴泛存在的).
Synchronized 不是读写锁.