synchronized优化原理（轻量级锁、锁膨胀、自旋优化、偏向锁、锁消除）有图解

1.轻量级锁

轻量级锁的使用场景：如果一个对象虽然有多线程访问，但多线程访问的时间是错开的（也就是没有竞争），那么可以使用轻量级锁来优化。

轻量级锁对使用者是透明的，语法仍然是synchronized

假设有两个方法同步块，利用同一个对象加锁

• 当线程运行到synchronized这一步时，会创建锁记录(Lock Record)对象，这个对象里的Object reference是一个对象指针（存储的是对象的引用地址），上面那部分是存储加锁对象的Mark Word。每个线程的栈帧都会包含一个锁记录的结构，内部可以存储锁定对象的Mark Word

上图 Object中的Hashcode Age Bias 01（也就是Mark Word）和KlassWord是对象头，下面的Object body是对象体。

• 让锁记录中Object reference指向锁对象，并尝试用cas替换Object的Mark Word，将Mark Word的值存入锁记录
  
  注：Object中的01表示的是无锁状态，Lock Record中的00表示的是轻量级锁的状态。如是10则是重量级锁
• 如果cas替换成功，对象头中存储了锁记录地址和状态00，表示由该线程给对象加锁，这时图示如下：
  

cas能保证这个替换操作是原子性的，不会被打断。

• 如果cas失败，有两种情况
  • 如果是其他线程已经持有了该Object的轻量级锁，这时表明有竞争，进入锁膨胀过程
  • 如果是自己执行了synchronized锁重入，那么再添加一条Lock Record作为重入的计数（也就是上述代码method2中的synchronized）
    
    轻量锁->竞争关系就膨胀成重量锁，如果还是自己就是可重入锁
• 当退出synchronized代码块（解锁时）如果有取值为null的锁记录，表示有重入，这时重置锁记录，表示重入计数减一。
  
• 当退出synchronized代码块（解锁时）锁记录的值不为null，这时使用cas将Mark Word的值恢复给对象头
  • 成功，则解锁成功
  • 失败，说明轻量级锁进行了锁膨胀或已经升级为重量级锁，进入重量级锁解锁流程

2.锁膨胀

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

• 当Thread-1进行轻量级加锁时，Thread-0已经对该对象加了轻量级锁
  
• 这时Thread-1加轻量级锁失败，进入锁膨胀流程
  • 即为Object对象申请Monitor锁，让Object指向重量级锁地址
  • 然后自己进入Monitor的EntryList BLOCKED
    
• 当Thread-0退出同步块解锁时，使用cas将Mark Word的值恢复给对象头，失败（因为此时Mark Word的值已经为Monitor地址，变成了重量级锁的值，后两位也变成了10）。这时会进入重量级锁流程，即按照Monitor地址找到Monitor对象，设置Owner为null，唤醒EntryList中BLOCKED线程。

3.自旋优化

重量级锁竞争的时候，还可以使用自旋来进行优化，如果当前线程自旋成功（即这时候持锁线程已经退出了同步块，释放了锁），这时当前线程就可以避免阻塞。（自旋就是让线程暂时不要进入阻塞，而是进入循环，如果在循环过程中持锁线程已经退出了同步块，释放了锁，这时线程就可避免阻塞，在多核cpu下才有意义）

自旋重试成功的情况

自旋重试失败的情况

• 在Java 6之后自旋锁是自适应的，比如对象刚刚的一次自旋操作成功过，那么认为这次自旋成功的可能性会高，就多自旋几次；反之，就少自旋甚至不自旋。总的来说就是比较智能。
• 自旋会占用CPU时间，单核CPU自旋就是浪费，多核CPU自旋才能发挥优势。
• Java 7之后不能控制是否开启自旋功能

4.偏向锁

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

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

例如：

偏向状态

对象头格式如下：

上图Normal和Biased中的biased_lock表示是否启用偏向锁，0表示不启用，1表示启用，Heavyweight Lock的10前面表示的是重量级锁的指针，Lightweight Locked的00前面表示的是指向锁记录的指针。

一个对象创建时：

• 如果开启了偏向锁（默认开启），那么对象创建后，Mark Word值为0x05即最后3位为101，这时它的thread、epoch、age都为0。
• 偏向锁默认是延迟的，不会在程序启动时立即生效，如果想避免延迟，可以加VM参数xx:BiasedLockingStartupDelay=0来禁用延迟。
• 如果没有开启偏向锁，那么对象创建后，Mark Word值为0x01即最后3位为001，这时它的hashcode、age都为0，第一次用到hashcode时才会赋值。

当应用程序里就一个线程，这种情况比较适合偏向锁（冲突少的情况），如果应用程序里经常多线程竞争，此时就不适合偏向锁。可以用vm参数-xx:-UseBiasedLocking禁用偏向锁。

撤销 - 调用对象hashCode

调用了对象的hashCode，但偏向锁的对象MarkWord中存储的是线程id，如果调用hashCode会导致偏向锁被撤销

• 轻量级锁会在锁记录中记录hashCode
• 重量级锁会在Monitor中记录hashCode

在调用hashCode后使用偏向锁，记得去掉-xx:-UseBiasedLocking

当可偏向对象调用它的hashcode方法时，它就会撤销偏向状态，将线程id替换成哈希码

撤销 - 其他线程使用对象

当有其他线程使用偏向锁对象时，会将偏向锁升级为轻量级锁

撤销 - 调用wait/notify

wait和notify只有重量级锁才有，调用这两个方法会将偏向锁或者轻量级锁升级为重量级锁。

批量重偏向

如果对象虽然被多个线程访问，但没有竞争，这时偏向了线程T1的对象仍有机会重新偏向T2，重偏向会重置对象的ThreadID。

当撤销偏向锁阈值超过20次后，jvm会这样觉得，我是不是偏向错了呢，于是会在给这些对象加锁时重新偏向至加锁线程。

批量撤销

当撤销偏向锁阈值超过40次后，jvm会这样觉得，自己确实偏向错了，根本就不该偏向。于是整个类的所有对象都会变为不可偏向的，新建的对象也是不可偏向的。