java 中锁的四种状态
[](()前言
============================================================
在多线程并发编程中 Synchronized 一直是元老级角色，很多人都会称它为重量级锁，但是随着 Java SE1.6 对 Synchronized 进行了各种优化之后，有些情况下它并不那么重了，本文详细介绍了 Java SE1.6 中为了减少获得锁和释放锁带来的性能消耗而引入的偏向锁和轻量级锁，以及锁的存储结构和升级过程。
[](()叙述
============================================================
首先我们以一张思维导图大概的了解一下锁状态，接下来将进行具体的阐述。
[](()Synchronized
synchronized,所谓的重量级锁。Java 中每一个对象都可以作为一个锁，表现为：
对于普通方法的同步，锁是当前实例对象。
对于静态方法的同步，锁是当前类的 Class 对象。
对于同步方法块，锁是 Synchronized 括号里配置的对象。
JVM 基于进入和退出 Monitor 对象来实现方法同步和代码同步。代码块同步是使用 monitorenter 和 monitorexit 指令实现的，monitorenter 指令是在编译后插入到同步代码块开始的位置，monitorexit 是插在方法结束处和异常处。
方法级的同步是隐式的。同步方法的常量池中会有一个 ACC_SYNCHRONIZED 标志。当某个线程要访问某个方法的时候，会检查是否有 ACC_SYNCHRONIZED，如果有设置，则需要先获得监视器锁，然后开始执行方法，方法执行之后再释放监视器锁。这时如果其他线程来请求执行方法，会因为无法获得监视器锁而被阻断住。值得注意的是，如果在方法执行过程中，发生了异常，并且方法内部并没有处理该异常，那么在异常被抛到方法外面之前监视器锁会被自动释放。
[](()volatile
volatile 是轻量级的 synchronized,它在多处理器开发中保证了共享变量的可见性。对一个 volatile 变量的读，总是能看到任意线程对这个 volatile 变量最后的写入，对单个 volatile 变量的读写具有原子性。就是说，线程对 volatile 变量本地内存的写入会被更新到主内存，其他线程对同个 volatile 的读取，会先将本地的设为无效，必须从主内存中读取。
[](()锁的状态
[](()锁是存在哪里的呢？
锁存在 Java 的对象头中的 Mark Work。Mark Work 默认不仅存放着锁标志位，还存放对象 hashCode 等信息。运行时，会根据锁的状态，修改 Mark Work 的存储内容。如果对象是数组类型，则虚拟机用 3 个字宽存储对象头，如果对象是非数组类型，则用 2 字宽存储对象头。在 32 位虚拟机中，一字宽等于四字节，即 32bit。
字宽（Word）: 内存大小的单位概念， 对于 32 位处理器 1 Word = 4 Bytes， 64 位处理器 1 Word = 8 Bytes
每一个 Java 对象都至少占用 2 个字宽的内存(数组类型占用 3 个字宽)。
第一个字宽也被称为对象头 Mark Word。 对象头包含了多种不同的信息， 其中就包含对象锁相关的信息。
第二个字宽是指向定义该对象类信息（class metadata）的指针
[](()四种状态
锁有四种状态：无锁状态、偏向锁、轻量级锁、重量级锁
随着锁的竞争，锁的状态会从偏向锁到轻量级锁，再到重量级锁。而且锁的状态只有升级，没有降级。也就是只有偏向锁->轻量级锁->重量级锁，没有重量级锁->轻量级锁->偏向锁。
锁状态的改变是根据竞争激烈程度进行的，在几乎无竞争的条件下，会使用偏向锁，在轻度竞争的条件下，会由偏向锁升级为轻量级锁， 在重度竞争的情况下，会升级到重量级锁。
下图展现了一个对象在创建（allocate）后，根据偏斜锁机制是否打开，对象 MarkWord 状态以不同方式转换的过程。
| 锁名称 | 描述 | 应用场景 |
| --- | --- | --- |
| 偏向锁 | 线程在大多数情况下并不存在竞争条件，使用同步会消耗性能，而偏向锁是对锁的优化，可以消除同步，提升性能。当一个线程获得锁，会将对象头的锁标志位设为 01,进入偏向模式.偏向锁可以在让一个线程一直持有锁，在其他线程需要竞争锁的时候，再释放锁。 | 只有一个线程进入临界区 |
| 轻量级锁 | 当线程 A 获得偏向锁后，线程 B 进入竞争状态，需要获得线程 A 持有的锁，那么线程 A 撤销偏向锁，进入无锁状态。线程 A 和线程 B 交替进入临界区，偏向锁无法满足，膨胀到轻量级锁，锁标志位设为 00。 | 多个线程交替进入临界区 |
| 重量级锁 | 当多线程交替进入临界区，轻量级锁 hold 得住。但如果多个线程同时进入临界区，hold 不住了，膨胀到重量级锁 | 多个线程同时进入临界区 |
[](()锁状态转换过程
无锁 -> 偏向锁
从上图可以看到 ， 偏向锁的获取方式是将对象头的 MarkWord 部分中， 标记上线程 ID， 以表示哪一个线程获得了偏向锁。 具体的赋值逻辑如下：
首先读取目标对象的 MarkWord, 判断是否处于可偏向的状态
下面是 Open Jdk/ JDK 8 源码 中检测一个对象是否处于可偏向状态的源码
// Indicates that the mark 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 时代表 markword 的可偏向标志 bit 位为 1 ，且对象头末尾标志为 01。
biased_locker() == NULL 返回 true 时代表对象 Mark Word 中 bit field 域存储的 Thread Id 为空。
如果为可偏向状态, 则尝试用 CAS 操作， 将自己的线程 ID 写入 MarkWord
如果 CAS 操作成功（状态转变为下图）， 则认为已经获取到该对象的偏向锁， 执行同步块代码 。 注意， age 后面的标志位中的值并没有变化， 这点之后会用到
补充： 一个线程在执行完同步代码块以后， 并不会尝试将 MarkWord 中的 thread ID 赋回原值 。这样做的好处是： 如果该线程需要再次对这个对象加锁，而这个对象之前一直没有被其他线程尝试获取过锁，依旧停留在可偏向的状态下， 即可在不修改对象头的情况下， 直接认为偏向成功。
补充如果 CAS 操作失败， 则说明， 有另外一个线程 Thread B 抢先获取了偏向锁。 这种状态说明该对象的竞争比较激烈， 此时需要撤销 Thread B 获得的偏向锁，将 Thread B 持有的锁升级为轻量级锁。 该操作需要等待全局安全点 JVM safepoint ( 此时间点， 没有线程在执行字节码)
如果是已偏向状态， 则检测 MarkWord 中存储的 thread ID 是否等于当前 thread ID
如果相等， 则证明本线程已经获取到偏向锁，可以直接继续执行同步代码块
如果不等， 则证明该对象目前偏向于其他线程， 需要撤销偏向锁
从上面的偏向锁机制描述中，可以注意到
偏向锁的 撤销（revoke） 是一个很特殊的操作， 为了执行撤销操作， 需要等待全局安全点（Safe Point）， 此时间点所有的工作线程都停止了字节码的执行
偏向锁的撤销（Revoke）
如上文提到的， 偏向锁的撤销（Revoke） 操作并不是将对象恢复到无锁可偏向的状态， 而是在偏向锁的获取过程中， 发现了竞争时， 直接将一个被偏向的对象“升级到” 被加了轻量级锁的状态。 这个操作的具体完成方式如下：
还未添加个人签名 2022.04.13 加入
还未添加个人简介
评论