偏向锁

当只有一个线程多次重复抢占锁同一资源时，即使是轻量级锁每次也至少需要两次(加锁、解锁)CAS操作。而此场景经Hotspot统计是比较容易出现的。所以为了减少不必要的资源浪费，偏向锁应运而生。

优点

• 只需要执行一次CAS即可获取锁
• 采用延迟释放锁策略
• 锁重入时，只需要判断mark_word.threadId(关于对象头的文章)是否为当前threadId即可

缺点

• 总体上只针对第一个线程有效，新线程获取锁时，会导致锁膨胀
• 锁膨胀时，会导致stop the world (STW)
• 与原生hashcode()互斥，导致偏向锁并非适应于所有的instance

如何获取一把偏向锁

前提

1. JVM偏向锁(-XX:+UseBiasedLocking)默认已开启
2. 确认instance可用偏向锁可用，即mark word 锁状态标记位为 01

分支条件

匿名偏向

若instance处于匿名偏向状态(即初始状态，threadId为null)，则执行CAS操作，将当前线程的id赋值到对象的mark word中，若成功则获取偏向锁成功，否则说明有多个线程竞争资源需要进行锁膨胀。

重偏向

即instance的Mark Word里的epoch与与klassOop.epoch标志位不一致时，表示此instance可被重偏向，此时新线程可以执行CAS操作进行锁抢占。

已偏向

即threadId已存在，且instance的epoch有效(与klassOop.epoch相等)此时instance处于已偏向状态。此时需比较当前threadId与mark_word.threadId的值，若相等，则可以继续占有锁，否则说存在资源竞争，需要进行锁膨胀。

锁膨胀过程

1. 所有要竞争锁的线程到达安全区后，挂起对应线程。
2. 遍历原锁持有线程的的调用栈的锁记录。将与被锁instance相关的锁记录改为轻量级锁相关的值。
3. 更改被锁instance的Mark Word，将其指向最早的锁记录。
4. 释放被挂起的相关线程。

偏向锁的骚操作

批量重偏向

Mark Word 里与偏向锁有关的信息除了threadId还有epoch，前面也提到epoch可以用来判断是否可以重偏向。那么他是如何实现的呢？

批量重偏向是针对两个线程串行共享instance资源场景(一个线程初始化instance传递给另一个线程)的优化。因为此时两个线程并不存在竞争，所以第二个线程可以继续使用偏向锁。

实现前提

Hotspot 通过在klassOop(可以理解为类的原型，其结构与instance一致)。里添加一个epoch字段，当一个Klass实例化instance一个时，便会以klassOop为原型初始化，epoch便被初始化在了instance的Mark Word中。

重偏向过程

1. 当JVM执行到一个全局安全点的时候，挂起所有线程。
2. 给KlassOop.epoch + 1.
3. 给所有被偏向锁锁住的instance的Mark Word中的epoch + 1。或者采用启发式撤销偏向锁。
4. 释放线程。

启发式撤销偏向

启发式撤销偏是针对重偏向的一种预防式优化。其逻辑很简单，通过设置一个阈值(k),一但epoch>k则执行撤销偏向锁操作，否者可以执行重偏向操作。

关于偏向锁的JVM参数

启用偏向锁

-XX:+UseBiasedLocking

偏向锁的延迟启动时间

偏向锁默认是在JVM启动4s后再初始化偏向锁，可用如下参数修改启动时间，设为0则表示立即启用。之所以这么设计是因为JVM启动的时候，如果立即启动偏向，有可能会因为线程竞争太激烈导致产生太多安全点挂起。
-XX:BiasedLockingStartupDelay=0

参考

1. https://www.oracle.com/technetwork/java/javase/tech/biasedlocking-oopsla2006-preso-150106.pdf

2. https://www.oracle.com/technetwork/java/biasedlocking-oopsla2006-wp-149958.pdf

3. http://ds.cs.ut.ee/courses/course-files/lockOptimizationHotSpot.pdf