问题引入
通过 synchronized 实现临界区内代码的原子性，本质是通过对象的 Monitor 来实现的，而 Monitor 本质又依赖于底层操作系统的 Mutex Lock 来实现，这种方式成本非常高，故称作重量级锁
优化思路
为了降低成本，提高获得锁和释放锁的效率，在 Java 6 引入了轻量级锁与偏向锁，此后，锁有 4 种状态，级别从低到高分别为无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态，随着竞争加剧，锁状态逐渐升级，锁可以升级但不能降级
轻量级锁
使用场景
多个线程交替访问临界区代码，并无竞争，若出现竞争则会导致轻量级锁膨胀为重量级锁
原理分析
加锁
- JVM 首先在当前线程的栈桢中创建用于存储锁记录的空间 Lock Record
- 让 Lock Record 中的 Object Reference 指向 Object
- 尝试使用 CAS 将 Lock Record 中的锁记录指针与 Object 中的 Mark Word 进行交换，先检查 Object 中的锁标志是否为 01 ，01意味着无锁或偏向锁，若为 01 则交换成功，Object 对象头的 Mark Word 中保存了锁记录的地址以及锁标志位 00
- 若 CAS 失败，有两种可能情况，①临界区代码中再次访问临界区，导致锁重入；②其它线程正在访问临界区，出现竞争
- 情况①中，由于 Object 的 Mark Word 中保存了锁记录指针，故 JVM 可以判断出该锁就是当前线程加的，不会发生锁膨胀，而是又创建一个 Lock Record ，但其中保存锁记录指针的位置为 null ，仅仅用于锁重入的计数
- 情况②中，出现竞争，轻量级锁膨胀为重量级锁
- Object 申请一个 Monitor ，让 Object 的 Mark Word 的前 30 bit 保存指向该 Monitor 的指针
- 该线程被阻塞，进入 Monitor 的 EntryList 中
解锁
- 若锁记录为 null ，表示有重入，直接清除 Lock Record 即可
- 若锁记录不为 null ，也就是最早加的锁，尝试使用 CAS 将 Lock Record 中保存的 HashCode age biased 01 信息还原到 Object 的 Mark Word 中，如果成功，则实现解锁，如果发现锁已经膨胀变成重量级锁（Object 的 Mark Word 已经变成 Monitor 信息，后 2bit 变成 10），解锁失败，进入重量级锁解锁流程
- 按照 Monitor 的地址找到 Monitor ，设置 Owner 为 null ，并唤醒 EntryList 中阻塞的线程
偏向锁（Biased Lock）
使用场景
同一线程多次访问临界区代码，若存在多个线程访问，则锁膨胀为轻量级锁
核心思想
顾名思义，偏向锁会偏向第一个获取锁的线程，这个线程在之后获取该锁不再需要进行复杂的 CAS 操作，大大提高同一线程多次获取锁的效率
原理分析
加锁
- 检测 Object 中的 Mark Word 的锁标记位是否为 01
- 若锁标记位是为 01，则说明对象处于无锁或偏向锁状态，进一步判断是否可偏向位
- 若不可偏向（是否可偏向位为 0），则锁膨胀为轻量级锁
- 若可偏向（是否可偏向位为 1 ），检测 Object 中的 Mark Word 中记录的是否为当前线程 ID
- 若为当前线程 ID ，则获取锁（无需进行 CAS 操作）
- 若不为当前线程 ID ，尝试使用 CAS 操作竞争锁（将该线程 ID 写入 Mark Word）
- 若 CAS 操作成功（原来为无锁状态），则获取锁
- 若 CAS 操作失败（原来为偏向锁状态），则说明有另外的线程已经获取了该对象的偏向锁，故撤销偏向（Revoke Bias），锁膨胀为轻量级锁
批量重偏向
当一个类的大量对象被一个线程作为锁，执行了同步操作后，若另外一个线程也需要对这些对象加锁并操作，就会引发大量的偏向锁撤销，影响性能
当这种偏向锁撤销超过一定阈值后（通常为 20 次），JVM 会认为该类对象的偏向锁有问题，进行批量重偏向，下一次该线程对这些对象加锁，产生竞争时，不会发生锁膨胀，而是会使用 CAS 操作将线程 ID 重新设置为当前线程 ID
批量撤销
当偏向锁撤销超过一定阈值（通常为 40 次），JVM 会认为该类对象的竞争较为激烈，将该类的全部对象（包括新创建的对象）标记为不可偏向（是否可偏向标记为 0 ）