JAVA锁机制（三）

        在上一部分说到了synchronized和monitor的原理，这一部分我们来看一下synchronized的优化和锁四种状态转换。

1、无锁

        顾名思义就是没有对资源进行锁定，所有线程都能访问到同一资源，就有两种情况：

        （1）无竞争：某个对象不会出现在多线程环境下，或者说及时出现再来多线程环境下也不会出现竞争的情况，那么无需对这个对象进行保护，直接给各个线程调用即可；

        （2）存在竞争，非锁方式：资源会被竞争但是我不想对资源进行锁定，但还是想通过一些机制来控制多线程。比如说：如果有多个线程想修改同一个值，我们不通过锁定资源的方式，而是通过其他方式来限制，同时只有一个线程能修改成功，而修改失败的线程会不断重试，直到修改成功，这就是所谓的CAS(Compare And Swap)。CAS在操作系统中通过一条指令来实现，所以保证了原子性。

        通过诸如CAS这种方式，我们可以进行无锁编程，在之前的文档中也分析了依赖操作系统mutex lock导致性能低下的原因。所以在大部分情况下，无锁状态下性能是很高的，但这并非意味着无锁能全面代替有锁，接下来我来介绍一下偏向锁。

2、偏向锁

        假如一个对象被加了锁，但在实际运行时只有一个线程会获取这个对象锁。我们最理想的方式就是不通过线程状态切换，也不要通过CAS来获取锁，因为会耗费资源，我们设想是这个对象能认识这个线程，只要线程过来，那么对象就直接把锁交出来，我们就可以人为这个锁偏爱这个线程，所以被称为偏向锁。

（1）偏向锁的实现：

        假如情况发生了变化，对象发现目前不只有一个线程，而是有多个线程正在竞争锁，那么偏向锁就会升级为轻量级锁。

3、轻量级锁

        当锁的状态还是偏向锁时，是通过Mark Word中的线程ID来找到占有这个锁的线程，那么当锁的状态升级到轻量级锁时，如何判断线程和锁之间的绑定关系呢？

        我们还是看上面那张表，这边已经不再使用线程ID这个字段，而是将前30个bit指向线程栈中锁记录（Lock Record）的指针。当一个线程想要获得某个对象的锁时，假如看到锁标志为00，那么就知道它就是轻量级锁，这是线程会在自己的虚拟机栈中开辟一块被称为Lock Record的空间。虚拟机栈是线程私有的。Lock Record中存放的是对象头中的Mark Word的副本以及owner指针，线程通过CAS去尝试获取锁，一旦获得那么将会复制该对象头中的Mark Word到Lock Record中，并且将Lock Record中的owner指针指向该对象，另一方面对象的Mark Word的前30个bit会生成一个指针，指向线程虚拟机栈中的Lock Record，这样一来就实现了线程和对象锁的绑定。

        这时候万一有其他线程也想要获取这个对象怎么办呢，此时其他线程将会进行自旋等待，那这里就会说到自旋的概念。

自旋，可以理解为一种轮询，线程自己在不断地循环，尝试着去看一下目标对象的锁有没有被释放，如果释放了那么就获取，如果没有释放那么就进行下一轮循环。这种方式区别于被操作系统挂起阻塞，因为如果对象的锁很快就会被释放的话，自旋就不需要进行系统中断和现场恢复，所以自旋效率更高。自旋相当于CPU在空转，如果长时间自旋将会浪费CPU资源，于是出现了一种叫做“适应性自旋”的优化，简单来说就是自旋的时间没有被固定，而是由上一次在同一个锁上的自选时间以及锁状态两个条件来决定。举个例子就好理解了，在同一个锁上，当前正在自旋等待的线程刚刚已经成功获得过锁，但是锁目前是被其他线程占用的，那么虚拟机会认为这一次自旋也有可能会成功，进而会允许更长的自旋时间，这就是适应性自旋。

        假如此时有个线程正在进行自旋，那么这个线程将会进行等待，如果同事又有多个线程想要获得这个对象锁，也就是说一旦自旋等待的线程数超过一个，那么轻量级锁将会升级为重量级锁。

4、重量级锁

        如果升级为重量级锁，那么就会想上一部分说过的，需要通过Monitor来对线程进行控制，此时会完全锁定资源，对线程的管控也最为严格。

大概大家看到这里，就应该会对Java锁机制有个比较大致的理解。请大家持续关注哦！！！