一篇文章说清 ：无锁、偏向锁、轻量级锁、重量级锁

前言

JDK1.6为了减少获得锁和释放锁所带来的性能消耗，引入了“偏向锁”和“轻量级锁”，所以在JDK1.6里锁一共有四种状态，无锁状态，偏向锁状态，轻量级锁状态和重量级锁状态，它会随着竞争情况逐渐升级。锁可以升级但不能降级，意味着偏向锁升级成轻量级锁后不能降级成偏向锁。这种锁升级却不能降级的策略，目的是为了提高获得锁和释放锁的效率.

Java中的锁有几种状态：无锁 → 偏向锁 → 轻量级锁 → 重量级锁

一、无锁

偏向锁，顾名思义，它会偏向于第一个访问锁的线程

程序不会有锁的竞争。那么这种情况我们不需要加锁，所以这种情况下对象锁状态为无锁。

二、偏向锁

偏向锁，顾名思义，它会偏向于第一个访问锁的线程

• 如果在运行过程中，同步锁只有一个线程访问，不存在多线程争用的情况，则线程是不需要触发同步的，这种情况下，就会给线程加一个偏向锁。线程第二次到达同步代码块时，会判断此时持有锁的线程是否就是自己，如果是则正常往下执行。由于之前没有释放锁，这里也就不需要重新加锁。如果自始至终使用锁的线程只有一个，很明显偏向锁几乎没有额外开销，性能极高。
• 如果在运行过程中，遇到了其他线程抢占锁，则持有偏向锁的线程会被挂起，JVM会消除它身上的偏向锁，将锁恢复到标准的轻量级锁。偏向锁通过消除资源无竞争情况下的同步原语，进一步提高了程序的运行性能。一旦有第二个线程加入锁竞争，偏向锁就升级为轻量级锁（自旋锁）。升级为轻量级锁的时候需要撤销偏向锁，撤销偏向锁的时候会导致STW(stop the word)操作；

锁竞争：如果多个线程轮流获取一个锁，但是每次获取锁的时候都很顺利，没有发生阻塞，那么就不存在锁竞争。只有当某线程尝试获取锁的时候，发现该锁已经被占用，只能等待其释放，这才发生了锁竞争。

三、轻量级锁（自选锁）

自旋锁：自旋锁原理非常简单，如果持有锁的线程能在很短时间内释放锁资源，那么那些等待竞争锁的线程就不需要做内核态和用户态之间的切换进入阻塞挂起状态，它们只需要等一等（自旋），等持有锁的线程释放锁后即可立即获取锁，这样就避免用户线程和内核的切换的消耗。

• 在轻量级锁状态下继续锁竞争，没有抢到锁的线程将自旋，即不停地循环判断锁是否能够被成功获取。长时间的自旋操作是非常消耗资源的，一个线程持有锁，其他线程就只能在原地空耗CPU，执行不了任何有效的任务，这种现象叫做忙等（busy-waiting）。如果锁竞争情况严重，某个达到最大自旋次数的线程，会将轻量级锁升级为重量级锁。

四、重量级锁

• 当后续线程尝试获取锁时，发现被占用的锁是重量级锁，则直接将自己挂起，等待将来被唤醒。在JDK1.6之前，synchronized直接加重量级锁，很明显现在得到了很好的优化。

重量级锁的特点：其他线程试图获取锁时，都会被阻塞，只有持有锁的线程释放锁之后才会唤醒这些线程。

锁升级场景

场景1： 经常只有某一个线程来加锁。

• 加锁过程：也许获取锁的经常为同一个线程，这种情况下为了避免加锁造成的性能开销，加偏向锁。
• 偏向锁的执行流程如下：
  • 1、线程首先检查该对象头的线程ID是否为当前线程；
  • 2、A：如果对象头的线程ID和当前线程ID一直，则直接执行代码；B：如果不是当前线程ID则使用CAS方式替换对象头中的线程ID，如果使用CAS替换不成功则说明有线程正在执行，存在锁的竞争，这时需要撤销偏向锁，升级为轻量级锁。
  • 3、如果CAS替换成功，则把对象头的线程ID改为自己的线程ID，然后执行代码。
  • 4、执行代码完成之后释放锁，把对象头的线程ID修改为空。

场景2： 有线程来参与锁的竞争，但是获取锁的冲突时间很短。

• 当开始有锁的竞争了，那么偏向锁就会升级到轻量级锁；
• 线程获取锁出现冲突时，线程必须做出决定是继续在这里等，还是先去做其他事情，等会再来看看，而轻量级锁的采用了继续在这里等的方式。当发现有锁竞争，线程首先会使用自旋的方式循环在这里获取锁，因为使用自旋的方式非常消耗CPU。当一定时间内通过自旋的方式无法获取到锁的话，那么锁就开始升级为重量级锁了。

场景3： 有大量的线程参与锁的竞争，冲突性很高。

• 当获取锁冲突多，时间越长的时候，线程肯定无法继续在这里死等了，所以只好先挂起，然后等前面获取锁的线程释放了锁之后，再开启下一轮的锁竞争，而这种形式就是我们的重量级锁。