synchronized锁的升级1-偏向锁

在分析这几种锁的区别时，我们先来思考一个问题：
使用锁能够实现数据的安全性，但是会带来性能的下降。
不使用锁能够基于线程并行提升程序性能，但是却不能保证线程的安全性。
这两者之间似乎是没有办法达到既能满足性能也能满足安全性的要求。

hotspot虚拟机作者发现，大部分情况下，加锁的代码不仅不存在多线程竞争，而且总是由同一个线程多次获得。
所以基于这样一个概率，synchronized在JDK1.6之后做了一些优化，为了减少获得锁和释放锁带来的性能开销，
引入了偏向锁、轻量级锁的概念。
因此，在synchronied中，锁存在四种状态，分别是：无锁、偏向锁、轻量级锁、重量级锁；
锁的状态根据竞争的激烈程度由低到高不断升级。

偏向锁的基本原理

前面说过，大部分情况下，锁不仅仅不存在多线程竞争，而且总是由同一个线程多次获得，为了让线程获得锁的代价更低，就
引入了偏向锁的概念。怎么理解偏向锁呢？
当一个线程访问加了同步锁的代码块时，会在对象头中存储当前线程的ID，后续这个线程进入和退出这段加了同步锁的代码块时，
不需要再次加锁和释放锁。而是直接比较对象头里面是否存储了指向当前线程的偏向锁，如果相等，表示偏向锁是偏向于当前线程的，
就不需要再尝试获得锁了。

1.偏向锁的获得和撤销逻辑

1. 首先获取锁对象的MarkWord，判断是否处于可偏向状态。（biased_lock=1、且Threadld为空）
2. 如果是可偏向状态，则通过CAS操作，把当前线程的ID写入到MarkWord

• 如果CAS成功，那么MarkWord就会变成这样。表示已经获得了锁对象的偏向锁，接着执行同步代码块
• 如果CAS失败，说明有其他线程已经获得了偏向锁，这种情况说明当前锁存在竞争，需要撤销已获得偏向锁的线程并且把他持有的锁升级为轻量级锁（这个操作需要等到全局安全点，也就是没有线程在执行字节码才能执行）

3. 如果是已偏向状态，需要检查MarkWord中存储的ThreadID是否等于当前线程的ThreadID

• 如果相等，不需要再次获得锁，可直接执行同步代码块
• 如果不相等，说明当前锁偏向于其他线程，需要撤销偏向锁并把他持有的锁升级到轻量级锁

2.偏向锁的撤销

偏向锁的撤销并不是把对象恢复到无锁可偏向状态（因为偏向锁并不存在释放锁的概念），而是在获取偏向锁的过程中，发现CAS失败也就是存在线程竞争时，
直接把被偏向的锁对象升级到被加了轻量级锁的状态。

对原持有偏向锁的线程进行撤销时，原获得偏向锁的线程有两种情况：

• 原获得偏向锁的线程如果已经退出了临界区，也就是同步代码块执行完了，那么这个时候会把对象头设置成无锁状态并且争抢锁的线程可以基于CAS重新偏向当前线程。
• 如果原获得偏向锁的线程的同步代码块还没有执行完，处于临界区之内，这个时候会把原获得偏向锁的线程升级为轻量级锁后继续执行同步代码块
  在我们的实际开发中，绝大部分情况下一定会存在2个以上的线程竞争，那么如果开启偏向锁，反而会提升获取锁的资源消耗。所以可以通过jvm参数UseBiasedLocking来设置开启或关闭锁。

3.流程图分析