偏向锁、轻量级锁、重量级锁、自旋锁、自适应自旋锁
1. 偏向锁
偏向锁就是在运行过程中，对象的锁偏向某个线程。即在开启偏向锁机制的情况下，某个线程获得锁，当该线程下次再想要获得锁时，不需要重新申请获得锁（即忽略synchronized关键词），直接就可以执行同步代码，比较适合竞争较少的情况。
偏向锁的目标是，减少无竞争且只有一个线程使用锁的情况下，使用轻量级锁而产生的性能消耗。轻量级锁每次申请、释放锁都至少需要一次CAS，但偏向锁只有初始化时需要一次CAS。
如果明显存在其他线程申请锁，那么偏向锁将很快膨胀为轻量级锁。如果需要，使用参数
-XX:-UseBiasedLocking禁止偏向锁优化（默认打开）。
1.1 偏向锁获取过程
- 查看
Mark Word中偏向锁的标识以及锁标志位，若是否为偏向锁为1，并且锁标志位为01，则该锁为可偏向状态。 - 若该锁为可偏向状态，判断
Mark Word中的线程ID与当前线程ID是否相等，如果相同，则直接执行同步代码，否则通过CAS操作竞争锁。 - 如果竞争成功，将
Mark Word中线程ID设置为当前线程ID，然后执行同步代码。 - 如果竞争失败，说明有其他线程竞争。持有偏向锁状态的线程在没有字节码正在执行的情况下释放锁，然后恢复到未锁定状态或者膨胀为轻量级锁。
1.2 偏向锁释放过程
持有偏向锁的线程不会主动释放锁，只有遇到其他线程尝试竞争偏向锁时，持有偏向锁状态的线程才会释放锁。持有持有偏向锁的线程需要等到所有的同步任务执行完成之后（即没有字节码正在执行），才会暂停持有偏向锁的线程，然后恢复到未锁定状态或者膨胀为轻量级锁。
Mark Word是对象头的一部分，每个线程都拥有自己的线程栈（虚拟机栈），记录线程和函数调用的基本信息。
2. 轻量级锁
轻量级锁是相对于重量级锁而言的，使用时不需要申请互斥量。而是在没有多线程竞争的情况下，使用轻量级锁能够减少性能消耗，但是当多个线程同时竞争锁时，轻量级锁会膨胀为重量级锁。
轻量级锁的目标是，减少无实际竞争情况下，使用重量级锁产生的性能消耗，包括系统调用引起的内核态与用户态切换、线程阻塞造成的线程切换等。
1.1 轻量级锁获取过程
- 当线程执行代码进入同步块时，若
Mark Word锁标识为无锁状态（是否为偏向锁为0，锁标志位为01），虚拟机会在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间（用于存储当前对象的Mark Word的拷贝，官方称之为Dispalced Mark Word）。 - 复制对象头中的
Mark Word到锁记录中。 - 复制成功后，虚拟机将使用
CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针，并将Lock Record里的owner指针指向对象的Mark Word - 如果更新成功，则这个线程拥有了这个锁，并将锁标志位设置00，此对象处于轻量级锁定状态。
- 如果更新失败，虚拟机会检查对象的Mark Word是否指向当前线程的栈帧。如果是，则说明当前线程已经拥有这个锁，可进入执行同步代码；如果不是，则说明多个线程竞争，轻量级锁就会膨胀为重量级锁，
Mark Word中存储重量级锁（互斥锁）的指针，后面等待锁的线程也要进入阻塞状态。
1.2 轻量级锁释放过程
- 通过CAS操作尝试把线程中复制的
Displaced Mark Word对象替换当前的Mark Word。 - 如果替换成功，整个同步过程就完成了。
- 如果替换失败，说明有其他线程尝试过获取该锁（此时锁已膨胀），那就要在释放锁的同时，唤醒被挂起的线程。
3. 重量级锁
重量级锁为synchronized，通过对象内部的一个叫做监视器锁（monitor）来实现的。但是监视器锁本质又是依赖于底层的操作系统的Mutex Lock来实现的。而操作系统实现线程之间的切换这就需要从用户态转换到核心态，这个成本非常高，状态之间的转换需要相对比较长的时间，这就是为什么synchronized效率低的原因。因此，这种依赖于操作系统Mutex Lock所实现的锁我们称之为“重量级锁”。
4. 自旋锁
在自旋状态下，当一个线程A尝试进入同步代码块，但是当前的锁已经被线程B占有时，线程A不进入阻塞状态，而是不停的空转，等待线程B释放锁。如果锁的线程能在很短时间内释放资源，那么等待竞争锁的线程就不需要做内核态和用户态之间的切换进入阻塞状态，只需自旋，等持有锁的线程释放后即可立即获取锁，避免了用户线程和内核的切换消耗。
优点：开启自旋锁后能减少线程的阻塞，在对于锁的竞争不激烈且占用锁时间很短的代码块来说，能提升很大的性能，在这种情况下自旋的消耗小于线程阻塞挂起的消耗。
缺点：在线程竞争锁激烈，或持有锁的线程需要长时间执行同步代码块的情况下，使用自旋会使得CPU做太多无用功。
JDK1.6中，设置参数
-XX：+UseSpinning开启。JDK1.7后，由JVM自动控制。
5. 自适应自旋锁
自适应意味着自旋的时间不再固定了，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定：
- 如果在同一个锁对象上，自旋等待之前成功获得过的锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也很有可能再次成功，因此允许自旋等待持续相对更长的时间。
- 相反的，如果对于某个锁，自旋很少成功获得过，那么以后要获取这个锁时将可能减少自旋时间甚至省略自旋过程，以避免浪费处理器资源。
自适应自旋解决的是“锁竞争时间不确定”的问题。JVM很难感知确切的锁竞争时间，而交给用户分析就违反了JVM的设计初衷。自适应自旋假定不同线程持有同一个锁对象的时间基本相当，竞争程度趋于稳定。因此，可以根据上一次自旋的时间与结果调整下一次自旋的时间。
6. 总结
| 锁类型 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 偏向锁 | 加锁和解锁不需要额外的消耗，和执行非同步方法比仅存在纳秒级的差距。 | 如果线程间存在锁竞争，会带来额外的锁撤销的消耗。 | 适用于只有一个线程访问同步块场景。 |
| 轻量级锁 | 竞争的线程不会阻塞，提高了程序的响应速度。 | 如果始终得不到锁竞争的线程使用自旋会消耗CPU。 | 追求响应时间。同步块执行速度非常快。 |
| 重量级锁 | 线程竞争不使用自旋，不会消耗CPU。 | 线程阻塞，响应时间缓慢。 | 追求吞吐量。同步块执行速度较长。 |
参考链接：
https://www.jianshu.com/p/8c255b942535
Kotlin开发者社区
专注分享 Java、 Kotlin、Spring/Spring Boot、MySQL、redis、neo4j、NoSQL、Android、JavaScript、React、Node、函数式编程、编程思想、"高可用，高性能，高实时"大型分布式系统架构设计主题。
