synchronized原理

目录：
Java 对象头

• 原理之 Monitor(锁)
• 原理之 synchronized
  synchronized 原理进阶
  1.轻量级锁
  加锁
  解锁
  2. 锁膨胀
  3. 自旋优化
  4. 偏向锁
     偏向状态
     撤销 - 调用对象 hashCode
     撤销 - 其它线程使用对象
     撤销 - 调用 wait/notify
     批量重偏向
     批量撤销
     5.锁消除

Java 对象头

1.普通对象：
以 32 位虚拟机为例,普通对象的对象头结构如下【一共8字节】，
其中的Klass Word为指针，指向这个对象从属的对应的Class【类对象】【找到这个对象是什么类型的】；

2.数组对象 除了Klass Word和Mark Word，还有4字节的数组长度，对象头一共12字节

Mark Word也是4字节-32位，具体结构如下：
25位表示hashcode
4位代表这个对象在垃圾回收时的分代年龄
1位是否为偏向锁
最后2位表示加锁状态【normal就是正常状态，01，表示没有与任何锁关联】
如果synchronized关联到monitor对象了，则最后2位变成10，前面30位部分变成指向monitor对象的指针

所以一个对象的结构如下：

一个int 只占4字节，但一个integer 对象头就占8字节，数据占4字节，补齐又要4字节，占了16字节
所以内存敏感时，最好用基本数据类型

另，64 位虚拟机 Mark Word
未加锁是01
轻量级锁是00
重量级锁是10【Monitor】

1

• 原理之 Monitor(锁)

Monitor(锁)被翻译为监视器或管程，Monitor是操作系统提供的，是c语言实现的

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

如果synchronized关联到monitor对象了，则Mark Word 中加锁状态，即最后2位变成10；前面30位部分变成指向monitor对象的指针

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【阻塞队列，处于BLOCK阻塞状态】
• Thread-2 执行完同步代码块的内容，然后唤醒 EntryList 中等待的线程来竞争锁，竞争的时是非公平的
• 图中 WaitSet 中的 Thread-0，Thread-1 是之前获得过锁，但条件不满足进入 WAITING 状态的线程，后面讲wait-notify 时会分析

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

• 原理之 synchronized
  

反编译后的字节码：

注意
方法级别的 synchronized 不会在字节码指令中有所体现

0: getstatic #2 // <- lock引用 （synchronized开始）
3: dup //复制了一份lock变量的引用存储在slot_1中【为了解锁使用】
4: astore_1 // lock引用 -> slot 1
5: monitorenter // 将 lock对象 MarkWord 置为 Monitor 指针
• 6: getstatic #3 // <- i 6-11这四步就是做counter++操作 #3代表counter
• 9: iconst_1 // 准备常数 1
• 10: iadd // +1
• 11: putstatic #3 // -> i
• 14: aload_1 // <- lock引用 拿到临时变量slot_1中存储的lock变量的引用，根据引用通过MarkWord头找到Monitor
• 15: monitorexit // 将 lock对象 MarkWord 重置, 唤醒 EntryList【之前的hashcode等已经存在了monitor对象当中，读取回来】
• 16: goto 24 // 执行到24，代码结束

// 下面是异常处理指令，可以看到，如果出现异常，也能自动地释放锁
19: astore_2 // e -> slot 2 把异常对象存储在临时变量slot 2中
20: aload_1 // <- 加载lock引用
21: monitorexit // 将 lock对象 MarkWord 重置, 唤醒 EntryList【释放锁】
22: aload_2 // <- slot 2 (e)【在slot 2中取出异常，并抛出】
23: athrow // throw e
24: return

// 监测字节码的执行，监测范围是from-to 6-16是同步代码块的内容，如果在这一块出现异常，就跳转到第19行
Exception table:
from to target type
6 16 19 any
19 22 19 any

之前是说synchronized是让每个对象管理一个monitor，而monitor是由操作系统提供的，每次使用要从操作系统获取monitor锁，这样成本比较高【重量级锁】

从java6开始，对synchronized获取锁的方式进行了改进：

每一次翻书包就代表每一次CAS操作

刻名字表示对象的MarkWord中记录了Thread id

批量重偏向和批量撤销

synchronized 原理进阶

1.轻量级锁
轻量级锁的使用场景是：如果一个对象虽然有多个线程要对它进行加锁，但是加锁的时间是错开的（也就是没有竞争时），那么可以使用轻量级锁来进行优化，有竞争时会升级为重量级锁。
轻量级锁对使用者是透明的，即语法仍然是synchronized

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

• 创建锁记录（Lock Record）对象，每个线程都的栈帧都会包含一个锁记录的结构【JVM层面】，内部可以存储锁定对象的Mark Word
【锁结构中有两部分内容：一个是对象指针(锁住对象的对象地址)；另一个是记录要加锁对象的Mark Word】

加锁：
• 让锁记录中 Object reference 指向锁对象，并尝试用 cas 替换 Object 的 Mark Word，将 Mark Word 的值存入锁记录【锁记录的数据与Mark Word数据进行交换，加锁状态是00表示轻量级锁，未加锁是01】
如果交换成功，则说明对象成功上锁

【CAS保证交换操作是原子的，不会被打断】

• 如果 cas 替换成功【要求对象加锁状态是01才能成功】，对象头中Mark Word存储锁记录地址和状态 00 ，表示由该线程给对象加锁, 加的是轻量级锁，这时图示如下【此时锁记录中就临时存放原来markword中存放的哈希值，分代年龄等】

• 如果 cas 失败【对象加锁状态已经是00了】，有两种情况
○ 如果是其它线程已经持有了该 Object 的轻量级锁【已经是00】，这时表明有竞争，进入锁膨胀过程
○ 如果是自己执行了 synchronized 锁重入【自己的线程又一次给同一个对象加锁了】，那么再添加一条 Lock Record 作为重入的计数【这个锁记录无意义，此时记录markword的地方为null，只是计数】
【但这种加锁失败没有关系，因为知道是自己加的】【加了几次锁，就代表有几个锁记录lock record】

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

• 当退出 synchronized 代码块（解锁时）锁记录的值不为 null，这时使用 cas 将 Mark Word 的值恢复给对象头【还原到原来的hashcode 分代年龄 是否偏向锁 以及最开始的无锁状态01】
○ 成功，则解锁成功
○ 失败，说明轻量级锁进行了锁膨胀或已经升级为重量级锁，进入重量级锁解锁流程

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

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

• 这时 Thread-1 加轻量级锁失败，进入锁膨胀流程
○ 即为 Object 对象申请 Monitor 锁【重量级锁】，让 Object 的MarkWord指向重量级锁地址，并且后两位变成10【重量级锁Monitor】
(因为现在线程有冲突，轻量级锁没有阻塞，所以需要升级为重量级锁)
○ 然后自己进入 Monitor 的 EntryList BLOCKED, 让自己变成阻塞状态

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

3. 自旋优化
   重量级锁竞争的时候，还可以使用自旋来进行优化，如果当前线程自旋成功（即这时候持锁线程已经退出了同步块，释放了锁），这时当前线程就可以避免阻塞。
   【让这个线程暂时先不要进入entrylist阻塞，而是进行几次循环，如果在这个过程中持锁线程释放锁，则不要阻塞了】【因为一次阻塞代表线程要发生一次上下文切换，有开销】

【自旋重试适用于多核CPU，如果是单核，线程12只能运行一个，自旋就没有意义】

自旋重试成功的情况【线程2获取monitor失败后 先自旋重试几次】

自旋重试失败的情况

• 自旋会占用 CPU 时间，单核 CPU 自旋就是浪费，多核 CPU 自旋才能发挥优势。
• 在 Java 6 之后自旋锁是自适应的，比如对象刚刚的一次自旋操作成功过，那么认为这次自旋成功的可能性会高，就多自旋几次；反之，就少自旋甚至不自旋，总之，比较智能。
• Java 7 之后不能控制是否开启自旋功能【底层自动控制】

4. 偏向锁
   轻量级锁【用的锁记录结构】在没有竞争时（就自己这个线程），每次重入仍然需要执行 CAS 操作【重入时CAS替换失败，但仍然会尝试；自己的锁结构保留作为重入时的计数】。

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

偏向状态
回忆一下对象头格式 倒数第三位：是否起用了偏向锁 0没有 1有启用

54位线程ID【操作系统分配的】

一个对象创建时：
• 如果开启了偏向锁（默认开启），那么对象创建后，markword 值为 0x05 即最后 3 位为 101，这时它的thread、epoch、age 都为 0
• 偏向锁是默认是延迟的，不会在程序启动时立即生效，如果想避免延迟，可以加 VM 参数 -XX:BiasedLockingStartupDelay=0 来禁用延迟
• 如果没有开启偏向锁，那么对象创建后，markword 值为 0x01 即最后 3 位为 001，这时它的 hashcode、age 都为 0，第一次用到 hashcode 时才会赋值

1） 测试延迟特性
2） 测试偏向锁

加锁过程中 前54位变成线程ID，说明加的是偏向锁
解锁之后，线程id仍然会保留在Markword中，线程ID不变

3）测试禁用
在上面测试代码运行时在添加 VM 参数 -XX:-UseBiasedLocking 禁用偏向锁
没加锁，最后三位001【正常】
加锁过程中是000【轻量级锁】 所以优先级是：偏向锁->轻量级锁->重量级锁

4. 测试 hashCode
   当调用对象的hashcode方法的时候就会撤销这个对象的偏向锁，因为使用偏向锁时没有位置存hashcode的值了

正常状态对象一开始是没有 hashCode 的，第一次调用才生成

偏向状态撤销 1- 调用对象 hashCode
当一个可偏向的对象调用了对象的 hashCode，但偏向锁的对象 MarkWord 中存储的是线程 id，如果调用 hashCode 会导致偏向锁被撤销【而被迫变成正常Normal状态，填充入hashcode】
○ 轻量级锁会在锁记录中记录 hashCode
○ 重量级锁会在 Monitor 中记录 hashCode
在调用 hashCode 后使用偏向锁，记得去掉 -XX:-UseBiasedLocking

输出

【偏向锁和轻量级锁，访问对象的线程都是交错开的，否则就是重量级锁了】

偏向状态撤销2 - 其它线程使用对象
当有其它线程使用偏向锁对象时，会将偏向锁升级为轻量级锁【前提：线程交错运行】

撤销 - 调用 wait/notify【因为wait notify只有重量级锁才有】

批量重偏向【一个线程关联多个锁对象】
如果对象虽然被多个线程访问，但没有竞争，这时偏向了线程 T1 的对象仍有机会重新偏向 T2，重偏向会重置对象的 Thread ID【偏向锁升级为轻量级锁，但其他线程仍然偏向T1线程；直到撤销偏向锁升级轻量级锁的操作超过20次，才重新偏向】

当撤销偏向锁阈值超过 20 次后，jvm 会这样觉得，我是不是偏向错了呢，于是会在给这些对象加锁时重新偏向至
加锁线程 ，继续使用偏向锁
【批量重偏向：针对那些还是偏向前一个线程的对象】
【前20次已经被设为不可偏向，升级为轻量级锁的对象，不变，仍然是不可偏向的】

例子：先用一个线程批量给30个对象加锁解锁，再用另一个线程给这30个对象加锁解锁

重偏向是批量执行的，超过阈值后，其他对象全部重偏向到另一个线程，不再升级为轻量级锁

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

LockSupport void park(Object blocker); // 暂停当前线程
void unpark(Thread thread); // 恢复当前线程

例子：先用一个线程批量给39个对象加锁解锁，再用另一个线程给这39个对象加锁解锁，再用第三个线程…最后在主线程里新建一个此类对象

t3先加锁前十九个对象，这19个对象已经被t2设置为不可偏向锁，状态不会变，故t3默认加轻量级锁

从第20个开始以后的对象，被重偏向到t2，遇到t3，又被撤销偏向，升级为轻量级锁

0-38加起来就已经有39次撤销操作了，再进入到第40次撤销操作时【新建一个此类对象】，MarkWord就不再是101了，变成001【不可偏向】

如果是0-37，则最后新建的这个类的对象其markword仍然是101，可偏向的

5.锁消除

java运行时，有一个JIT即时编译器！会对java的字节码进行进一步的优化：【开关默认是打开的】
发现局部变量o根本不会逃离方法的作用范围，意味着不存在被共享的变量，synchronized就没有任何意义，被优化去掉，真正代码执行时就没有synchronized了

没有加锁消除时，可以发现synchronized对性能影响还是很大的

锁粗化
对相同对象多次加锁，导致线程发生多次重入，可以使用锁粗化方式来优化，这不同于之前讲的细分锁的粒度。

目录