目录
一、轻量级锁
二、锁膨胀
三、自旋优化
四、偏向锁
五、锁消除
一、轻量级锁
1. 会创建一个锁记录 Lock Record(保存在线程栈中),尝试 CAS 修改 Mark Word 中的对象头,是一种乐观锁的思想,而不是将 Java 对象与操作系统的 Monitor 对象关联起来(重量级锁)
2. CAS 修改
- mark word 最后两位是 01 表示无锁,最后两位是 00 表示有锁,加锁失败
- 也有可能是锁的重入(判断对象头的锁记录地址是不是自己),如果是自己执行锁重入,那么再添加一条锁记录 Lock Record 作为锁重入的记录(重入时,锁记录为 null;非重入锁,锁记录是对象头 Mark Word 的值),解锁的时候就是解一次锁去掉一条锁记录,要等栈帧中的所有锁记录被去除才是真的释放了锁
二、锁膨胀
如果在尝试 CAS 替换锁对象的对象头 Mark Word 和锁记录时,替换失败,有种情况就是其他线程对该对象加上了轻量级锁(有竞争),此时就会发生锁膨胀,将轻量级锁升级为重量级锁
- 加轻量级锁失败,申请 Monitor 锁,让 Object 指向 Monitor,建立 Java 对象和 Monitor 的关联,将 mark word 最后两位变为 10,表示重量级锁
- 加锁(轻量级锁)失败的线程,加入 Monitor 的阻塞队列
- 解锁:Thread-0(获取轻量级锁成功的)通过 CAS 将 Mark Word 的值恢复给对象头,由于对象头已经变成了 Monitor 的地址,所以恢复失败,接下来就会走重量级锁的解锁流程,先到 Monitor 中清空 Owner,到阻塞队列唤醒 Thread-1,恢复 Mark Word
三、自旋优化
重量级锁竞争时,线程可以通过自旋来优化,原来需要加入阻塞队列(上下文切换),开销较大,自旋可以重试访问重新判断锁是否可用,自旋成功(在自旋过程中,持有锁的线程退出了同步代码块,释放锁)避免阻塞
- 自旋会一直消耗 CPU,适用于多核的情况(单核在执行持有锁的线程的任务,自旋线程会被阻塞,没有意义)
- 问题:可以间隔一段时间再重试吗❓
- 自旋失败:重试一定次数还是失败就加入阻塞队列
- Java 6 之后 的自旋锁是自适应的,JVM 底层会根据最近自旋是否成功来判断自旋的次数,最近成功了说明成功概率比较大,就多自旋几次;最近失败了就少重试几次或者不重试;Java 7 之后不能控制是否开启自旋锁,都是由底层来控制是否开启的
四、偏向锁 ‼️
轻量级锁在没有发生竞争时,同一个线程需要重入锁,也需要进行多次 CAS 操作,影响性能
Java 6 中引入的偏向锁来做进一步优化:第一次进行 CAS 操作时,将线程 ID 设置到对象头 Mark Word 中,之后需要重入锁,只需要判断对象头的 ID 是不是自己,不需要进行 CAS 操作
之后只要不发生竞争,这个对象就归该线程所有(问题:如何判断是否发生锁竞争❓锁竞争会将轻量级锁升级为重量级锁,对象头的 Mark Word 会指向 Monitor,释放锁的时候 CAS 失败)
1. 创建对象:如果开启了偏向锁(默认开启),mark word 最后三位是 101,此时 thread、epoch、age 都是 0,但是偏向锁默认是有延迟的,在程序刚启动时不会生效,如果想避免延迟立即生效可以加 JVM 参数;没有开启偏向锁,mark word 最后三位是 001,此时 hashcode、age 都是 0,在第一次用到 hashcode 时才会赋值
问题:创建对象时 101 的意思是已经加了偏向锁还是表示可以加偏向锁❓
2. 加锁:给对象头设置线程 id
3. 释放锁:线程 id 还是保持上一个线程,除非发生锁竞争,这就是偏向锁名字的来由,偏向同一个线程,当该线程再次请求时就不需要再进行复杂的加锁操作
4. 适用场景:单线程多次使用,不适合有多个线程来竞争这把锁的场景,如果知道可能会有冲突,可以通过加 JVM 参数禁用偏向锁,让对象刚创建时是 Normal 正常状态,加锁时后两位是 00(轻量级锁)
5. 加锁顺序:偏向锁 -> 轻量级锁 -> 重量级锁
6. 撤销
- ⚠️ 注意:调用了 hashcode() 之后就会禁用 / 撤销偏向锁,因为调用 hashcode() 会给 mark word 赋值哈希码,mark word 的大小不够存放线程 id 了,本来可偏向的状态就会被撤销,由 101 变成 001;但是轻量级锁和重量级锁不会有这个问题,因为轻量级锁调用 hashcode() 之后会将哈希码存到锁记录里,重量级锁会存到 monitor 里,解锁时还会还原
- 释放锁之后其他线程要使用锁:撤销偏向状态(101 -> 001,由可偏向改为不可偏向),将偏向锁升级为轻量级锁(注意不是锁竞争,如果冲突的话是升级为重量级锁了)
- 调用 wait/notify:也会撤销偏向锁升级为重量级锁,因为 wait/notify 只有重量级锁有
撤销偏向状态比较影响性能:虽然对象被多个线程访问,但并没有发生竞争(t1 释放时候 t2 才访问的),撤销偏向状态升级锁没啥必要,可以将原本偏向 t1 的置为偏向 t2 的(修改 mark word 的线程 id)⬇️
7. 批量重偏向:被多个线程访问但没有发生竞争,修改偏向的线程 id
- 开启批量重偏向的阈值:当撤销偏向锁的次数达到 20 次之后,JVM 会觉得可能偏向错了,就在加锁时重新偏向加锁线程(第二十次就已经改了)
- 批量:修改偏向状态是将这批对象的线程 id 都修改成最后一个请求他们锁的线程
8. 批量撤销:撤销偏向达到 40 次(本来就不该偏向),JVM 会对该类的所有对象批量撤销偏向锁,直接进入轻量级锁的状态,新建对象也是 001 不可偏向的
五、锁消除
JVM 的高级优化技术,允许编译器确定锁对象不会引起线程安全问题时,减少不必要的加锁操作,提升程序性能,是 JVM 自动进行的优化,对开发者是透明的
1. JIT 即时编译器会对热点代码(重复调用的)进行优化,如果 synchronized 的对象不会逃离方法的作用范围(局部变量),就可以不加锁,直接消除锁
2. 工作原理
3. 示例场景
- 如果一个方法内部创建了一个局部变量,对该局部变量进行加锁操作,但是该变量仅存在当前方法栈帧中,不会被其他线程并发访问,所以没有线程安全问题,JVM 就会进行锁消除的优化
4. 优点
- 性能提升:减少上下文切换和同步开销
- 简化编程:开发者不需要自己去判断哪些锁是可以避免的,由编译器来自动执行