java中锁在宏观中可以分为乐观锁、悲观锁，在实现上有偏向锁、轻量级锁、自旋锁、重量级锁等，其中涉及到锁升级，本文对以上四种锁及其实现原理做浅显介绍。

乐观锁与悲观锁

乐观锁：乐观锁认为读多写少，遇到并发写的可能性低，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，采取在写时先读出当前版本号，然后加锁操作（比较跟上一次的版本号，如果一样则更新），如果失败就重复，读-比较-写的操作。Java中的乐观锁基本都是通过CAS操作实现的，CAS是一种原子性的更新操作，比较当前值跟传入值是否一样，一样则更新，否则失败。

悲观所：悲观所就是悲观思想，即认为写多于读，遇到并发写的可能性很高，每次去拿数据的时候都认为别人会修改，所以每次在读写数据的时候都会上锁，这样别人向读写这个数据久会block直到拿到锁。而synchronized就是其中的代表。

java对象头

java对象头是实现synchronized的锁对象的基础，synchronized使用的锁对象是存储在Java对象头里的。

对象头包含两部分：

• Mark Word：存储对象hashcode、锁信息、分代年龄、GC信息等
• Class Metadata Address：类型指针指向类的类元数据，jvm通过类原数据来确定类的实例

其中Mark Word在默认情况下存储结构如下图

由于对象头的信息是与对象自身定义的数据没有关系的额外存储成本，因此考虑到JVM的空间效率，Mark Word 被设计成为一个非固定的数据结构，以便存储更多有效的数据，它会根据对象本身的状态复用自己的存储空间，如32位JVM下，除了上述列出的Mark Word默认存储结构外，还有如下可能变化的结构：

偏向锁

偏向锁是JDK6中引入的一项锁优化，它的目的是消除数据在无竞争情况下的同步原语，进一步提高程序的运行性能。

偏向锁会偏向于第一个获得它的线程，如果在接下来的执行过程中，该锁没有被其他的线程获取，则持有偏向锁的线程将永远不需要同步。大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁。

• 当锁对象第一次被线程获取的时候，线程使用CAS操作把这个线程的ID记录在对象Mark Word之中，同时置偏向标志位01。
• 以后该线程再进入和退出同步块时不需要进行CAS操作来加锁和解锁，只需要简单地测试一下对象头的Mark Word里是否存储着指向当前线程的ID。如果测试成功，表示线程已经获得了锁。
• 当有另外一个线程去尝试获取这个锁时，偏向模式就宣告结束。根据锁对象目前是否处于被锁定的状态，撤销偏向后恢复到未锁定或轻量级锁定状态。

轻量级锁

轻量级锁提升程序同步性能的依据是：对于绝大部分的锁，在整个同步周期内都是不存在竞争的（区别于偏向锁）。这是一个经验数据。如果没有竞争，轻量级锁使用CAS操作避免了使用互斥量的开销，但如果存在锁竞争，除了互斥量的开销外，还额外发生了CAS操作，因此在有竞争的情况下，轻量级锁比传统的重量级锁更慢。

轻量级锁加锁过程

• 在代码进入同步块的时候，如果同步对象锁状态为无锁状态（锁标志位为“01”状态，是否为偏向锁为“0”）
• 当前线程栈帧中创建Local Record空间
• 拷贝对象头中的Mark Word复制到锁记录（Lock Record）中
• 虚拟机使用CAS操作尝试将锁对象的Mark Word更新为指向Lock Record的指针，并将线程栈帧中的Lock Record里的owner指针指向Object的 Mark Word。
• 如果CAS成功则线程获得该对象的锁，并且对象Mark Word的锁标志位设置为“00”

• 如果CAS失败则检查对象的Mark Word是否指向当前线程的栈帧，如果是就说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行。否则说明多个线程竞争锁，轻量级锁就要膨胀为重量级锁，锁标志的状态值变为“10”，Mark Word中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也要进入阻塞状态。

自旋锁与自适应自旋锁

Java的线程是映射到操作系统的原生线程之上的，如果要阻塞或唤醒一个线程，都需要操作系统来帮忙完成，这就需要从用户态转换到核心态中，因此状态转换需要耗费很多的处理器时间，对于代码简单的同步块（如被synchronized修饰的getter()和setter()方法），状态转换消耗的时间有可能比用户代码执行的时间还要长。

虚拟机的开发团队注意到在许多应用上，共享数据的锁定状态只会持续很短的一段时间，为了这段时间去挂起和恢复线程并不值得。如果物理机器有一个以上的处理器，能让两个或以上的线程同时并行执行，我们就可以让后面请求锁的那个线程“稍等一下“，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁。为了让线程等待，我们只需让线程执行一个忙循环（自旋），这项技术就是所谓的自旋锁。

自旋锁在JDK1.4.2中引入，使用-XX:+UseSpinning来开启。JDK1.6中已经变为默认开。自旋等待不能代替阻塞。自旋等待本身虽然避免了线程切换的开销，但它是要占用处理器时间的，因此，如果锁被占用的时间很短，自旋等待的效果就会非常好，反之，如果锁被占用的时间很长，那么自旋的线程只会浪费处理器资源。因此，自旋等待的时间必须要有一定的限度，如果自旋超过了限定次数（默认是10次，可以使用-XX:PreBlockSpin来更改）没有成功获得锁，就应当使用传统的方式去挂起线程了。

JDK1.6中引入自适应的自旋锁，自适应意味着自旋的时间不在固定。而是有虚拟机对程序锁的监控与预测来设置自旋的次数。

自旋是在轻量级锁中使用的

重量级锁

重量级锁也就是通常说synchronized的对象锁，锁标识位为10，其中指针指向的是monitor对象（也称为管程或监视器锁）的起始地址。

每个对象都存在着一个 monitor 与之关联，对象与其 monitor 之间的关系有存在多种实现方式，如monitor可以与对象一起创建销毁或当线程试图获取对象锁时自动生成，但当一个 monitor 被某个线程持有后，它便处于锁定状态。

• 当多个线程同时访问一段同步代码时，首先会进入 Entry Set
• 当线程获取到对象的monitor 后进入 The Owner 区域并把monitor中的owner变量设置为当前线程，同时monitor中的计数器count加1
• 若线程调用 wait() 方法，将释放当前持有的monitor，owner变量恢复为null，count自减1，同时该线程进入 WaitSet集合中等待被唤醒
• 若当前线程执行完毕也将释放monitor(锁)并复位变量的值，以便其他线程进入获取monitor(锁)。

由此看来，monitor对象存在于每个Java对象的对象头中(存储的指针的指向)，synchronized锁便是通过这种方式获取锁的，也是为什么Java中任意对象可以作为锁的原因，同时也是notify/notifyAll/wait等方法存在于顶级对象Object中的原因。

锁升级

锁可以升级但不可以降级，具体过程如下：

• 对象实例化后遇到第一个访问线程，则偏向第一个访问线程并设定偏向锁，CAS操作修改对象头偏向锁标记为01，对象头中ThreadID改成自己的ID，之后再次访问这个对象时，只需要对比ID，不需要再使用CAS在进行操作。
• 当有第二个线程访问该对象，检查偏向锁指向线程是否存活
• 如果未存活则第二个线程获取偏向锁
• 如果存活则马上执行那个线程的操作栈，检查该对象的使用情况，如果仍然需要持有偏向锁，则偏向锁升级为轻量级锁
• 如果不存在使用了，则可以将对象回复成无锁状态，然后重新偏向
• 轻量级锁认为竞争存在，但是竞争的程度很轻，一般两个线程对于同一个锁的操作都会错开，或者说稍微等待一下（自旋），另一个线程就会释放锁
• 当自旋超过一定的次数，或者一个线程在持有锁，一个在自旋，又有第三个来访时，轻量级锁膨胀为重量级锁，重量级锁使除了拥有锁的线程以外的线程都阻塞，防止CPU空转。

参考资料：

[1]https://www.cnblogs.com/deltadeblog/p/9559035.html

版权声明：本文为博主原创文章，欢迎转载，转载请注明作者、原文超链接，感谢各位看官!!!

本文出自：monkeyGeek

座右铭：生于忧患，死于安乐

欢迎志同道合的朋友一起交流、探讨！

monkeyGeek