JDK锁优化
在 JVM 中 monitorenter 和 monitorexit 字节码依赖于底层的操作系统的Mutex Lock 来实现的，但是由于使用 Mutex Lock 需要将当前线程挂起并从用户态切换到内核态来执行，这种切换的代价是非常昂贵的。然而，在现实中的大部分情况下，同步方法是运行在单线程环境（无锁竞争环境），如果每次都调用 Mutex Lock 那么将严重的影响程序的性能。
因此，JDK 1.6 对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。
- 锁粗化（Lock Coarsening）
- 锁消除（Lock Elimination）
- 轻量级锁（Lightweight Locking）
- 偏向锁（Biased Locking）
- 适应性自旋（Adaptive Spinning）
自旋锁
由来
线程的阻塞和唤醒，需要 CPU 从用户态转为核心态。频繁的阻塞和唤醒对 CPU 来说是一件负担很重的工作，势必会给系统的并发性能带来很大的压力。同时，我们发现在许多应用上面，对象锁的锁状态只会持续很短一段时间。为了这一段很短的时间，频繁地阻塞和唤醒线程是非常不值得的。所以引入自旋锁。
定义
所谓自旋锁，就是让该线程等待一段时间，不会被立即挂起，看持有锁的线程是否会很快释放锁。
怎么等待呢？执行一段无意义的循环即可（自旋）。
自旋等待不能替代阻塞，先不说对处理器数量的要求（多核，貌似现在没有单核的处理器了），虽然它可以避免线程切换带来的开销，但是它占用了处理器的时间。如果持有锁的线程很快就释放了锁，那么自旋的效率就非常好，反之，自旋的线程就会白白消耗掉处理的资源，它不会做任何有意义的工作，典型的占着茅坑不拉屎，这样反而会带来性能上的浪费。
所以说，自旋等待的时间（自旋的次数）必须要有一个限度，如果自旋超过了定义的时间仍然没有获取到锁，则应该被挂起。
自旋锁在 JDK 1.4.2 中引入，默认关闭，但是可以使用 -XX:+UseSpinning 开开启。
在 JDK1.6 中默认开启。同时自旋的默认次数为 10 次，可以通过参数 -XX:PreBlockSpin 来调整。
如果通过参数 -XX:PreBlockSpin 来调整自旋锁的自旋次数，会带来诸多不便。假如我将参数调整为 10 ，但是系统很多线程都是等你刚刚退出的时候，就释放了锁（假如你多自旋一两次就可以获取锁），你是不是很尴尬。于是 JDK 1.6 引入自适应的自旋锁，让虚拟机会变得越来越聪明。
适应自旋锁
JDK 1.6 引入了更加聪明的自旋锁，即自适应自旋锁。
所谓自适应就意味着自旋的次数不再是固定的，它是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。它怎么做呢？
- 线程如果自旋成功了，那么下次自旋的次数会更加多，因为虚拟机认为既然上次成功了，那么此次自旋也很有可能会再次成功，那么它就会允许自旋等待持续的次数更多。
- 反之，如果对于某个锁，很少有自旋能够成功的，那么在以后要或者这个锁的时候自旋的次数会减少甚至省略掉自旋过程，以免浪费处理器资源。
锁消除
由来
为了保证数据的完整性，我们在进行操作时需要对这部分操作进行同步控制。但是，在有些情况下，JVM检测到不可能存在共享数据竞争，这是JVM会对这些同步锁进行锁消除。如果不存在竞争，为什么还需要加锁呢？所以锁消除可以节省毫无意义的请求锁的时间。
定义
锁消除的依据是逃逸分析的数据支持。变量是否逃逸，对于虚拟机来说需要使用数据流分析来确定，但是对于我们程序员来说这还不清楚么？我们会在明明知道不存在数据竞争的代码块前加上同步吗？但是有时候程序并不是我们所想的那样？我们虽然没有显示使用锁，但是我们在使用一些 JDK 的内置 API 时，如 StringBuffer、Vector、HashTable 等，这个时候会存在隐性的加锁操作。比如 StringBuffer 的 #append(..)方法，Vector 的 add(…) 方法：
1
2
3
4
5
6
7
public void vectorTest(){
Vector<String> vector = new Vector<String>();
for (int i = 0 ; i < 10 ; i++){
vector.add(i + "");
}
System.out.println(vector);
}
在运行这段代码时，JVM 可以明显检测到变量 vector 没有逃逸出方法 #vectorTest() 之外，所以 JVM 可以大胆地将 vector 内部的加锁操作消除。
锁粗化
由来
我们知道在使用同步锁的时候，需要让同步块的作用范围尽可能小：仅在共享数据的实际作用域中才进行同步。这样做的目的，是为了使需要同步的操作数量尽可能缩小，如果存在锁竞争，那么等待锁的线程也能尽快拿到锁。
在大多数的情况下，上述观点是正确的，但是如果一系列的连续加锁解锁操作，可能会导致不必要的性能损耗，所以引入锁粗化的概念。
定义
锁粗化概念比较好理解，就是将多个连续的加锁、解锁操作连接在一起，扩展成一个范围更大的锁。
如上面实例：vector 每次 add 的时候都需要加锁操作，JVM 检测到对同一个对象（vector）连续加锁、解锁操作，会合并一个更大范围的加锁、解锁操作，即加锁解锁操作会移到 for 循环之外。
锁的升级
锁主要存在四种状态，依次是：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态。它们会随着竞争的激烈而逐渐升级。注意，锁可以升级不可降级，这种策略是为了提高获得锁和释放锁的效率。 偏向锁、轻量级锁、重量级锁三者各自的应用场景：
- 偏向锁：只有一个线程进入临界区；
- 轻量级锁：多个线程交替进入临界区；
- 重量级锁：多个线程同时进入临界区。
无锁状态
偏向锁
偏向锁（Biased Locking）：JDK1.6引入。目的是消除数据在无竞争情况下的同步原语，使用CAS记录获取它的线程，下一次同一个线程进入则偏向该线程，无需任何同步操作。 引入偏向锁主要目的是：为了在无多线程竞争的情况下，尽量减少不必要的轻量级锁执行路径。 只需要检查是否为偏向锁、锁标识为以及 ThreadID 即可。 简单的讲，就是在锁对象的对象头Mark Word中有个ThreaddId字段，这个字段如果是空的，第一次获取锁的时候，就将自身的ThreadId写入到锁的ThreadId字段内，将锁头内的是否偏向锁的状态位置1.这样下次获取锁的时候，直接检查ThreadId是否和自身线程Id一致，如果一致，则认为当前线程已经获取了锁，因此不需再次获取锁，略过了轻量级锁和重量级锁的加锁阶段。
偏向锁竞争过程
轻量级锁
轻量级锁（Lightweight Locking）：JDK1.6引入。在没有多线程竞争的情况下避免重量级互斥锁，只需要依靠一条CAS原子指令就可以完成锁的获取及释放。
轻量级加锁过程
- 线程A和线程B都在栈中开辟一块
LockRecord空间； - 线程A和线程B都把锁对象复制一份到自己的
LockRecord空间中，并且开辟一块owner空间留作执行锁使用； - 锁对象的前62bit位合并，等待线程A和线程B来修改指向自己的线程，假如线程A修改成功，则锁对象头的前62bit位会存线程A的
LockRecord的内存地址，并且线程A的owner也会存一份锁对象的内存地址，形成一个双向指向的形式； - 线程B修改失败，则进入一个自旋状态，就是持续来修改锁对象。
轻量级锁解锁
1.遍历线程栈,找到所有obj字段等于当前锁对象的Lock Record；
2.如果Lock Record的Displaced Mark Word为null，代表这是一次重入，将obj设置为null后continue；
3.如果Lock Record的Displaced Mark Word不为null，则利用CAS指令将对象头的mark word恢复成为Displaced Mark Word。如果成功，则continue，否则膨胀为重量级锁。
重量级锁
重量级锁通过对象内部的监视器（Monitor）实现，其中，Monitor 的本质是，依赖于底层操作系统的 Mutex Lock 实现。操作系统实现线程之间的切换，需要从用户态到内核态的切换，切换成本非常高。
重量级锁过程
- 线程B多次自旋以后还是没有拿到锁，会告知虚拟机，这时线程B会由用户态切换到内核态，申请一个互斥量，JVM会将锁对象的前62bit指向互斥量地址，并且线程B进入睡眠状态；
- 线程A继续运行知道完成时，当线程A要释放锁资源时，发现原来锁的前62bit位并不是指向自己了，这时线程A释放锁，并且去唤醒那些处于睡眠状态的线程，锁升级到重量级锁；
【死磕 Java 并发】—– synchronized 的锁膨胀过程
