为什么引入偏向锁

  • HotSpot的作者经过研究发现，大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，如果每次都要竞争锁会增大很多没有必要付出的代价，为了降低获取锁的代价，才引入的偏向锁。

  • 当一个线程访问加了同步锁的代码块时，会在对象头中存储当前线程的 ID，后续这个线程进入和退出这段加了同步锁的代码块时，不需要再次加锁和释放锁。而是直接比较对象头里面是否存储了指向当前线程的线程ID。如果相等表示偏向锁是偏向于当前线程的，就不需要再尝试获得锁了。

    偏向锁的获取

  • 首先获取锁对象头中的 Mark Word，判断当前对象是否处于可偏向状态(即当前没有对象获得偏向锁)。

  • 如果是可偏向状态，则通过CAS原子操作，把当前线程的ID，写入到 Mark Word
    • 如果CAS成功，表示获得偏向锁成功，会将偏向锁标记设置为1，且将当前线程的ID写入Mark Word；
    • 如果CAS失败则说明当前有其他线程获得了偏向锁，同时也说明当前环境存在锁竞争，这时候就需要将已获得偏向锁的线程中的偏向锁撤销掉，并升级为轻量级锁(偏向锁的撤销，需要等待全局安全点，即在这个时间点上没有正在执行的字节码)。

  • 如果当前线程是已偏向状态，需要检查Mark Word中的ThreadID是否和自己相等，如果相等则不需要再次获得锁，可以直接执行同步代码块，如果不相等，说明当前偏向的是其他线程，需要撤销偏向锁并升级到轻量级锁

    偏向锁撤销之调用对象HashCode

    调用锁对象的obj.hashCode()或System.identityHashCode(obj)方法会导致该对象的偏向锁被撤销。因为对于一个对象，其HashCode只会生成一次并保存，偏向锁是没有地方保存hashcode的。

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

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

当对象处于可偏向（也就是线程ID为0）和已偏向的状态下，调用HashCode计算将会使对象再也无法偏向：

  • 当对象可偏向时，MarkWord将变成未锁定状态，并只能升级成轻量锁；
  • 当对象正处于偏向锁时，调用HashCode将使偏向锁强制升级成重量锁。