引用自：http://blog.iluckymeeting.com/2018/01/06/threadandlocktwo/
为什么会有偏向锁、轻量级锁和重量级锁?
并发锁总共有4种状态：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态，每种状态在并发竞争情况下需要消耗的资源由低到高，性能由高到低。重量级锁需要通过操作系统在用户态与核心态之间切换，就像它的名字是一个重量级操作，这也是synchronized效率不高的原因，JDK1.6对synchronized进行了优化，引入了偏向锁与轻量级锁，提高了性能降低了资源消耗。
什么是偏向锁？
通过对大量数据的分析可以发现，大多数情况下锁竞争是不会发生的，往往是一个线程多次获得同一个锁，于是引入了偏向锁，偏向锁不会被刻意的释放，如果没有竞争，线程再次请求锁时可以直接获得锁。
偏向锁的获取
我们先来回顾一下偏向锁对象头的存储结构
- 首先检查对象头Mark Word中锁标记是否是偏向锁
- 检查对象头中记录的线程ID是否是当前线程的ID，如果是说明当前线程已经获得过锁，当前线程将再次获得锁，可以执行同步代码
- 如果对象头中的线程ID不是当前线程的ID，则通过CAS操作替换成当前线程的ID，如果替换成功意味着当前线程获得了锁，可以执行同步代码
- 如果步骤3的CAS操作失败，则意味着已经有别的线程获得了锁，针对这个锁出现了竞争，当已经获得了锁的线程到达全局安全点后（没有字节码执行）会被挂起，偏向锁膨胀为轻量级锁，被挂起的线程被唤醒，线程将按照轻量级锁的机制竞争锁
通过以上偏向锁的获得过程可以发现，偏向锁没有释放的步骤，它的加锁、解锁不需要消耗额外的资源;一旦偏向锁出现了竞争，它就会膨胀成轻量级锁，所以在锁竞争比较多的情况下它会额外的消耗资源做锁的膨胀。
什么是轻量级锁？
轻量级锁的性能介于偏向锁与重量级锁之间，在存在锁竞争的情况下，不需要让线程在阻塞与唤醒状态间切换，它的对象头存储结构如下：
除了对象头，轻量级锁还有一个相关的存储结构Monitor Record，它是JVM在栈中开辟出的一块空间，里面会保存获得锁的线程信息，而对象头中记录的锁指针就指向这个Monitor Record。
轻量级锁的获取
- JVM在执行同步代码块前，会在栈中开辟一块空间存储锁记录Monitor Record，并将对象头中的Mark Word复制到锁记录中，称为Displaced Mark Word。
- 线程通过CAS操作尝试将Mark Word指向锁记录，如果成功意味着线程获得了锁，Monitor Record中会有一个字段Owner记录获得锁的线程信息
- 如果步骤2中的CAS操作失败，则线程进入自旋等待（默认10次），如果自旋成功，则线程获得了锁可以执行同步代码，如果自旋失败，这个锁会膨胀成重量级锁
- 线程执行完成后，将通过CAS操作将Monitor Record中记录的Displaced Mark Word替换回对象头中的Mark Word，如果操作成功则锁被释放，如果操作失败，则意味着存在锁竞争，这个锁将膨胀成重量级锁
由以上轻量级锁的获取步骤可以看出，竞争锁的线程如果竞争失败不会进入阻塞状态，所以不会发生线程在用户态与核心态的切换，资源消耗比重量级锁少，但是竞争失败的线程会进入自旋状态，这又白白浪费了CPU计算资源。
什么是重量级锁？
重量级锁在JVM中有一个监视器(Monitor)，保持了两个队列：锁竞争队列和信号阻塞队列，一个实现线程互斥，另一个实现线程同步。重量级锁在底层是靠操作系统的Mutex Lock实现的，线程在阻塞和唤醒状态间切换需要操作系统将线程在用户态与核心态之间转换，成本很高，所以最早的synchronized效率不高。
偏向锁、轻量级锁和重量级锁对比
| 锁类型 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 偏向锁 | 加锁、解锁不需要额外资源消耗，效率较高 | 如果线程间存在锁竞争，会带来额外的解锁消耗 | 适用只有一个线程访问同步块的情景 |
| 轻量级锁 | 竞争的线程不会阻塞，提高了程序响应速度 | 如果获取锁失败，会进入自旋消耗cpu | 针对锁占用时间短，对响应时间比较敏感的情况 |
| 重量级锁 | 线程竞争不使用自旋，不消耗cpu | 线程会被阻塞，影响响应时间 | 锁占用时间较长，对吞吐量要求较高 |
