sychronized-基本原理介绍以及锁升级过程详解

sychronized的实现原理与应用

在多线程并发编程中synchronized一直是元老的角色，很多人都会称呼它为重量级锁。但是，随着Java SE 1.6对synchronized进行了各种优化后，有很多特殊情况下它就并不是那个重了。本文详细介绍Java SE 1.6 中为了减少获得锁和释放锁带来的性能消耗而引入的偏向锁和轻量级锁，以及锁的升级过程。

sychronized锁的基础

Java中的每一个对象都可以作为锁。具体可以有以下三种形式

• 1.对于普通的同步方法，锁的是当前实例对象。
• 2.对于静态同步方法，锁是当前的Class对象。
• 3.对于同步方法块，锁是Synchonized括号里配置的对象。

当一个线程识图访问同步代码块时，它首先必须得到锁，退出或者抛出异常的时候必须释放锁。

从JVM规范中可以看到synchronized在JVM里的实现原理。JVM基于进入和退出Monitor对象来实现方法同步和代码块同步，但两者的实现细节不一样。代码块的同步是使用monitorenter和monitorexit指令实现的，而方法的同步使用修饰符上的ACC_SYNCHNIZED完成的。方法的同步同样可以使用这两个指令完成。不管使用哪一种，本质是对一个对象的监视器进行获取，同一个时刻只能有一个线程获取到由synchronized保护对象的监视器。

monitorenter指令是在编译后插入到同步代码块的开始位置，而monitorexit是插入到方法的结束处和异常处。任何对象都有一个monitor与之关联，当且一个monitor被持有后，它将处于锁定状态。线程执行到monitorenter指令时，将会尝试获取对象所对应的monitor所有权，即尝试获取对象的锁。

Java对象头

synchronized用的锁是存在java对象头里的。如果对象是数组类型，则虚拟机用3个字节宽（word）存储对象头，如果是非数组类型，则用2个字节宽存储。32位虚拟机1字宽=4字节=32bit
对象头内容包括MarkWord（32/64bit 存储对象的hashCode或锁信息）、Class Metadata Address(32/64bit 存储对象类型数据的指针)，Array Length(32/32bit 数组长度)

java对象头里的Mark Word里默认存储对象的HashCode、分代年龄和锁标记位。32位JVM的Mark Word可能变化存储为以下5种数据：

Mark Word 状态变化

在64位虚拟机下，Mark Word是64bit大小，其存储结构如下

Mark Word存储结构-64

锁升级对比

Java SE 1.6 为了减少获得锁和释放锁带来的性能消耗，引入了“偏向锁”和“轻量级锁”。锁一共有四种状态：无锁状态、偏向锁、轻量级锁、重量级锁，这个状态随着竞争情况主键升级。锁可以升级但不可以降级。不可逆这是为了提供获得锁和释放锁的效率。

先介绍一下自旋锁

自旋锁

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

• 优化
  自旋锁早在JDK1.4 中就引入了，只是当时默认时关闭的。在JDK 1.6后默认为开启状态。自旋锁本质上与阻塞并不相同，先不考虑其对多处理器的要求，如果锁占用的时间非常的短，那么自旋锁的新能会非常的好，相反，其会带来更多的性能开销（因为在线程自旋时，始终会占用CPU的时间片，如果锁占用的时间太长，那么自旋的线程会白白消耗掉CPU资源）。因此自旋等待的时间必须要有一定的限度，如果自选超过了限定的次数仍然没有成功获取到锁，就应该使用传统的方式去挂起线程了，在JDK定义中，自旋锁默认的自旋次数为10次，用户可以使用参数-XX:PreBlockSpin来更改。

偏向锁

在大多实际环境下，锁不仅不存在多线程竞争，而且总是由同一个线程多次获取，那么在同一个线程反复获取所释放锁中，其中并还没有锁的竞争，那么这样看上去，多次的获取锁和释放锁带来了很多不必要的性能开销和上下文切换。
为了解决这一问题，HotSpot的作者在Java SE 1.6 中对Synchronized进行了优化，引入了偏向锁。当一个线程访问同步快并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID，以后该线程在进入和推出同步块时不需要进行CAS操作来加锁和解锁。只需要简单地测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁。如果成功，表示线程已经获取到了锁。

• 偏向锁的撤销
  偏向锁使用了一种等到竞争出现才释放锁的机制，所以当其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁。偏向锁的撤销需要等待拥有偏向锁的线程到达全局安全点（在这个时间点上没有字节码正在执行），会首先暂停拥有偏向锁的线程，然后检查持有偏向锁的线程是否活着，如果线程不处于活动状态，则将锁的对象的对象头设置成无锁状态，如果线程仍然活着，拥有偏向锁的栈会被执行(判断是否需要持有锁)，遍历偏向对象的锁记录，查看使用情况，如果还需要持有偏向锁，则偏向锁升级为轻量级锁，如果不需要持有偏向锁了，则将锁对象恢复成无锁状态，最后唤醒暂停的线程。

  
  
  偏向锁加锁和撤销流程

轻量级锁

• 加锁
  线程在执行同步块之前，JVM会现在当前线程的栈帧中创建用于存储锁记录的空间，并将对象头中的Mark Word复制到锁记录中，官方称为Disolaced Mard Word。然后线程尝试使用CAS将对象头中的Mark Word替换为指向锁记录的指针。如果成功，当前线程获得锁，如果失败，表示其他线程竞争，当前线程便尝试使用自选来获取锁。

• 解锁
  轻量级解锁时，会使用原子的CAS操作将Displaced Mard Word替换回到对象头，如果成功，则表示没有竞争发生。如果失败，表示当前锁存在竞争，锁就会膨胀成重量级锁。

争夺锁 导致的锁膨胀流程图

锁的优缺点对比

锁的优缺点对比

参考《深入理解JVM》《JAVA并发编程的艺术》