目录

一、轻量级锁

二、锁膨胀

三、自旋优化

四、偏向锁

五、锁消除

---

一、轻量级锁

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. 优点

• 性能提升：减少上下文切换和同步开销
• 简化编程：开发者不需要自己去判断哪些锁是可以避免的，由编译器来自动执行