偏向锁
当只有一个线程多次重复抢占锁同一资源时，即使是轻量级锁每次也至少需要两次(加锁、解锁)CAS操作。而此场景经Hotspot统计是比较容易出现的。所以为了减少不必要的资源浪费，偏向锁应运而生。
优点
- 只需要执行一次CAS即可获取锁
- 采用延迟释放锁策略
- 锁重入时，只需要判断mark_word.threadId(关于对象头的文章)是否为当前threadId即可
缺点
- 总体上只针对第一个线程有效，新线程获取锁时，会导致锁膨胀
- 锁膨胀时，会导致stop the world (STW)
- 与原生hashcode()互斥，导致偏向锁并非适应于所有的instance
如何获取一把偏向锁
前提
- JVM偏向锁(-XX:+UseBiasedLocking)默认已开启
- 确认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的值，若相等，则可以继续占有锁，否则说存在资源竞争，需要进行锁膨胀。
锁膨胀过程
- 所有要竞争锁的线程到达安全区后，挂起对应线程。
- 遍历原锁持有线程的的调用栈的锁记录。将与被锁instance相关的锁记录改为轻量级锁相关的值。
- 更改被锁instance的Mark Word，将其指向最早的锁记录。
- 释放被挂起的相关线程。
偏向锁的骚操作
批量重偏向
Mark Word 里与偏向锁有关的信息除了threadId还有epoch，前面也提到epoch可以用来判断是否可以重偏向。那么他是如何实现的呢？
批量重偏向是针对两个线程串行共享instance资源场景(一个线程初始化instance传递给另一个线程)的优化。因为此时两个线程并不存在竞争，所以第二个线程可以继续使用偏向锁。
实现前提
Hotspot 通过在klassOop(可以理解为类的原型，其结构与instance一致)。里添加一个epoch字段，当一个Klass实例化instance一个时，便会以klassOop为原型初始化，epoch便被初始化在了instance的Mark Word中。
重偏向过程
- 当JVM执行到一个全局安全点的时候，挂起所有线程。
- 给KlassOop.epoch + 1.
- 给所有被偏向锁锁住的instance的Mark Word中的epoch + 1。或者采用启发式撤销偏向锁。
- 释放线程。
启发式撤销偏向
启发式撤销偏是针对重偏向的一种预防式优化。其逻辑很简单，通过设置一个阈值(k),一但epoch>k则执行撤销偏向锁操作，否者可以执行重偏向操作。
关于偏向锁的JVM参数
启用偏向锁
-XX:+UseBiasedLocking
偏向锁的延迟启动时间
偏向锁默认是在JVM启动4s后再初始化偏向锁，可用如下参数修改启动时间，设为0则表示立即启用。之所以这么设计是因为JVM启动的时候，如果立即启动偏向，有可能会因为线程竞争太激烈导致产生太多安全点挂起。
-XX:BiasedLockingStartupDelay=0
