synchronized优化原理

轻量级锁

如果一个对象有多个线程访问，但多线程访问的时间是错开的（没有竞争），可以用轻量级锁优化

  @Slf4j(topic = "c.ExerciseTransfer")public class Test {​static final Object obj = new Object();public static void main(String[] args) throws InterruptedException {synchronized (obj){method();}}​public static void method(){synchronized (obj){}}}

让锁记录中 Object reference 指向锁对象，并尝试用 cas 替换 Object 的 Mark Word，将 Mark Word 的值存 入锁记录

如果 cas 替换成功，对象头中存储了 锁记录地址和状态 00 ，表示由该线程给对象加锁，这时图示如下。

如果 cas 失败，有两种情况

• 如果是其它线程已经持有了该 Object 的轻量级锁，这时表明有竞争，进入锁膨胀过程

• 如果是自己执行了 synchronized 锁重入，那么再添加一条 Lock Record 作为重入的计数

当退出 synchronized 代码块（解锁时）如果有取值为 null 的锁记录，表示有重入，这时重置锁记录，表示重入计数减一。

当退出 synchronized 代码块（解锁时）锁记录的值不为 null，这时使用 cas 将 Mark Word 的值恢复给对象头

• 成功，则解锁成功

• 失败，说明轻量级锁进行了锁膨胀或已经升级为重量级锁，进入重量级锁解锁流程

锁膨胀

如果在尝试加轻量级锁的过程中，CAS 操作无法成功，这时一种情况就是有其它线程为此对象加上了轻量级锁（有 竞争），这时需要进行锁膨胀，将轻量级锁变为重量级锁。

这时 Thread-1 加轻量级锁失败，进入锁膨胀流程

• 即为 Object 对象申请 Monitor 锁，让 Object 指向重量级锁地址

• 然后自己进入 Monitor 的 EntryList BLOCKED

  

当 Thread-0 退出同步块解锁时，使用 cas 将 Mark Word 的值恢复给对象头，失败。这时会进入重量级解锁 流程，即按照 Monitor 地址找到 Monitor 对象，设置 Owner 为 null，唤醒 EntryList 中 BLOCKED 线程。

自旋优化

重量级锁竞争的时候，还可以使用自旋来进行优化，如果当前线程自旋成功（即这时候持锁线程已经退出了同步块，释放了锁），这时当前线程就可以避免阻塞。

偏向锁

轻量级锁在没有竞争时（就自己这个线程），每次重入仍然需要执行 CAS 操作。

Java 6 中引入了偏向锁来做进一步优化：只有第一次使用 CAS 将线程 ID 设置到对象的 Mark Word 头，之后发现这个线程 ID 是自己的就表示没有竞争，不用重新 CAS。以后只要不发生竞争，这个对象就归该线程所有。例如：

  static final Object obj = new Object();public static void m1() {synchronized( obj ) {// 同步块 Am2();}}public static void m2() {synchronized( obj ) {// 同步块 Bm3();}}public static void m3() {synchronized( obj ) {// 同步块 C}}

偏向状态

之所以要用偏向锁是因为轻量级锁的锁重入每次都调用CAS进行对比，CAS是一个OS指令操作，速度很慢。所以偏向锁是把ThreadId直接赋值给markword，那么下次能直接在java上对比这个markword。

1. 偏向锁带有延迟性，通常对象创建过一会才会生成

2. 先生成偏向锁->轻量级锁->重量级锁

3. 如果给临时区使用偏向锁，那么对应执行线程的id赋值给markword

4. 如果使用了锁的hashcode，那么偏向锁就会被禁止，因为hashcode占用的bit太多。

5. 轻量级在锁记录上记录hashcode，重量级在monitor上记录

6. 如果两个线程用同一个偏向级锁，那么锁会变成不可偏向，升级为轻量级锁。