Java synchronized的相关实现原理

关于synchronized

内置锁

Java提供了一种内置的锁机制来支持原子性：同步代码块。
同步代码块包括两个部分：

• 作为锁的对象引用
• 作为由这个锁保护的代码块

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

• 对于普通同步方法，锁是当前实例对象
• 对于静态同步方法，锁是当前类的Class对象
• 对于同步方法块，锁是synchonized括号里配置的对象

这些锁被称为内置锁（Intrinsic Lock）或监视器锁（Monitor Lock），线程在进入同步代码块之前会自动获得锁，并且在退出同步代码块时自动释放锁。（无论是通过正常的控制路径退出，还是通过从代码块中抛出异常退出）

Java的内置锁相当于一种互斥锁，这意味着最多只有一个线程能持有这种锁。当线程A尝试获取一个由线程B持有的锁时，线程A必须等待或阻塞，直到线程B释放这个锁。如果线程B永不释放锁，那么A也将永远地等下去。

可重入

当某个线程请求一个由其他线程持有的锁时，发出请求的线程就会阻塞。然而，内置锁是可重入的，因此如果某个线程试图获得一个已经由它持有的锁，那么这个请求就会成功。
重入意味着获取锁的操作粒度是线程。
重入的一种实现方式是，为每个锁关联一个计算值和一个所有者线程。
当计数值为0时，这个锁就被认定是没有被任何线程持有。当线程请求一个未被持有的锁时，JVM将记下锁的持有者，并且将获取计数值置为1。
如果同一个线程再次获取这个锁，计数值将递减，而当线程退出同步代码块时，计数器会相应地递减。当计数值为0时，这个锁将被释放。

Java虚拟机实现同步的方式

synchronized关键字经过Javac编译之后，会在同步代码块的开始位置插入monitorenter指令，而monitorexit是插入到方法结束处和异常处，JVM要保证每个monitorenter必须有对应的monitorexit与之配对。
这两个字节码指令都需要一个引用类型参数来指明要锁定和解锁的对象。关于在Java源码中如何判断当前锁的对象，在前面有所提及。
根据《Java虚拟机规范》的要求，在执行monitorenter指令时，首先要去尝试获取对象的锁。如果这个对象没被锁定，或者当前线程已经持有了那个对象的锁，就把锁的计数器的值增加一，而在执行monitorexit指令时会将锁计数器的值减一。一旦计数器的值为零，锁随即就被释放了。如果获取对象锁失败，那么当前线程就会被阻塞等待，直到请求锁定的对象被持有它的线程释放为止。
从功能上来看，根据以上《Java虚拟机规范》对monitorenter和monitorexit的行为描述，可以得出两个关于synchronized的直接结论：

• 被synchronized修饰的同步块对同一个线程来说是可重入的。
• 被synchronized修饰的同步块在持有锁的线程执行完毕并释放锁之前，会无条件地阻塞后面其他线程的进入。

Java对象头

synchronized用的锁是存在Java对象头里的。如果对象是数组类型，则虚拟机用3个字宽 （Word）存储对象头，如果对象是非数组类型，则用2字宽存储对象头。在32位虚拟机中，1字宽等于4字节，即32bit，如下Java对象头长度表格：

Java对象头里的Mark Word里默认存储对象的HashCode、分代年龄和锁标记位。32位JVM的Mark Word的默认存储结构表如下：

在运行期间，Mark Word里存储的数据会随着锁标志位的变化而变化。Mark Word可能变化为存储以下4种数据，如下表所示：

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

锁的升级与对比

Java SE 1.6为了减少获得锁和释放锁带来的性能消耗，引入了“偏向锁”和“轻量级锁”，在 Java SE 1.6中，锁一共有4种状态，级别从低到高依次是：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态，这几个状态会随着竞争情况逐渐升级。锁可以升级但不能降级，意味着偏 向锁升级成轻量级锁后不能降级成偏向锁。这种锁升级却不能降级的策略，目的是为了提高获得锁和释放锁的效率，下面会详细分析。

偏向锁

HotSpot的作者经过研究发现，大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁。当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID，以后该线程在进入和退出 同步块时不需要进行CAS操作来加锁和解锁，只需简单地测试一下对象头的Mark Word里是否 存储着指向当前线程的偏向锁。如果测试成功，表示线程已经获得了锁。如果测试失败，则需要再测试一下Mark Word中偏向锁的标识是否设置成1（表示当前是偏向锁）：如果没有设置，则使用CAS竞争锁；如果设置了，则尝试使用CAS将对象头的偏向锁指向当前线程。
（1）偏向锁的撤销
偏向锁使用了一种等到竞争出现才释放锁的机制，所以当其他线程尝试竞争偏向锁时， 持有偏向锁的线程才会释放锁。偏向锁的撤销，需要等待全局安全点（在这个时间点上没有正 在执行的字节码）。它会首先暂停拥有偏向锁的线程，然后检查持有偏向锁的线程是否活着， 如果线程不处于活动状态，则将对象头设置成无锁状态；如果线程仍然活着，拥有偏向锁的栈 会被执行，遍历偏向对象的锁记录，栈中的锁记录和对象头的Mark Word要么重新偏向于其他 线程，要么恢复到无锁或者标记对象不适合作为偏向锁，最后唤醒暂停的线程。
以下的图中线程1演示了偏向锁初始化的流程，线程2演示了偏向锁撤销的流程。

（2）关闭偏向锁
偏向锁在Java 6和Java 7里是默认启用的，但是它在应用程序启动几秒钟之后才激活，如 有必要可以使用JVM参数来关闭延迟：-XX:BiasedLockingStartupDelay=0。如果你确定应用程 序里所有的锁通常情况下处于竞争状态，可以通过JVM参数关闭偏向锁：-XX:- UseBiasedLocking=false，那么程序默认会进入轻量级锁状态。

轻量级锁

（1）轻量级锁加锁
线程在执行同步块之前，JVM会先在当前线程的栈桢中创建用于存储锁记录的空间，并将对象头中的Mark Word复制到锁记录中，官方称为Displaced Mark Word。然后线程尝试使用 CAS将对象头中的Mark Word替换为指向锁记录的指针。如果成功，当前线程获得锁，如果失败，表示其他线程竞争锁，当前线程便尝试使用自旋来获取锁。
自旋次数如果超过以下条件，则会膨胀为重量级锁：

1. 在jdk1.6之前，默认10次，可通过-XX:PreBlockSpin来修改，或者自旋线程数超过CPU核数的一半。
2. 在jdk1.6之后，引入了自适应自旋锁，次数并非一成不变。根据获取锁的成功率来决定是否能有更长的等待时间。

（2）轻量级锁解锁
轻量级解锁时，会使用原子的CAS操作将Displaced Mark Word替换回到对象头，如果成功，则表示没有竞争发生。如果失败，则说明有其它线程尝试过获取该锁，并且在有限的自旋次数下都获取锁失败了，于是就将原指向线程栈帧锁记录的指针，改为了指向重量级锁的指针。因此就要在释放锁的同时，唤醒被阻塞挂起的线程。
以下的图中展示的是两个线程同时争夺锁，导致锁膨胀的流程图。

因为自旋会消耗CPU，为了避免无用的自旋（比如获得锁的线程被阻塞住了），一旦锁升级成重量级锁，就不会再恢复到轻量级锁状态。当锁处于这个状态下，其他线程试图获取锁时，都会被阻塞住，当持有锁的线程释放锁之后会唤醒这些线程，被唤醒的线程就会进行新一轮的夺锁之争。

锁的优缺点对比

下面总结下，用于实现synchronized的几种锁的优缺点：

关于偏向锁状态下与Mark Word中对象的hash code的问题

相信只要仔细观察对象头中的Mark Word数据结构，不难发现一个问题：当对象进入偏向状态的时候，Mark Word大部分的空间（23个比特）都用于存储持有锁的线程ID了，这部分空间占用了原有存储对象哈希码的位置，那原来对象的哈希码这么办呢？
在Java语言里一个对象如果计算过哈希码，就应该一直保持该值不变（强烈推荐但不强制，因为用户可以重载hashCode()方法，按自己的意愿返回哈希码），否则很多依赖对象哈希姆的API都可能存在出错的风险。
而作为绝大多数对象哈希码的Object::hashCode()方法，返回的是对象的一致性哈希码，这个值是能强制保持不变的，它通过在对象头中存储计算结果来保证第一次计算之后，再次调用该方法取到的哈希码值，永远不会再发生改变了。
因此，当一个对象已经计算过一致性哈希码后，它就再也无法进入偏向锁状态了；而当一个对象当前正处于偏向锁状态，又收到需要计算其一致性哈希码请求时（这里的计算请求应来自于对Object::hashCode()或者System::identityHashCode(Object)方法的请求调用，而不是针对于重写了对象的hashCode()方法的请求），
它的偏向锁状态会被立即撤销，并且锁会膨胀成重量级锁。在重量级锁的实现中，对象头指向了重量级锁的位置，代表重量级锁的ObjectMonitor类里有字段可以记录非加锁状态（标志位为：01）下的Mark Word，其中自然也可以存储原来的哈希码。

锁状态转化与对象的Mark Word关系

下面对偏向锁、轻量级锁的状态转化及对象Mark Word的关系进行一个总结，如下图所示：