synchronized底层

一、Java对象头

通常创建的Java对象在内存中有两部分组成【对象头与对象中的成员变量】

以 32 位虚拟机为例介绍对象头

对象头在32 位虚拟机上是64位（8个字节）；其中4个字节为Mark Word，另外四个字节为Klass Word

每个对象如何知道自己的类型？
由Klass Word来表示，它是一个指针，它指向了对象所从属的Class（通过指针便可找到类对象）

其中Mark Word 结构（32位）为：

数组对象：（除Mark Word、Klass之外，还有4个字节的数组长度）

二、Monitor

Monitor(锁) 被翻译为监视器或者管程，也是Java中synchronized锁底层的原理

Monitor与Java对象之间的关系：
每一个Java对象都可以关联一个Monitor对象，如果使用synchronized 给对象上锁（重量级）之后，该对象头的Mark Word就被设置指向 Monitor 对象的指针

2.1、Monitor—工作原理

synchronized底层—Monitor(锁) 工作原理

■ 刚开始Monitor中Owner为null

■ 当Thread-2 执行synchronized(obj)就会将Monitor的所有者Owner置为Thread-2，Monitor中只能有一个Owner

■ 在Thread-2.上锁的过程中，如果Thread-3, Thread-4, Thread-5 也来执行synchronized(obj)， 就会进入EntryList BLOCKED（等待队列/阻塞队列）

■ Thread-2 执行完同步代码块的内容,然后唤醒EntryList中等待的线程来竞争锁，竞争的时是非公平的（并非先进入的线程先成为Owner）由JDK底层实现决定

■ 图中WaitSet中的Thread-0， Thread-1是之前获得过锁，但条件不满足进入WAITING状态的线程，后面中wait-notify部分会对其进行分析

注意：

● synchronized必须是进入同一个对象的monitor才有上述的效果
● 不加synchronized的对象不会关联监视器，不遵从以上规则

2.2、Monitor工作原理—字节码角度

 static final Object lock=new Object();// 要保护的共享成员变量static int counter=0;public static void main(String[] args) throws InterruptedException {synchronized (lock){counter++;}}

对应的字节码分析：

synchronized字节码分析

2.2、synchronized进阶原理（优化）

synchronized工作方式是让每个对象关联一个Monitor为真正的锁，但Monitor锁是由操作系统提供的，若要使用它成本是较高的，若每次进入synchronized都要获取Monitor锁对程序运行性能是存在影响的【从Java 6开始对synchronized关键字获取锁的方式进行了一些优化，从直接使用Monitor锁改为了还可以使用轻量级锁、偏向锁等】

小故事

故事角色
● 老王 - 操作系统
● 小南 - 线程
● 小女 - 线程
● 房间 - 对象
● 房间门上 - 防盗锁 - Monitor
● 房间门上 - 小南书包 - 轻量级锁
● 房间门上 - 刻上小南大名 - 偏向锁
● 批量重刻名 - 一个类的偏向锁撤销到达 20 阈值
● 不能刻名字 - 批量撤销该类对象的偏向锁，设置该类不可偏向

小南要使用房间保证计算不被其它人干扰（原子性），最初，他用的是防盗锁，当上下文切换时，锁住门。这样，即使他离开了，别人也进不了门，他的工作就是安全的。

但是，很多情况下没人跟他来竞争房间的使用权。小女是要用房间，但使用的时间上是错开的，小南白天用，小女晚上用。每次上锁太麻烦了，有没有更简单的办法呢？

小南和小女商量了一下，约定不锁门了，而是谁用房间，谁把自己的书包挂在门口（轻量级锁优化），但他们的书包样式都一样，因此每次进门前得翻翻书包，看课本是谁的，如果是自己的，那么就可以进门，这样省的上锁解锁了。万一书包不是自己的，那么就在门外等，并通知对方下次用锁门的方式。

后来，小女回老家了，很长一段时间都不会用这个房间。小南每次还是挂书包，翻书包，虽然比锁门省事了，但仍然觉得麻烦。

于是，小南干脆在门上刻上了自己的名字：【小南专属房间，其它人勿用】，下次来用房间时，只要名字还在，那么说明没人打扰，还是可以安全地使用房间。如果这期间有其它人要用这个房间，那么由使用者将小南刻的名字擦掉，升级为挂书包的方式。（偏向级锁优化）===>专属于某个房间使用

同学们都放假回老家了，小南就膨胀了，在 20 个房间刻上了自己的名字，想进哪个进哪个。后来他自己放假回老家了，这时小女回来了（她也要用这些房间），结果就是得一个个地擦掉小南刻的名字，升级为挂书包的方式。老王觉得这成本有点高，提出了一种批量重刻名的方法，他让小女不用挂书包了，可以直接在门上刻上自己的名字【批量重偏向优化】（当一个类的偏向锁被撤销达到一定预值时，JVM认定在这种情况下不应该让这些类的对象继续偏向于某一个线程使用）

后来，刻名的现象越来越频繁（偏向锁撤销次数达到更高预值），老王受不了了（这个类是否不太适合做偏向锁的优化）：算了，这些房间都不能刻名了，只能挂书包

2.3、synchronized优化原理——轻量级锁

轻量级锁的使用场景：如果一个对象虽然有多线程访问，但多线程访问的时间是错开的（也就是说没有竞争），那么可以使用轻量级锁来优化。如果有竞争，轻量级锁会升级为重量级锁。

轻量级锁对使用者是透明的，即语法仍然是synchronized，调用synchronized会优先使用轻量级锁进行加锁，若轻量级锁加锁失败会再使用重量级锁进行加锁

假设有两个方法同步块，利用同一个对象加锁

    static final Object obj=new Object();public static void method(){synchronized (obj){// 同步块Amethod2();}}public static void method2(){synchronized (obj){// 同步块B}}

● 创建锁记录（Lock Record）对象，每个线程的栈帧都会包含一个锁记录的结构，内部可以存储对象的Mark Word

● 让锁记录中的Object reference指向对象锁，并尝试用CAS替换Object的Mark Word，将Mark Word的值存入锁记录

● 如果cas替换成功，对象头中存储了锁记录地址和状态 00（轻量级锁），表示由该线程给对象加锁，给对象加锁

● 如果cas失败，由两种情况
—— 如果是其他线程已经持有了Object的轻量级锁，这是表明有竞争，进入锁膨胀过程
—— 如果是自己执行了 synchronized 锁重入（自身线程又一次给同一个对象加锁），那么再添加一条Lock Record作为重入的计数

● 当退出synchronized代码块（解锁时）如果有取值为null的锁记录，表示有重入，这时重置锁记录，表示重入计数减一

● 当退出synchronized代码块（解锁时）锁记录的值不为null，这时使用cas将Mark Word的值恢复给对象头
—— 成功，则解锁成功
—— 失败，说明轻量级锁进行了锁膨胀或已经升级为重量级锁，进入重量级锁解锁流程

2.4、synchronized优化原理——锁膨胀

如果在尝试加轻量级锁的过程中，CAS操作无法成功，这时一种情况就是有其他线程为此对象加上了轻量级锁（有竞争），这时需要进行锁膨胀，将轻量级锁变为重量级锁。

static Object obj=new Object();public static void method(){synchronized (obj){// 同步块}

● 当 Thread-1 进行轻量级加锁时，Thread-0 已经对该对象加了轻量级锁

● 这时 Thread-1加轻量级锁失败，进入锁膨胀流程
—— 即为 Object 对象申请 Monitor 锁，让Object指向重量级锁地址
—— 然后自己进入Monitor的EntryList BLOCKED

● 当Thread-0退出同步块解锁时，使用cas将Mark Word 的值恢复给对象头，失败（此时锁膨胀，对象的Mark Word 已经变为重量级锁的地址）。这时会进入重量级流程，即按照Monitor地址找到Monitor对象，设置Owner为null，唤醒EntryList中BLOCKED 线程

2.5、synchronized优化原理——自旋优化

重量级锁竞争的时候，还可以使用自旋来进行优化，如果当前线程自旋成功（即这个时候持锁线程已经退出了同步块，释放了锁），这时当前线程可以避免阻塞。阻塞意味着线程要发生上下文切换，这种操作是较慢的并且比较耗费性能【用自旋的方式可以避免阻塞上下文切换的发生】

自旋重试成功的情况

自旋操作需要使用CPU，其适合多核CPU场景下。若为单核，自旋无意义（无CPU可用）

自旋重试失败的情况

● 在Java 6之后自旋锁是自适应的，比如对象刚刚的一次自旋操作成功过，那么认为这次自旋成功的可 能性会高，就多自旋几次；反之就少自旋甚至不自旋，总之，比较智能

● 自旋会占用CPU时间，单核CPU自旋就是浪费，多核CPU自旋才能发挥优势

● Java 7之后不能控制是否开启自旋功能

2.6、synchronized优化原理——偏向锁

轻量级锁相对重量级锁性能有了一定性能提升，其不再需要Monitor锁，只是用线程栈中锁记录来充当轻量级锁。但轻量级锁存在一定的缺点，在没有竞争时（就自己这个线程），每次重入仍然需要执行CAS操作。

Java 6中引入了偏向锁来做进一步优化：只有第一次使用CAS将线程ID设置到对象的Mark Word头，之后发现这个线程ID是自己的就没有竞争，不用重新CAS。以后只要不发生竞争，这个对象就归该线程所有

锁重入：

  static final Object obj = new Object();public static void m1() {synchronized (obj) { // 同步块Am2();}}public static void m2() {synchronized (obj) {// 同步块Bm3();}}private static void m3() {synchronized (obj) {// 同步块C}}
}

2.7、synchronized优化原理—偏向锁—状态

对象头格式

一个对象创建时：

● 如果开启了偏向锁（默认开启），那么对象创建后，markword值为0x05即最后三位为101，这是它的thread、epoch、age都为0

● 偏向锁是默认延迟的，不会在程序启动时立刻生效，如果想避免延迟，可以加VM参数 -XX:BiasedLockingStartupDelay=0来禁用延迟

● 如果没有开启偏向锁，那么对象创建后，markword值为0x01 即最后三位为 001，这是他的hashcode、age都为0，第一次用到hashcode时才会赋值

如何查看对象的对象头（依赖第三方jar包，其他工具查看并不方便）
在pom.xml中加入如下依赖：

<dependency><groupId>org.openjdk.jol</groupId><artifactId>jol-core</artifactId><version>0.10</version></dependency>

注意：处于偏向锁的对象解锁后，线程id仍存储于对象头中

测试禁用（此时创建的对象为正常对象）
在测试运行时可以添加VM参数-XX: -UseBiasedLocking 禁用偏向锁

2.8、synchronized优化原理—偏向锁—撤销

① 撤销——调用对象hashCode

调用了对象的hashCode，但偏向锁的对象Mark Word中存储的是线程id，如果调用hashCode会导致偏向锁被撤销
● 轻量级锁会在锁记录中记录hashCode
● 重量级锁会在Monitor中记录hashCode

在调用hashCode后使用偏向锁，应记得去掉-XX: -UseBiasedLocking

② 撤销——其他线程使用对象
当有其他线程使用偏向锁对象时，会将偏向锁升级为轻量级锁（可偏向变为不可偏向）

③ 撤销——调用wait / notify

wait / notify：只有重量级锁才有

批量重偏向

④ 撤销——批量重偏向
如果对象虽被多个线程访问，但没有竞争，这时偏向了线程t1的对象仍有机会偏向t2，重偏向会重置对象的 Thread ID

当撤销偏向锁阈值超过20次以后，jvm会这样觉得，自身是否是否偏向错？于是会在给这些对象加锁时重新偏向至加锁线程

当撤销偏向锁阈值超过40次以后，jvm会这样觉得，自身确实偏向错了，根本就不该偏向。于是整个类所有对象都会变为不可偏向的，新建的对象也是不可偏向的

2.9、synchronized优化原理—锁消除

锁消除（比较加锁与不加锁的性能差异）

import org.openjdk.jmh.annotations.*;
import java.util.concurrent.TimeUnit;@Fork(1)
// 平均运行时间
@BenchmarkMode(Mode.AverageTime)
// 预热次数
@Warmup(iterations=3)
// 测试轮数
@Measurement(iterations=5)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class MyBenchmark {static int x = 0;//对静态变量进行++操作@Benchmarkpublic void a() throws Exception {x++;}@Benchmark// 先创建局部 Object 对象，在对其进行加锁，加锁后进行++操作public void b() throws Exception {Object o = new Object();synchronized (o) {x++;}}
}

运行结果：

加锁会有一定的性能损耗，为何两者运行时间却相近

JIT即时编译器会对Java字节码再做进一步优化（反复执行的热点代码JIT会对其进行优化，分析Object为局部变量，根本不会逃离方法的作用范围，这种情况意味着对象不可能会被共享，使用synchronized 对其加锁毫无意义）

这种优化使可以通过开关来控制的（默认打开）：
关闭开关===>java -XX: -EliminateLocks -jar benchmarks.jar

运行结果：（此时性能相差较大）