一. 常见的锁策略
1. 乐观锁和悲观锁
乐观锁和悲观锁主要是看主要是锁竞争的激烈程度.
乐观锁预测锁竞争不是很激烈, 做的准备工作相对更少, 开销更小, 效率更高.
悲观锁预测锁竞争会很激烈, 做的准备工作相对更多, 开销更大, 效率更低.
🍂举个例子:
比如在疫情期间, 我们谁也不知道下一步疫情的情况, 疫情一旦严重, 吃饭都成问题, 可能会买不到菜！
悲观锁, 就是在认为当前时刻可能就会出现这样的情况, 就需要提前准备, 所以去超市菜场大量的屯粮屯药, 以备不时之需;
乐观锁, 就是认为在国家的管控下, 疫情正常的衣食不会有太大的影响, 就不去屯货了.
🍂应用场景:
乐观锁一般应用在线程的冲突比较少, 也就是说读操作比较多, 写操作比较少; 而悲观锁则相反, 一般应用在线程冲突比较多, 写操作比较多的情况下.
2. 轻量级锁和重量级锁
轻量级锁和重量级锁看的是锁操作的开销大不大.
重量级锁: 加锁解锁的开销比较的大, 需要在内核态中进行完成, 多数情况下悲观锁是一个重量级锁, 但并不绝对.
轻量级锁: 它的开销比较小, 在用户态中完成就行, 多数情况下乐观锁是一个轻量级锁, 但并不绝对.
轻量级锁一般都是通过版本号机制或CAS算法进行实现的, 但对用重量级锁来说不是, 这与操作系统的内核有关, cpu一般会提供一些特殊指令, 操作系统会对这些指令进行封装一层, 提供一个mutex(互斥量), 在Linux种就会提供一个这样的接口供用户进行加锁解锁; 一般来说, 如果锁是通过调用mutex来进行实现的, 那么这个锁就是一个重量级锁.
3. 自旋锁和挂起等待锁
自旋锁: 是一种典型的轻量级锁, 在线程获取不到锁的情况下, 不会立刻放弃CPU, 而是会一直快速频繁进行获取, 直到获取到锁; 这种策略的优势在于节省线程调度的开销并且更能及时的获取到锁, 缺点就是更加浪费cpu资源.
挂起等待锁: 是一种典型的重量级锁, 线程在获取不到锁的情况下会堵塞等待(放弃CPU,进入等待队列), 然后等到锁被释放的时候再有操作系统调度.
🍂举个例子:
想象一下, 去追求一个女神, 当男生向女神表白后, 女神说: 你是个好人, 但是我有男朋友了.
挂起等待锁: 继续等, 等女神分手, 过了很久很久之后, 突然女神发来消息, “咱俩要不试试?”, 但这个很长的时间间隔后女神想起了你, 这期间已经是沧海桑田了, 女神可能已经换了好几个男票了.
自旋锁: 死皮赖脸的继续追求, 仍然每天持续的和女神说早安晚安, 一旦女神和上一任分手, 那么就能立刻抓住机会上位.
4. 普通互斥锁和读写锁
对于Java中synchronized这样的锁就是一个普通的互斥锁, 只涉及两个操作：
加锁.
解锁.
之所以有读写锁的设置是基于一个事实, 多线程针对同一个变量并发读, 这个时候没有线程安全问题的, 也不需要加锁控制, 对于读写锁来说, 分成了三个操作:
加读锁:如果代码只进行了读操作,就加读锁
加写锁:如果代码进行了修改操作,就加写锁
解锁: 针对读锁和读锁之间,是不存在互斥关系的
读锁和读锁之间是没有互斥的, 读锁和写锁之间, 写锁和写锁之间, 才需要互斥
在java中有读写锁的标准类, 位于java.util.concurrent.locks.ReentrantReadWriteLock, 其中ReentrantReadWriteLock.ReadLock为读锁, ReentrantReadWriteLock.WriteLock为写锁.
🍂应用场景:
很多开发场景中, 读操作非常高频, 比写操作的频率高很多, 如果我们所有场景都使用同一种锁, 就会浪费一些资源, 而如果使用读写锁将读操作和写操作分开加锁, 就可以避免一些不必要的开销.
5. 公平锁和非公平锁
公平锁: 多个线程在等待一把锁的时候, 遵循先来后到原则, 谁是先来的, 谁就先获得这把锁.
非公平锁: 多个线程等待同一把锁, 不遵守先来后到原则, 每个人等待线程获取锁的概率是均等的.
操作系统中原生的锁都是 “非公平锁”, 操作系统中的针对加锁的控制, 是依赖于线程调度顺序的, 这个调度顺序是随机的, 不会考虑到这个线程等待锁多久了, 如果想要实现公平锁, 就得在这个基础上加额外的数据结构(比如引入一个队列), 来记录线程的先后顺序.
6. 可重入锁和不可重入锁
可重入锁: 一个线程针对同一把锁连续加锁两次，不会出现死锁
不可重入锁: 一个线程针对同一把锁连续加锁两次，会出现死锁
二. synchronized的锁机制
结合上面的锁策略, Synchronized 具有如下特性 性(只考虑 JDK 1.8):
既是乐观锁也是悲观锁, 当锁竞争较小时它就是乐观锁(默认), 锁竞争较大时它就是悲观锁.
是普通互斥锁。
既是轻量级锁(默认)也是重量级锁, 根据锁竞争激烈程度自适应.
轻量级锁部分基于自旋锁实现, 重量级锁部分基于挂起等待锁实现.
是非公平锁.
是可重入锁.
1. 锁升级/锁膨胀
JVM 将 synchronized 锁分为 无锁, 偏向锁, 轻量级锁, 重量级锁 状态; 会根据情况, 进行依次升级.
当没有线程加锁的时候, 此时为无锁状态.
当首个线程进行加锁的时候, 此时进入偏向锁的状态, 偏向锁不是真的加锁, 而是在对象头做个标记(这个过程是非常轻量的).
🍂举个例子理解偏向锁:
这里我的人设是一个妹子, 我谈了一个小哥哥, 长的又帅又有钱, 如果时间长了, 就想换换把他甩了, 但是他要是对我纠缠不休, 这就很麻烦.
于是我就调整了更高效谈恋爱的方式, 我就只是和这个小哥哥搞暧昧, 不明确我们彼此的关系, 这样做的好处就是有朝一日, 我想换男朋友了, 就直接甩了就行, 毕竟我们有情侣之实而无情侣之名, 这样换人的成本就很低了.
但是如果在这个过程中, 有另外一个妹子, 也在对这个小哥哥频频示好, 我就需要提高警惕了, 对于这种情况, 由于我和小哥哥前面感情铺垫到位了, 就可以立即顺理成章的和小哥哥官宣确认情侣关系(加锁), 并且勒令小哥哥和这个妹子离远点.
偏向锁并不是真的加锁, 只是做了一个标记, 这样带来的好处就是, 后续如果没人竞争的时候, 就一直不去确立关系(节省了确立关系/分手的开销), 如果没有其他的线程来竞争这个锁, 就不必真的加锁(节省了加锁解锁的开销), 如果在执行代码过程中, 并没有其他线程来尝试加锁, 那么在执行完synchronized之后, 取消偏向锁即可.
上述过程, 就类似于 “偏向锁” 这个过程, 相当于 “懒汉模式” 中的懒加载一样, “非必要,不加锁”.
当有其他线程进行加锁, 导致产生了锁竞争时, 此时进入轻量级锁状态(迅速的把偏向锁升级成真正的加锁状态).
此处的轻量级锁是通过 CAS 来实现的, 如果其他的线程很快的释放锁, 那么我们的自旋锁是非常合适的, 但是如果其他线程长时间占用锁, 自旋锁就不太合适了, 自旋操作是一直让 CPU 空转, 比较浪费 CPU 资源, 因此此处的自旋不会一直持续进行, 而是达到一定的时间/重试次数, 就不再自旋了, 也就是所谓的 “自适应”.
如果竞争进一步加剧, 进入重量级锁状态(挂起等待锁).
重量级锁是基于操作系统原生的一组API(mutex)来进行加锁了, 当我们自旋不能快速获取到锁时, 锁竞争加剧, 就会升级为重量级锁, 我们的线程就会被放到阻塞队列中, 暂时不参与CPU调度, 当锁被释放了之后, 线程才有机会被调度, 从而有机会获取到锁, 一旦线程被切换出cpu, 这就是比较低效的事情了.
2. 锁消除
锁消除是编译器的智能判定, 有些代码, 编译器认为没有加锁的必要, 就会自动把你加的锁自动去除, 比如字符串相关的线程安全类StringBuffer, 这个类中的关键方法都带有synchronized, 但是当我们在单线程环境下使用StringBuffer, 不会涉及到线程安全问题, 此时编译器就会直接把这些加锁操作去除了.
3. 锁粗化
锁粗化就是将synchronized的加锁代码块范围增大, 加锁的代码块中的代码越多, 锁的粒度就越粗, 否则锁的粒度就越细.
通常情况下, 认为锁的粒度细一点比较好, 加锁的部分的代码, 是不能并发执行的, 锁的粒度越细, 能并发的代码就越多, 反之就越少.
但是有些情况下, 锁的粒度粗一些反而更好, 如果我们两次加锁解锁的时间间隙非常小, 分开加锁会造成额外的资源开销, 而且中间间隙很小, 就算并发效果也不是很明显, 这种情况下不如直接一把大锁搞定.
🍂举个例子理解锁粗化 ：
下属向领导汇报工作:
方式一:
第一次打电话, 汇报工作1, 挂电话.
第二次打电话, 汇报工作2, 挂电话.
第三次打电话, 汇报工作3, 挂电话.
方式二:
打电话, 汇报工作1, 2, 3, 挂电话, 显然, 相对于方式以, 这里的方案更高效.
