JVM中的锁优化

锁优化

Jvm 在加锁的过程中，会采用自旋、自适应、锁消除、锁粗化等优化手段来提升代码执行效率。

什么是锁升级，降级？

锁的4中状态：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态（级别从低到高）。
所谓的锁升级、降级，就是 JVM 优化 synchronized 运行的机制，当 JVM 监测到不同的竞争状况是，会自动切换到不同的锁实现。这种切换就是锁的升级、降级。

锁升级

偏向锁

因为经过大量的研究发现，大多数时候是不存在锁竞争的，常常是一个线程多次获得同一个锁，因此如果每次都要竞争锁会增大很多没有必要付出的代价，为了降低获取锁的代价，才引入的偏向锁。

在程序的一开始，处于无锁状态。紧接着，有一个线程申请锁，此时通过CAS竞争锁（CAS保证了此竞争行为的原子性），获取锁成功，Mark Word 将标记为偏向锁。当同样的线程再次到来，发现是锁的持有者并且是偏向锁，直接进入临界区。
因此，偏向锁意味着，不会发生竞争条件，因为只有一个线程。

轻量级锁

随着程序的运行，有新的线程要进入临界区，通过CAS竞争锁失败。Mark Word立即将偏向锁标记锁为轻量级锁，因为已经发生了竞争条件。紧接着，会反复同通过CAS为线程获取锁，如果占有锁的线程在临界区待的时间很短，那么申请锁的线程将很快拿到锁。
因此，轻量级锁意味着，有竞争条件，但是大家能很快地被分配到锁。

重量级锁

当然，申请锁的线程并不总是能很快地获取到锁，与其反复地CAS重试而浪费CPU时间，不如直接将线程阻塞住。那么，在轻量级锁的情况下，如果有线程超过一定次数的重试还是获取不到锁，Mark Word立即将轻量级锁标记为重量级锁，此后所有获取不到锁的线程将被阻塞，需要Monitor的参与。

因此，重量级锁意味着，在有竞争条件的情况下，线程不能很快地被分配到锁。

Synchronized的锁只能膨胀，不能收缩。偏向锁和轻量锁为乐观锁，重量级锁为悲观锁。

Synchronized的好处在于，它的优化、锁申请释放、锁的分配都是自动的，开发者能快速地使用。

轻量级锁什么时候升级为重量级锁？

线程1获取轻量级锁时会先把锁对象的对象头MarkWord复制一份到线程1的栈帧中创建的用于存储锁记录的空间（称为DisplacedMarkWord），然后使用CAS把对象头中的内容替换为线程1存储的锁记录（DisplacedMarkWord）的地址；

如果在线程1复制对象头的同时（在线程1CAS之前），线程2也准备获取锁，复制了对象头到线程2的锁记录空间中，但是在线程2CAS的时候，发现线程1已经把对象头换了，线程2的CAS失败，那么线程2就尝试使用自旋锁来等待线程1释放锁。

但是如果自旋的时间太长也不行，因为自旋是要消耗CPU的，因此自旋的次数是有限制的，比如10次或者100次，如果自旋次数到了线程1还没有释放锁，或者线程1还在执行，线程2还在自旋等待，这时又有一个线程3过来竞争这个锁对象，那么这个时候轻量级锁就会膨胀为重量级锁。重量级锁把除了拥有锁的线程都阻塞，防止CPU空转。

锁膨胀

当轻量级锁失败，虚拟机就会使用重量级锁。使用重量级锁时，对象的Mark Word中的末尾的2位会被设置为'10'。整个Mark Word表示指向monitor对象的指针。

JVM对锁的优化

1.自旋锁

在没有加入锁优化时，Synchronized是一个非常“胖大”的家伙。在多线程竞争锁时，当一个线程获取锁时，它会阻塞所有正在竞争的线程，这样对性能带来了极大的影响。在挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作对系统的并发性能带来了很大的压力。同时HotSpot团队注意到在很多情况下，共享数据的锁定状态只会持续很短的一段时间，为了这段时间去挂起和回复阻塞线程并不值得。在如今多处理器环境下，完全可以让另一个没有获取到锁的线程在门外等待一会(自旋)，但不放弃CPU的执行时间。等待持有锁的线程是否很快就会释放锁。为了让线程等待，我们只需要让线程执行一个忙循环(自旋)，这便是自旋锁由来的原因。