多线程锁的升级原理

synchronized 原理

synchronized 关键字编译后会在同步块的前后添加上 montorenter 和 monitorexit 两个字节码指令，这两个字节码指令都需要一个指向锁定和解锁对象的 reference，如果指定了同步的对象reference就指向这个对象，如果修饰的是方法，如果是类方法就指向Class对象，如果是实例方法就指向这个实例。

对象头和锁

synchronized 使用的锁存在 Java 对象头中。HotSpot 虚拟机的对象头分两部分信息，第一部分用于存储对象自身的运行时数据，如HashCode,GC分代年龄等，这部分数据长度在32位和64位虚拟机中分别为32bit和64bit，它又称为“MarkWord”，它是实现锁的关键。另一部分就是用于存储指向方法区对象类型数据的指针，如果是数组的话，还有一个额外的空间储存数组长度。

对象头是与对象自己数据无关的额外储存成本，因此考虑到空间效率，MarkWord会根据自身的状态进行复用，也就是说在不同的状态下，它的储存结构不一样。在32位的HotSpot虚拟机中对象未锁定的状态下，Mark Word的32bit空间中的25bit用于储存对象的哈希码，4bit用于储存对象分代年龄，2bit用于储存锁标志位，1bit固定为0。

锁升级

没有优化以前，synchronized是重量级锁（悲观锁），使用 wait 和 notify、notifyAll 来切换线程状态非常消耗系统资源；线程的挂起和唤醒间隔很短暂，这样很浪费资源，影响性能。所以 JVM 对 synchronized 关键字进行了优化，把锁分为 无锁、偏向锁、轻量级锁、重量级锁 状态。
锁的级别从低到高依次为：无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁，这几个状态会随着竞争情况逐渐升级。锁可以升级但不能降级。

锁升级的图示过程

1、无锁：

没有对资源进行锁定，所有的线程都能访问并修改同一个资源，但同时只有一个线程能修改成功，其他修改失败的线程会不断重试直到修改成功。

2、偏向锁：

偏向锁的核心思想就是锁会偏向第一个获取它的线程，该线程是不会主动释放偏向锁的，只有当其他线程尝试竞争偏向锁才会被释放。在接下来的执行过程中该锁没有其他的线程获取，则持有偏向锁的线程永远不需要再进行同步。

当一个线程访问同步块并获取锁的时候，会在对象头和栈帧中的锁记录里存储偏向的线程 ID，以后该线程在进入和退出同步块时不需要进行 CAS 操作来加锁和解锁，只需要检查当前 Mark Word 中存储的线程是否为当前线程，如果是，则表示已经获得对象锁；否则，需要测试 Mark Word 中偏向锁的标志是否为1，如果没有则使用 CAS 操作竞争锁，如果设置了，则尝试使用 CAS 将对象头的偏向锁指向当前线程。

偏向锁的撤销，需要在某个时间点上没有字节码正在执行时，先暂停拥有偏向锁的线程，然后检查持有偏向锁的线程是否活着。如果线程不处于活动状态，则将对象头设置成无锁状态，并撤销偏向锁；如果线程处于活动状态，升级为轻量级锁的状态。

3、轻量级锁：

轻量级锁是指当锁是偏向锁的时候，被第二个线程 B 所访问，此时偏向锁就会升级为轻量级锁，线程 B 会通过自旋的形式尝试获取锁，线程不会阻塞，从而提高性能。

当前只有一个等待线程，则该线程将通过自旋进行等待。但是当自旋超过一定的次数时，轻量级锁便会升级为重量级锁；当一个线程已持有锁，另一个线程在自旋，而此时又有第三个线程来访时，轻量级锁也会升级为重量级锁。

4、重量级锁：

指当有一个线程获取锁之后，其余所有等待获取该锁的线程都会处于阻塞状态。

重量级锁将程序运行交出控制权，将线程挂起，由操作系统来负责线程间的调度，负责线程的阻塞和执行。这样会出现频繁地对线程运行状态的切换，线程的挂起和唤醒，消耗大量的系统资源，导致性能低下。

重量级锁通过对象内部的监视器（monitor）实现，而其中 monitor 的本质是依赖于底层操作系统的 Mutex Lock 实现，操作系统实现线程之间的切换需要从用户态切换到内核态，切换成本非常高。

锁状态对比

参考
多线程锁的升级原理是什么?
重学多线程（十）—— synchronized 原理与锁升级