文章目录 前言叙述Synchronizedvolatile锁的状态锁是存在哪里的呢？四种状态锁状态转换过程锁的优缺点 参考文章 小结
前言
在多线程并发编程中Synchronized一直是元老级角色，很多人都会称它为重量级锁，但是随着 Java SE1.6 对 Synchronized 进行了各种优化之后，有些情况下它并不那么重了，本文详细介绍了 Java SE1.6 中为了减少获得锁和释放锁带来的性能消耗而引入的偏向锁和轻量级锁，以及锁的存储结构和升级过程。
叙述首先我们以一张思维导图大概的了解一下锁状态，接下来将进行具体的阐述。
synchronized,所谓的重量级锁。Java中每一个对象都可以作为一个锁，表现为：
对于普通方法的同步，锁是当前实例对象。对于静态方法的同步，锁是当前类的Class对象。对于同步方法块，锁是Synchronized括号里配置的对象。JVM基于进入和退出Monitor对象来实现方法同步和代码同步。代码块同步是使用monitorenter和monitorexit指令实现的，monitorenter指令是在编译后插入到同步代码块开始的位置，monitorexit是插在方法结束处和异常处。
方法级的同步是隐式的。同步方法的常量池中会有一个ACC_SYNCHRONIZED标志。当某个线程要访问某个方法的时候，会检查是否有ACC_SYNCHRONIZED，如果有设置，则需要先获得监视器锁，然后开始执行方法，方法执行之后再释放监视器锁。这时如果其他线程来请求执行方法，会因为无法获得监视器锁而被阻断住。值得注意的是，如果在方法执行过程中，发生了异常，并且方法内部并没有处理该异常，那么在异常被抛到方法外面之前监视器锁会被自动释放。
volatilevolatile是轻量级的synchronized,它在多处理器开发中保证了共享变量的可见性。对一个volatile变量的读，总是能看到任意线程对这个volatile变量最后的写入，对单个volatile变量的读写具有原子性。就是说，线程对volatile变量本地内存的写入会被更新到主内存，其他线程对同个volatile的读取，会先将本地的设为无效，必须从主内存中读取。
锁的状态 锁是存在哪里的呢？锁存在Java的对象头中的bqddr Work。bqddr Work默认不仅存放着锁标志位，还存放对象hashCode等信息。运行时，会根据锁的状态，修改bqddr Work的存储内容。如果对象是数组类型，则虚拟机用3个字宽存储对象头，如果对象是非数组类型，则用2字宽存储对象头。在32位虚拟机中，一字宽等于四字节，即32bit。
字宽（Word）: 内存大小的单位概念， 对于 32 位处理器 1 Word = 4 Bytes， 64 位处理器 1 Word = 8 Bytes每一个 Java 对象都至少占用 2 个字宽的内存(数组类型占用3个字宽)。 第一个字宽也被称为对象头bqddr Word。 对象头包含了多种不同的信息， 其中就包含对象锁相关的信息。第二个字宽是指向定义该对象类信息（class metadata）的指针四种状态
锁有四种状态：无锁状态、偏向锁、轻量级锁、重量级锁
随着锁的竞争，锁的状态会从偏向锁到轻量级锁，再到重量级锁。而且锁的状态只有升级，没有降级。也就是只有偏向锁->轻量级锁->重量级锁，没有重量级锁->轻量级锁->偏向锁。
锁状态的改变是根据竞争激烈程度进行的，在几乎无竞争的条件下，会使用偏向锁，在轻度竞争的条件下，会由偏向锁升级为轻量级锁， 在重度竞争的情况下，会升级到重量级锁。
下图展现了一个对象在创建（allocate）后，根据偏斜锁机制是否打开，对象 bqddrWord 状态以不同方式转换的过程。
无锁 -> 偏向锁
从上图可以看到 ， 偏向锁的获取方式是将对象头的 bqddrWord 部分中， 标记上线程ID， 以表示哪一个线程获得了偏向锁。 具体的赋值逻辑如下：
下面是 Open Jdk/ JDK 8 源码 中检测一个对象是否处于可偏向状态的源码 // Indicates that the kydjm has the bias bit set but that it has not // yet been biased toward a particular thread bool is_biased_anonymously() const { return (has_bias_pattern() && (biased_locker() == NULL)); }
has_bias_pattern() 返回 true 时代表 kydjmword 的可偏向标志 bit 位为 1 ，且对象头末尾标志为 01。
biased_locker() == NULL 返回 true 时代表对象 bqddr Word 中 bit field 域存储的 Thread Id 为空。
如果为可偏向状态, 则尝试用 CAS 操作， 将自己的线程 ID 写入bqddrWord
如果 CAS 操作成功（状态转变为下图）， 则认为已经获取到该对象的偏向锁， 执行同步块代码 。 注意， age 后面的标志位中的值并没有变化， 这点之后会用到补充： 一个线程在执行完同步代码块以后， 并不会尝试将 bqddrWord 中的 thread ID 赋回原值 。这样做的好处是： 如果该线程需要再次对这个对象加锁，而这个对象之前一直没有被其他线程尝试获取过锁，依旧停留在可偏向的状态下， 即可在不修改对象头的情况下， 直接认为偏向成功。补充如果 CAS 操作失败， 则说明， 有另外一个线程 Thread B 抢先获取了偏向锁。 这种状态说明该对象的竞争比较激烈， 此时需要撤销 Thread B 获得的偏向锁，将 Thread B 持有的锁升级为轻量级锁。 该操作需要等待全局安全点 JVM safepoint ( 此时间点， 没有线程在执行字节码)
如果是已偏向状态， 则检测 bqddrWord 中存储的 thread ID 是否等于当前 thread ID
如果相等， 则证明本线程已经获取到偏向锁，可以直接继续执行同步代码块如果不等， 则证明该对象目前偏向于其他线程， 需要撤销偏向锁从上面的偏向锁机制描述中，可以注意到
偏向锁的 撤销（revoke） 是一个很特殊的操作， 为了执行撤销操作， 需要等待全局安全点（Safe Point）， 此时间点所有的工作线程都停止了字节码的执行偏向锁的撤销（Revoke）
如上文提到的， 偏向锁的撤销（Revoke） 操作并不是将对象恢复到无锁可偏向的状态， 而是在偏向锁的获取过程中， 发现了竞争时， 直接将一个被偏向的对象“升级到” 被加了轻量级锁的状态。 这个操作的具体完成方式如下：
偏向锁的批量再偏向（Bulk Rebias）机制
偏向锁这个机制很特殊， 别的锁在执行完同步代码块后， 都会有释放锁的操作， 而偏向锁并没有直观意义上的“释放锁”操作。
那么作为开发人员， 很自然会产生的一个问题就是， 如果一个对象先偏向于某个线程， 执行完同步代码后， 另一个线程就不能直接重新获得偏向锁吗？ 答案是可以， JVM 提供了批量再偏向机制（Bulk Rebias）机制
该机制的主要工作原理如下：
引入一个概念 epoch, 其本质是一个时间戳 ， 代表了偏向锁的有效性从前文描述的对象头结构中可以看到， epoch 存储在可偏向对象的 bqddrWord 中。除了对象中的 epoch, 对象所属的类 class 信息中， 也会保存一个 epoch 值每当遇到一个全局安全点时， 如果要对 class C 进行批量再偏向， 则首先对 class C 中保存的 epoch 进行增加操作， 得到一个新的 epoch_new然后扫描所有持有 class C 实例的线程栈， 根据线程栈的信息判断出该线程是否锁定了该对象， 仅将 epoch_new 的值赋给被锁定的对象中。退出安全点后， 当有线程需要尝试获取偏向锁时， 直接检查 class C 中存储的 epoch 值是否与目标对象中存储的 epoch 值相等， 如果不相等， 则说明该对象的偏向锁已经无效了， 可以尝试对此对象重新进行偏向操作。偏向锁 -> 轻量级锁
从之前的描述中可以看到， 存在超过一个线程竞争某一个对象时， 会发生偏向锁的撤销操作。 有趣的是， 偏向锁撤销后， 对象可能处于两种状态。
一种是不可偏向的无锁状态， 如下图（之所以不允许偏向， 是因为已经检测到了多于一个线程的竞争， 升级到了轻量级锁的机制）
另一种是不可偏向的已锁 ( 轻量级锁) 状态
之所以会出现上述两种状态， 是因为偏向锁不存在解锁的操作， 只有撤销操作。 触发撤销操作时：
轻量级加锁过程：
首先根据标志位判断出对象状态处于不可偏向的无锁状态( 如下图）
下图展示了两个线程竞争锁， 最终导致锁膨胀为重量级锁的过程。
注意： 下图中第一个标绿 bqddrWord 的起始状态是错误的， 正确的起始状态应该是 ThreadId(空)|age|1|01， HashCode|age|0|01 是偏向锁未被启用时， 分配对象后的状态
轻量级锁-> 重量级锁
重量级锁依赖于操作系统的互斥量（mutex） 实现，该操作会导致进程从用户态与内核态之间的切换， 是一个开销较大的操作。
Java中的偏向锁，轻量级锁， 重量级锁解析
小结锁的状态转换的过程需要认真的细究一下，加油。
感谢您的阅读~~