背景
自 Java 6/Java 7 开始，Java虚拟机对内部锁的实现进行了一些优化（主要针对的是 synchronized）。
这些优化主要包括锁消除（Lock Elision）、锁粗化（Lock Coarsening/Lock Merging）、偏向锁（Biased Locking）以及适应性锁（Adaptive Locking，也称为适应性自旋（Adaptive Spinning）。
锁消除（Lock Elision）
锁消除（Lock Elision）是 JIT 编译器对内部锁的具体实现所做的一种优化。即对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行削除。
锁削除的主要判定依据来源于**逃逸分析（Escape Analysis）**的数据支持，如果判断到一段代码中，在堆上的所有数据都不会逃逸出去被其他线程访问到，那就可以把它们当作栈上数据对待，认为它们是线程私有的，同步加锁自然就无须进行。
换句话来说，如果同步块所使用的锁对象通过这种分析被证实只能够被一个线程访问，那么 JIT 编译器在编译这个同步块的时候并不生成 synchronized 所表示的锁的申请与释放对应的机器码，而仅生成原临界区代码对应的机器码，这就造成了被动态编译的字节码就像是不包含 monitorenter（申请锁）和 monitorexit（释放锁）这两个字节码指令一样，即消除了锁的使用。这种编译器优化就被称为锁消除（Lock Elision），它使得特定情况下我们可以完全消除锁的开销。
是否需要锁消除
也许有人可能会问，变量是否逃逸，对于虚拟机来说需要使用数据流分析来确定，但是程序员自己应该是很清楚的，怎么会在明知道不存在数据争用的情况下要求同步呢？
答案是有许多同步措施并不是程序员自己加入的，同步的代码在 Java 程序中的普遍程度也许超过了大部分读者的想象。
例子1
如果同步块所使用的锁对象通过这种分析被证实只能够被一个线程访问，那么JIT编译器在编译这个同步块的时候就会取消对这部分代码的同步。
如以下代码：
public void f() {
Test test = new Test();
synchronized(test) {
System.out.println(test);
}
}
代码中对 test 这个对象进行加锁，但是 test 对象的生命周期只在 f() 方法中，并不会被其他线程所访问到，所以在 JIT 编译阶段就会被优化掉。优化成：
public void f() {
Test test = new Test();
System.out.println(test);
}
这里，可能有读者会质疑了，代码是程序员自己写的，程序员难道没有能力判断要不要加锁吗？
就像以上代码，完全没必要加锁，有经验的开发者一眼就能看的出来的。
其实道理是这样，但是还是有可能有疏忽，比如我们经常在代码中使用 StringBuffer 作为局部变量，而 StringBuffer 中的 append 是线程安全的，有 synchronized 修饰的，这种情况开发者可能会忽略。这时候，JIT 就可以帮忙优化，进行锁消除。
例子2 - StringBuffer
Java 标准库中的有些类（比如StringBuffer）虽然是线程安全的，但是在实际使用中我们往往不在多个线程间共享这些类的实例。而这些类在实现线程安全的时候往往借助于内部锁。因此，这些类是锁消除优化的常见目标。
我们来看下面的一个例子，这段非常简单的代码仅仅是输出三个字符串相加的结果，无论是源码字面上还是程序语义上都没有同步。
public String concatString(String s1, String s2, String s3) {
return s1 + s2 + s3;
}
我们也知道，由于 String 是一个不可变的类，对字符串的连接操作总是通过生成新的 String 对象来进行的，因此 Javac 编译器会对 String 连接做自动优化。在 JDK 1.5 之前，会转化为 StringBuffer 对象的连续 append() 操作，在 JDK 1.5 及以后的版本中，会转化为 StringBuilder 对象的连续 append() 操作。
即上面的代码等价于下面这样 ：
public String concatString(String s1, String s2, String s3) {
StringBuffer sb = new StringBuffer();
sb.append(s1);
sb.append(s2);
sb.append(s3);
return sb.toString();
}
现在大家还认为这段代码没有涉及同步吗？每个 StringBuffer.append() 方法中都有一个同步块，锁就是 sb 对象。虚拟机观察变量 sb，很快就会发现它的动态作用域被限制在 concatString() 方法内部。也就是 sb 的所有引用永远不会“逃逸”到 concatString() 方法之外，其他线程无法访问到它，所以这里虽然有锁，但是可以被安全地削除掉，在即时编译之后，这段代码就会忽略掉所有的同步而直接执行了。
锁粗化（Lock Coarsening/Lock Merging）
锁粗化（Lock Coarsening/Lock Merging）也是 JIT 编译器对内部锁的具体实现所做的一种优化。
原则上，我们在编写代码的时候，总是推荐将同步块的作用范围限制得尽量小——只在共享数据的实际作用域中才进行同步，这样是为了使得需要同步的操作数量尽可能变小，如果存在锁竞争，那等待锁的线程也能尽快地拿到锁。
大部分情况下，上面的原则都是正确的，但是如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作是出现在循环体中的，那即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。
在上面举的连续调用 append() 方法的例子就属于这类情况。如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展（膨胀）到整个操作序列的外部，就是扩展到第一个 append() 操作之前直至最后一个 append() 操作之后，这样只需要加锁一次就可以了。
轻量级锁
JDK 1.6 引入了偏向锁和轻量级锁，从而让锁拥有了四个状态：无锁状态（unlocked）、偏向锁状态（biasble）、轻量级锁状态（lightweight locked）和重量级锁状态（inflated）。
**“轻量级”是相对于使用操作系统互斥量来实现的传统锁而言的，因此传统的锁机制就被称为“重量级”**锁。
需要强调一点的是，轻量级锁并不是用来代替重量级锁的，它的本意是在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。
轻量级锁是相对于传统的重量级锁而言，它使用 CAS 操作来避免重量级锁使用互斥量的开销。对于绝大部分的锁，在整个同步周期内都是不存在竞争的，因此也就不需要都使用互斥量进行同步，可以先采用 CAS 操作进行同步，如果 CAS 失败了再改用互斥量进行同步。
当尝试获取一个锁对象时，如果锁对象标记为 0 01，说明锁对象的锁未锁定（unlocked）状态。此时虚拟机在当前线程的虚拟机栈中创建 Lock Record，然后使用 CAS 操作将对象的 Mark Word 更新为 Lock Record 指针。如果 CAS 操作成功了，那么线程就获取了该对象上的锁，并且对象的 Mark Word 的锁标记变为 00，表示该对象处于轻量级锁状态。
如果 CAS 操作失败了，虚拟机首先会检查对象的 Mark Word 是否指向当前线程的虚拟机栈，如果是的话说明当前线程已经拥有了这个锁对象，那就可以直接进入同步块继续执行，否则说明这个锁对象已经被其他线程线程抢占了。如果有两条以上的线程争用同一个锁，那轻量级锁就不再有效，要膨胀为重量级锁。
偏向锁（Biased Lock）
背景
偏向锁也是 JDK 1.6 中引入的一项锁优化，它的目的是消除数据在无竞争情况下的同步原语，进一步提高程序的运行性能。
这种优化基于这样的观测结果（Observation）：大多数锁并没有被争用（Contented），并且这些锁在其整个生命周期内至多只会被一个线程持有。
如果说轻量级锁是在无竞争的情况下使用 CAS 操作去消除同步使用的互斥量，那偏向锁就是在无竞争的情况下把整个同步都消除掉，连 CAS 操作都不做了。
偏向锁（Biased Lock）
偏向锁的“偏”，就是偏心的“偏”、偏袒的“偏”。它的意思是这个锁会偏向于第一个获得它的线程，如果在接下来的执行过程中，该锁没有被其他的线程获取，则持有偏向锁的线程将永远不需要再进行同步。
因为，Java 虚拟机在实现 monitorenter 字节码（申请锁）和 monitorexit 字节码（释放锁）时，需要借助一个原子操作（CAS操作），这个操作代价相对来说比较昂贵。
因此，Java 虚拟机会为每个对象维护一个偏好（Bias），即一个对象对应的内部锁第 1 次被一个线程获得，那么这个线程就会被记录为该对象的偏好线程（Biased Thread）。
这个线程后续无论是再次申请该锁还是释放该锁，都无须借助原先（指未实施偏向锁优化前）昂贵的原子操作，从而减少了锁的申请与释放的开销。
然而，一个锁没有被争用并不代表仅仅只有一个线程访问该锁，当一个对象的偏好线程以外的其他线程申请该对象的内部锁时，Java 虚拟机需要收回（Revoke）该对象对原偏好线程的“偏好”并重新设置该对象的偏好线程。这个偏好收回和重新分配过程的代价也是比较昂贵的，因此如果程序运行过程中存在比较多的锁争用的情况，那么这种偏好收回和重新分配的代价便会被放大。有鉴于此，偏向锁优化只适合于存在相当大一部分锁并没有被争用的系统之中。如果系统中存在大量被争用的锁而没有被争用的锁仅占极小的部分，那么我们可以考虑关闭偏向锁优化。
假设当前虚拟机启用了偏向锁（启用参数-XX:+UseBiasedLocking，这是JDK 1.6的默认值），那么，当锁对象第一次被线程获取的时候，虚拟机将会把对象头中的标志位设为“01”，即偏向模式。同时使用 CAS 操作把获取到这个锁的线程的ID记录在对象的 Mark Word 之中，如果CAS操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机都可以不再进行任何同步操作（例如Locking、Unlocking及对Mark Word的Update等）。
当有另外一个线程去尝试获取这个锁时，偏向模式就宣告结束。根据锁对象目前是否处于被锁定的状态，撤销偏向（Revoke Bias）后恢复到未锁定（标志位为“01”）或轻量级锁定（标志位为“00”）的状态，后续的同步操作就如上面介绍的轻量级锁那样执行。
偏向锁可以提高带有同步但无竞争的程序性能。它同样是一个带有效益权衡（Trade Off）性质的优化，也就是说它并不一定总是对程序运行有利，如果程序中大多数的锁都总是被多个不同的线程访问，那偏向模式就是多余的。在具体问题具体分析的前提下，有时候使用参数-XX:-UseBiasedLocking来禁止偏向锁优化反而可以提升性能。
适应性自旋锁（Adaptive Spinning Lock）
**适应性自旋（ Adaptive Spinning ）**是 JIT 编译器对内部锁实现所做的一种优化。
自旋锁的自适应（Adaptive）性
所谓自适应（Adaptive）就意味着自旋的次数不再是固定的，它是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。
它具体怎么做呢？线程如果自旋成功了，那么下次自旋的次数会更加多。
因为虚拟机认为既然上次成功了，那么此次自旋也很有可能会再次成功，那么它就会允许自旋等待持续的次数更多。
反之，如果对于某个锁，很少有自旋能够成功的，那么在以后要或者这个锁的时候自旋的次数会减少甚至省略掉自旋过程，以免浪费处理器资源。
有了自适应自旋锁，随着程序运行和性能监控信息的不断完善，虚拟机对程序锁的状况预测会越来越准确，虚拟机会变得越来越聪明。
Reference
- 《深入理解Java虚拟机》
- Java多线程编程那些事：Java虚拟机对内部锁的优化 - https://zhuanlan.zhihu.com/p/30003980
- 【深入理解多线程】Java虚拟机的锁优化技术（五） - https://blog.csdn.net/w372426096/article/details/80079605
- Java 并发：深入分析 synchronized 的实现原理 - https://juejin.im/entry/58a702b9128fe1006cb91707