并发编程学习3—深度解析各种锁

monitor翻译为监视器或管程。

1. synchronized底层

每个 Java 对象都可以关联一个 Monitor 对象，如果使用 synchronized 给对象上锁（重量级）之后，该对象头的Mark Word 中就被设置指向 Monitor 对象的指针。此时Mark Word内部结构就会变化，具体是要看加的是什么类型的锁。

1.1 对象头

Klass Word存的类型指针（比如知道这个对象是Student, Teacher…）

1.2 △加锁过程

Thread1和3运行到synchronized，发现Owner已经有人了Thread2，就会从运行状态进入阻塞状态，并且加入阻塞队列 EntryList。
当Thread2把synchronized(obj){ }临界区里的代码执行完，Owner就会空出来，就会叫醒阻塞队列。
WaitSet中放的是之前获得过锁的线程，但条件不满足进入Waiting状态的线程，后面讲wait-notify时会详细分析。？

1.3 字节码分析：

static final Object lock = new Object();
static int counter = 0;

public static void main(String[] args) {
	synchronized (lock) {
counter++;
}}

![[uTools_1688281108206.png]]

△△△2. synchronized底层进阶（加什么类型的锁）

（synchronized( obj ) {}时优先加偏向锁，不行再慢慢升级）
故事角色：
老王 - JVM
小南 - 线程
小女 - 线程
房间 - 对象
房间门上 - 防盗锁 - Monitor
房间门上 - 小南书包 - 轻量级锁
房间门上 - 刻上小南大名 - 偏向锁
批量重刻名 - 一个类的偏向锁撤销到达 20 阈值
不能刻名字 - 批量撤销该类对象的偏向锁，设置该类不可偏向

【Monitor】小南要使用房间保证计算不被其它人干扰（原子性），最初，他用的是防盗锁，当上下文切换时，锁住门。这样，即使他离开了，别人也进不了门，他的工作就是安全的。
但是，很多情况下没人跟他来竞争房间的使用权。小女是要用房间，但使用的时间上是错开的，小南白天用，小女晚上用。每次上锁太麻烦了，有没有更简单的办法呢？

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

后来，小女回老家了，很长一段时间都不会用这个房间。小南每次还是挂书包，翻书包，虽然比锁门省事了，但仍然觉得麻烦。（这个过程叫做锁重入，得再翻书包，需要执行CAS操作。）

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

【批量重刻名】同学们都放假回老家了，小南就膨胀了，在 20 个房间刻上了自己的名字，想进哪个进哪个。后来他自己放假回老家了，这时小女回来了（她也要用这些房间），结果就是得一个个地擦掉小南刻的名字，升级为挂书包的方式。老王觉得这成本有点高，提出了一种批量重刻名的方法，他让小女不用挂书包了，可以直接在门上刻上自己的名字。

后来，刻名的现象越来越频繁，老王受不了了：算了，这些房间都不能刻名了，只能挂书包(说明此时这个对象不适合用偏向锁，还得用轻量级锁)

2. 1 轻量级锁

轻量级锁的使用场景：
如果一个对象虽然有多线程要加锁，但加锁的时间是错开的（也就是没有竞争），那么可以使用轻量级锁来优化（不再用Monitor对象来加锁，用栈帧中的锁记录）。语法和重量级锁一样，也是用synchronized(){}.

static final Object obj = new Object();   
// 是在同一个线程里对同一对象加锁
public static void method1() {
	synchronized( obj ) {
		// 同步块 A
		method2();
}}
public static void method2() {
	synchronized( obj ) {
		// 同步块 B
}}

2. 1. 1 分析上述代码加锁流程

1. Step 1

对象头主要包括Mark Word和 Klass Word(类型变量)。 Object Body存的成员变量的信息。对齐填充。假设现在Thread-0运行到method1的临界区代码块，就会先在线程栈帧中产生一个锁记录（JVM层面），里面将要存的是对象指针和要加锁对象的Mark Word。

2. Step 2
   让锁记录中 Object reference 指向要锁的对象。
   并尝试用 cas 替换 Object 的 Mark Word，将 Mark Word 的值存入锁记录。（交换：加锁过程）
   一开始01表示无锁状态，00代表轻量级锁。

![[uTools_1688282464109.png]]

3. Step 3
   如果锁加成功了（原对象无锁01）， cas （原子性的，实现替换操作）替换成功，对象头中存储了 锁记录地址和状态 00 ，表示由该线程给对象加锁。
   原来锁记录里面存的就是原来对象的信息，将来解除锁的时候复原给对象。
   图示如下：
   ![[uTools_1688282654640.png]]
   如果 cas 失败，有两种情况：

如果是其它线程已经持有了该 Object 的轻量级锁，这时表明有竞争，进入锁膨胀过程。（已经是00或者lock record指向其他线程）
如果是自己执行了 synchronized 锁重入（上述代码运行到method2，又要给同一个对象加锁），那么再添加一条 Lock Record 作为重入的计数。（区别于锁升级）

第二种锁重入情况如图下：
![[uTools_1688282948752.png]]
第二次CAS的时候，已经自己改成00加锁了，就会CAS失败，但不是错的，lock Record那就会存成null，表示一个锁重入的计数。
4. Step 4
当退出 synchronized 代码块（解锁时）如果有取值为 null 的锁记录，如method2结束，表示有重入，这时重置锁记录（把null的那个锁记录去掉），表示重入计数减一。
当退出 synchronized 代码块（解锁时）锁记录的值不为 null，这时使用 cas 将 Mark Word 的值恢复给对象头。

成功，则解锁成功。
失败，说明轻量级锁进行了锁膨胀或已经升级为重量级锁，进入重量级锁解锁流程。

2. 2 锁膨胀

1. Step1：不同线程里对同一对象加锁，就会出现cas失败。
   ![[uTools_1688283608419.png]]
2. Step2：这时 Thread-1 加轻量级锁失败，Thread-1 进入锁膨胀流程。（下图）
   即为 Object 对象申请 Monitor 锁（得让Thread1去阻塞等待），让 Object 指向重量级锁地址（Mark word改成指向Monitor重量级锁，后面改成‘10’）。
   然后自己进入 Monitor 的 EntryList BLOCKED，这个时候Owner是Thread-0。
   ![[uTools_1688283759356.png]]
3. Step3：当 Thread-0 退出同步块解锁时，使用 cas 将 Mark Word 的值恢复给对象头，失败（因为对象的Mark Word地址已经变成重量级锁了，后两位变成’10’了）。
   这时Thread-0 会进入重量级解锁流程，即按照对象中Mark word存的 Monitor 地址找到 Monitor 对象，设置 Owner 为 null，唤醒 EntryList 中 BLOCKED 线程Thread-1。（1.2）

2. 3 自旋优化

解释：

针对重量级锁竞争的优化，如果当前对象已经被别的线程指向了Monitor的Owner，当前线程可以不立即进入阻塞队列等待，可以使用自旋来进行优化，如果当前线程自旋成功（即这时候持锁线程已经退出了同步块，释放了锁），这时当前线程就可以避免阻塞，好处是避免上下文切换。

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

2. 4 偏向锁

轻量级锁不要指向Monitor对象了，只用线程栈中的锁记录作为轻量级锁，但也有缺点：
轻量级锁在没有竞争时（就自己这个线程），每次重入仍然需要执行 CAS 操作，并又产生一个null的锁记录作为锁重入的计数。

想进一步优化，就是偏向锁。
![[uTools_1689321347633.png]]
![[uTools_1688284876353.png]]
Java 6 中引入了偏向锁来做进一步优化：

只有第一次使用 CAS 将线程 ID 设置到对象的 Mark Word 头（名字刻到房间门上，之后省去了翻书包的过程，不用CAS操作【省去】），之后发生锁重入时发现这个线程 ID 是自己的就表示没有竞争，不用重新 CAS。以后只要不发生竞争，这个对象就归该线程所有。

2. 4. 1 偏向状态

一个对象创建时：

1. 如果开启了偏向锁（默认开启），那么对象在创建后，markword 值为 0x05 即最后 3 位为 ‘101’ (第三位为‘1’就代表开启了偏向锁)，这时它的thread、epoch、age 都为 0 【也就是开启后，默认创建的就是Biased的，不是Normal】。线程给他加锁时，线程id才会被设置。
2. 偏向锁是默认是延迟的，不会在程序启动时立即生效，如果想避免延迟，可以加 VM 参数 -XX:BiasedLockingStartupDelay=0 来禁用延迟。加完锁后，从前面到倒数第十位都是线程id。synchronized( obj ) {}里面的代码运行完，发现对象头没有变化，说明这个对象还是归该线程所有的。
3. 如果没有开启偏向锁，那么对象创建后，markword 值为 0x01 即最后 3 位为 001，这时它的 hashcode、age 都为 0，第一次用到 hashcode 时才会赋值。

2. 4. 2 撤销偏向

情况1.：
当一个加了偏向锁的对象，调用了hashCode()方法，就会撤销偏向锁，从101变成001（没有额外的存 hashcode，轻量级会存在锁记录里，重量级锁存在Monitor对象里，解锁的时候都会还回来）。

情况2：
一个线程里的对象加了偏向锁，当其他线程【在不同时间】使用这个偏向锁对象时，就不应该再偏向于前一个线程，就会自动升级成轻量级锁。
注意：要保证两个线程访问是错开的，不然就升级成重量级了。

所以代码中t2线程就会等t1的synchronized(d)代码块运行完，才会到类对象中通知在这个类对象上等待的t2（synchronized(.class) wait），现在t2线程下面的代码才开始运行。
![[uTools_1688287194786.png]]
![[uTools_1688287500053.png]]
第一次 前面空后面101，表示1线程偏向锁可偏向的状态（还没加偏向锁syn）。
第二次 前面线程id后面101：给这个线程加上了偏向锁。
第三次 前面线程id后面101：解完锁，线程id之类的还保留在MarkWord。
第四次 前面线程id后面101 ：通知了2线程，可以开始了，此时还没加锁。
第五次 前面锁记录后面000：对象d已经有了线程1的偏向锁了，此时2线程只能升级成轻量级锁。
第六次 前面空后面001，2线程解锁了（注意完全解锁，不是降级），变成normal。

情况3：
如果调用wait-notify（重量级锁才用），不管原来什么锁，都会升级成重量级锁。

2. 4. 3 批量重偏向

如果对象虽然被多个线程访问，但没有竞争，这时偏向了线程 T1 的对象仍有机会重新偏向 T2，重偏向会重置对象的 Thread ID。

运行现象：

当撤销偏向锁阈值超过 20 次后（上文提到撤销偏向锁了就会升级成轻量级锁），jvm 会这样觉得，我是不是偏向错了呢，于是会在【后面】给这些对象加锁时重新偏向至新的加锁线程（Thread2）。
![[uTools_1688288177296.png]]

2. 4. 4 批量撤销

当撤销偏向锁阈值超过 40 次后，jvm 会这样觉得，自己确实偏向错了，根本就不该偏向。
于是整个类的【所有对象】都会变为不可偏向的，新建的对象也是不可偏向的。（因为此时JVM发现好多线程要用这个对象，不该偏向于第一个用的）
![[uTools_1689323685043.png]]
![[Pasted image 20230714183825.png]]

T1线程创建了39个对象，都偏向于T1。
然后T2线程运行，一开始19个是【撤销偏向】，升级为轻量级锁（001）。后面20个会【批量重偏向】（101），偏向于T2。
然后T3开始运行，前19个就是轻量级锁的，加锁解锁也是轻量级锁级别（全都没有偏向了）。从第19个开始到40个又要从T2偏到T3，进行了【撤销偏向】，去升级锁。
在主线程再想创建这个对象，就变成001不可偏向状态了。

2. 4. 5 锁消除

发现l两个方法加不加锁，运行时间差不多。
因为会被JIT（即时编译器）优化，发现代码中的Object o不会逃离方法的作用范围，是不可能被共享，加锁是没意义的，JIT会优化掉syn加锁，不会运行，直接运行里面的x++。