1 入门知识介绍
synchronized锁，是不是默认实现了锁升级。代码中只需要直接使用synchronized，至于怎么从偏向锁升级为轻量锁再升级为重量级锁，这些底层jvm已经实现了。不需要程序员担心。
是的，Java 8中的
synchronized关键字确实默认实现了锁升级的机制。当使用synchronized关键字时，JVM会自动管理锁的状态，根据竞争情况从偏向锁开始，逐步升级到轻量级锁，最终升级到重量级锁。这一过程是由JVM内部实现的，不需要程序员手动干预。锁升级的过程如下：
偏向锁（Biased Locking）：在没有竞争的情况下，JVM使用偏向锁来减少锁操作的开销。当一个线程第一次获取到锁时，该锁会偏向这个线程，后续这个线程再次访问这个同步块时，不需要任何同步操作，因为锁已经被该线程偏向了。
轻量级锁（Lightweight Locking）：如果有另一个线程尝试获取这个锁，JVM会将偏向锁撤销，并升级为轻量级锁。轻量级锁通过在栈帧中存储锁记录（Lock Record）的方式来实现，线程通过CAS（比较并交换）操作尝试将锁的Mark Word更新为指向自己的锁记录的指针，以此来获取锁。
重量级锁（Heavyweight Locking）：如果锁竞争加剧，轻量级锁的自旋操作不能及时成功获取锁，JVM会将轻量级锁膨胀为重量级锁。此时，线程会被阻塞，直到拥有锁的线程释放锁后，操作系统才会唤醒等待的线程。
这种锁升级的机制是JVM为了提高同步性能而设计的，它能够在没有竞争或竞争不激烈的情况下，减少同步操作的开销，而在竞争激烈时又能确保同步的正确性。
因此，作为Java程序员，你只需要在代码中使用
synchronized关键字来同步代码块或方法，而无需关心锁的具体状态和升级过程。JVM会自动处理这些细节，以优化程序的性能。
1.1 面试题
-
谈谈你对Synchronized的理解
-
请你聊聊Synchronized的锁升级
1.2 本章路线总纲
1.2.1 锁使用的强制要求
- 【强制】高并发时，同步调用应该去考量锁的性能损耗，能用无锁数据结构，就不要用锁；能锁区块，就不要锁整个方法体；能用对象锁，就不要用类锁。
说明：尽可能使加锁的代码块工作量尽可能的小，避免在锁代码块中调用RPC方法。
-
synchronized锁优化的背景
用锁能够实现数据的安全性，但是会带来性能下降。
无锁能够基于现成并行提升程序性能，但是会带来安全性下降
那么如何求平衡？
-
锁的升级过程
无锁-偏向锁-轻量级锁-重量级锁(锁的范围一点一点变大，还是上面那句话，尽可能锁的范围小)
1.2.2 synchronized锁：由对象头重的Mark Word根据锁标志位的不同而被复用及锁升级策略
2 Synchronized的性能变化
java5以前，只有Synchronized，这个是操作系统级别的重量级操作
(我们写一个new Thread().start()的话是调用了底层的native方法的）
- java的线程是映射到操作系统原生线程之上的，如果要阻塞或唤醒一个线程就需要操作系统介入，需要在用户态与核心态之间切换，这种切换会消耗大量的系统资源，因为用户态与内核态都有各自专用的内存空间，专用的寄存器等，用户态切换至内核态需要传递给许多变量、参数给内核，内核也需要保护好用户态在切换时的一些寄存器值、变量等，以便内核态调用结束后切换回用户态继续工作。
- 在Java早期版本中，synchronized属于重量级锁，效率低下，因为监视器锁（monitor）是依赖于底层的操作系统的Mutex Lock(系统互斥量)来实现的，挂起线程和恢复线程都需要转入内核态去完成，阻塞或唤醒一个Java线程需要操作系统切换CPU状态来完成，这种状态切换需要耗费处理器时间，如果同步代码块中内容过于简单，这种切换的时间可能比用户代码执行的时间还长”，时间成本相对较高，这也是为什么早期的synchronized效率低的原因Java 6之后，为了减少获得锁和释放锁所带来的性能消耗，引入了轻量级锁和偏向锁
（一句话就是尽量减少用户态和内核态的切换）
为什么每一个对象都可以成为一个锁-复习之前的知识
我们大概可以知道，每个对象都有一个ObjectMonitor，而每个ObjectMonitor都可以成为锁。
小结：我们说在java中每个对象都可以成为一把锁，因为在JVM中每个对象都一个monitor(监视器锁。对应到C底层叫做Object Monitor，并用c定义了很多信息。再往下到操作系统中是基于Mutex Lock互斥锁实现，涉及到了用户态和内核态的切换，所以非常耗费资源。
结合之前的synchronized和对象头说明
- 主要就是MarkWord中是什么代码表示了它是什么锁状态
从图中可以看出，如果当前锁对象是重量级锁，它底层还会有ObjectMonitor，保存了很多锁的相关信息。
3 Synchronized锁种类及升级步骤
3.1 多线程访问情况
- 只有一个线程来访问，有且唯一Only One
- 有两个线程（2个线程交替访问）
- 竞争激烈，更多线程来访问
不同线程访问情况，有着不同锁解决问题。
3.2 升级流程
Synchronized用的锁是存在Java对象头里的MarkWord中，锁升级功能主要依赖MarkWord中锁标志位和释放偏向锁标志位
- 重点关注【偏向锁位】和【锁标志位】
锁指向总结，请牢记
-
偏向锁：MarkWord存储的是偏向的线程ID；
-
轻量锁：MarkWord存储的是指向线程栈中Lock Record的指针；
-
重量锁：MarkWord存储的是指向堆中的monitor对象的指针；
3.3 无锁
复习C源码的MarkWord标记
我们知道，一个对象只是创建出来，它是无锁状态的。无锁状态的MarkWord标记占8字节，也就是64位。其中：25位是没有使用的 (unused)，31位存放了hashcode (hash)，1位未使用，4位是分代年龄 (age 4位二进制最大就是1111，十进制就是15，因此分代年龄最大15)，1位偏向锁位 (biased lock)，2位锁标识位 (normal lock)。25 + 31 + 1 + 4 + 1 + 2 = 64位(8字节)
Code1
import org.openjdk.jol.info.ClassLayout;
public class SynchronizedUpDemo {
public static void main(String[] args) {
Object o = new Object();
System.out.println(ClassLayout.parseInstance(o).toPrintable());
}
}
输出结果：
java.lang.Object object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 01 00 00 00 (00000001 00000000 00000000 00000000) (1)
4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0)
8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
12 4 (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
提出疑问
以上Code1就是new一个对象，对应64位对象标记图的无锁态！
- hashCode对应的是哪31位，为什么都是0？
- 前8个字节（64位）的对象标记应该正着看还是倒着看？
import org.openjdk.jol.info.ClassLayout;
public class SynchronizedUpDemo {
public static void main(String[] args) {
Object o = new Object();
System.out.println("10进制：" + o.hashCode());
System.out.println("16进制：" + Integer.toHexString(o.hashCode()));
System.out.println("2进制：" + Integer.toBinaryString(o.hashCode()));
System.out.println(ClassLayout.parseInstance(o).toPrintable());
}
}
输出结果：
10进制：529116035
16进制：1f89ab83
2进制：11111100010011010101110000011
java.lang.Object object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 01 83 ab 89 (00000001 10000011 10101011 10001001) (-1985248511)
4 4 (object header) 1f 00 00 00 (00011111 00000000 00000000 00000000) (31)
8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
12 4 (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
解答疑问
1.可以看到调用了hashCode()方法后，对象标记打印出了对象的hashCode，所以默认是不打印hashCode的，需要调用对象的hashCode()方法才会打印
2.倒着看的，且每8位正着看，可以看到16进制hashCode刚好对应倒着看的对象标记的31位的hashCode（1f89ab83）
二进制验证
二进制：11111100010011010101110000011
对应对象标记：00011111 10001001 10101011 10000011 ——>（第一位未使用）——>
0011111 10001001 10101011 10000011 ——> 11111 10001001 10101011 10000011 (二进制打印结果)
3.另外，无锁态的对象标志对应这里的具体如下：
程序不会有锁得竞争
无锁：初始状态，一个对象被实例化后，如果还没有被任何线程竞争锁，那么它就为无锁状态（001）
3.4 偏向锁
3.4.1 偏向锁使用场景：单线程竞争
当线程A第一次竞争到锁时，通过修改Mark Word中的偏向线程ID、偏向模式。如果不存在其他线程竞争，那么持有偏向锁的线程将永远不需要进行同步
主要作用
当一段同步代码一直被同一个线程多次访问，由于只有一个线程那么该线程在后续访问时便会自动获得锁。
例如：同一个老顾客来访，直接老规矩行方便
多线程卖票案例
public class SaleTicketDemo {
public static void main(String[] args) {
Ticket ticket = new Ticket();
new Thread(() -> {
for (int i = 0; i < 55; i++) {
ticket.sale();
}
}, "a").start();
new Thread(() -> {
for (int i = 0; i < 55; i++) {
ticket.sale();
}
}, "b").start();
new Thread(() -> {
for (int i = 0; i < 55; i++) {
ticket.sale();
}
}, "c").start();
}
}
class Ticket {
private int number = 50;
Object lockObject = new Object();
public void sale() {
synchronized (lockObject) {
if (number > 0) {
System.out.println(Thread.currentThread().getName() + "卖出第：\t" + (number--) + "\t 还剩下：" + number);
}
}
}
}
输出结果：
a卖出第： 50 还剩下：49
a卖出第： 49 还剩下：48
a卖出第： 48 还剩下：47
a卖出第： 47 还剩下：46
a卖出第： 46 还剩下：45
a卖出第： 45 还剩下：44
b卖出第： 44 还剩下：43
b卖出第： 43 还剩下：42
b卖出第： 42 还剩下：41
a卖出第： 41 还剩下：40
a卖出第： 40 还剩下：39
a卖出第： 39 还剩下：38
a卖出第： 38 还剩下：37
a卖出第： 37 还剩下：36
a卖出第： 36 还剩下：35
a卖出第： 35 还剩下：34
a卖出第： 34 还剩下：33
a卖出第： 33 还剩下：32
a卖出第： 32 还剩下：31
a卖出第： 31 还剩下：30
a卖出第： 30 还剩下：29
a卖出第： 29 还剩下：28
a卖出第： 28 还剩下：27
a卖出第： 27 还剩下：26
a卖出第： 26 还剩下：25
a卖出第： 25 还剩下：24
a卖出第： 24 还剩下：23
a卖出第： 23 还剩下：22
a卖出第： 22 还剩下：21
a卖出第： 21 还剩下：20
a卖出第： 20 还剩下：19
a卖出第： 19 还剩下：18
a卖出第： 18 还剩下：17
a卖出第： 17 还剩下：16
a卖出第： 16 还剩下：15
a卖出第： 15 还剩下：14
a卖出第： 14 还剩下：13
a卖出第： 13 还剩下：12
a卖出第： 12 还剩下：11
a卖出第： 11 还剩下：10
a卖出第： 10 还剩下：9
a卖出第： 9 还剩下：8
a卖出第： 8 还剩下：7
a卖出第： 7 还剩下：6
a卖出第： 6 还剩下：5
a卖出第： 5 还剩下：4
a卖出第： 4 还剩下：3
a卖出第： 3 还剩下：2
a卖出第： 2 还剩下：1
a卖出第： 1 还剩下：0从运行结果可以看出：大部分情况下都是某一个线程进入同步代码块。这样大大减少了用户态切换到内核态的次数 (synchronized锁是重量级锁，设计底层操作系统，会从用户态切换为内核态。而通过偏锁优化以后，同一个线程再次进入该同步代码块时，不需要再次加锁和释放锁)！提高程序性能！
结论
HotSpot的作者经过研究发现，大多数情况下：
在多线程情况下，锁不仅不存在多线程竞争，还存在由同一个线程多次获得的情况，偏向锁就是在这种情况下出现的，它的出现是为了解决只有一个线程执行同步时提高性能。
偏向锁会偏向于第一个访问锁的线程，如果在接下来的运行过程中，该锁没有被其他线程访问，则持有偏向锁的线程将永远不需要触发同步。也即偏向锁在资源在没有竞争情况下消除了同步语句，懒得连CAS操作都不做了，直接提高程序性能。
3.4.2 偏向锁的持有
理论落地：
在实际应用运行过程中发现，“锁总是同一个线程持有，很少发生竞争”，也就是说锁总是被第一个占用他的线程拥有，这个线程就是锁的偏向线程。
那么只需要在锁第一次被拥有的时候，记录下偏向线程ID。这样偏向线程就一直持有着锁(后续这个线程进入和退出这段加了同步锁的代码块时，不需要再次加锁和释放锁。而是直接会去检查锁的MarkWord里面是不是放的自己的线程ID)。
判断当前线程ID和偏向锁记录的ID是否相等：
1.如果相等，表示偏向锁是偏向于当前线程的，就不需要再尝试获得锁了，直到竞争发生才释放锁。以后每次同步，检查锁的偏向线程[D与当前线程1D是否一致，如果一致直接进入同步。无需每次加锁解锁都去CAS更新对象头。如果自始至终使用锁的线程只有一个，很明显偏向锁几乎没有额外开销，性能极高。
2.如果不等，表示发生了竞争，锁己经不是总是偏向于同一个线程了，这个时候会尝试使用CAS来替换MarkWord里面的线程ID为新线程的ID，
- 竞争成功，表示之前的线程不存在了，MarkWord里面的线程1D为新线程的ID，锁不会升级，仍然为偏向锁；
- 竞争失败，说明当前锁还是被其他线程持有。需要升级变为轻量级锁，才能保证线程间公平竞争锁。（偏向锁 ——>(升级为) 轻量级锁）
注意，偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，线程是不会主动释放偏向锁的。技术实现：
一个synchronized方法被一个线程抢到了锁时，那这个方法所在的对象就会在其所在的Mark Word中将偏向锁修改状态位，同时还会占用前54位来存储县城指针作为标识。若该线程再次访问同一个synchronized方法时，该线程只需要去对象头的Mark Word中去判断一下是否有偏向锁指向本身的ID，无需再进入Monitor去竞争对象了。
偏向锁用54位存放线程指针以确定是哪个线程占有了锁。
3.4.3 细化Account对象举例说明
结论：JVM不用和操作系统协商设置Mutex（争取内核，内核态的切换），它只需要记录下线程ID就标识自己获得了当前锁，不用操作系统接入。
偏向锁的操作不用直接捅到操作系统，不涉及用户到内核转换，不必要直接升级为最高级，我们以一个account对象的“对象头”为例
假如有一个线程执行到synchronized代码块的时候，JVM使用CAS操作把线程指针ID记录到Mark Word当中，并修改偏向锁位，标识当前线程就获得该锁，锁对象变成偏向锁（通过CAS修改对象头里的锁标志位），字面意思是“偏向于第一个获得它的线程”的锁。执行完同步代码块后，线程并不会主动释放偏向锁。
这时线程获得了锁，可以执行同步代码块。当该线程第二次到达同步代码块时会判断此时持有锁的线程是否还是自己（持有锁的线程ID也在对象头里）。JVM通过account对象的Mark Word判断：当前线程ID还在，说明还持有着这个对象的锁，就可以继续进入临界区工作。由于之前没有释放锁，这里也就不需要重新加锁。如果自始至终使用锁的线程只有一个，很明显偏向锁几乎没有额外开销，性能极高。
结论：JVM不用和操作系统协商设置Mutex（争取内核），它只需要记录下线程ID就表示自己获得了当前锁，不用操作系统介入
上述就是偏向锁：在没有其它线程竞争的时候，一直偏向当前线程，当前线程可以一直执行
3.4.4 偏向锁JVM命令
java -XX:+PrintFlagsInitial |grep BiasedLock*
- 偏向锁存在且默认开启（图片里最后一行的false），并且有4s延迟（图片里的4000）
重要参数说明
- 关于如何开启偏向锁（延迟设置为0即可）和关闭偏向锁
实际上偏向锁在JDK1.6之后是款认开启的，但是启动时间有延迟，
所以需要添加参数-XX:BiasedLockingStartupDelay=0，让其在程序启动时立刻启动。
开启偏向锁：
-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0
关闭偏向锁：关闭之后程序默认会直接进入 ----------------------->>>>>>> 轻量级锁状态
-XX:-UseBiasedLocking
Code演示-通过将延迟改为0来开启偏向锁
- 演示无效果，偏向锁本应该是101，000是轻量级锁（无效是因为有4s延迟，程序直接变成了轻量级锁）
因为参数系统默认开启
说明：默认情况下，jvm会延迟4s再开启偏向锁。这就说明，虚拟机刚启动时，是没有偏向锁的，就会自动升级为轻量级锁。
关闭延迟参数，启用该功能
Code演示2-主动迎合这4秒的延迟
第一种情况-没用synchronized
- 确实开启了偏向锁101，但是o对象未采用synchronized加锁，所以线程id是空的
第二种情况- 用synchronized
- 使用synchronized锁住o之后，发现这五十四位指向了当前线程指针
可以发现，当使用了synchronized以后，对象o记录了当前持有锁的线程。
3.4.5 偏向锁 升级为 轻量级锁
首先我们知道：当只有一个线程使用锁资源，没有人跟他争抢锁的时候，这个锁对象的锁状态是：偏向锁。
现在偏向锁的好日子到头了，另一个线程尝试获取锁。锁对象保存了之前线程的ID，和当前尝试获取锁的线程ID进行对比：
- 如果相等那还好说，说明锁就是当前线程的。还是偏向锁，直接进入就行。
- 问题就怕不是同一个线程！发生了竞争。这时候当前尝试获取锁的线程如果争抢成功，说明之前持有锁的线程不在了，当前线程成功获取锁。
- 但如果当前线程发现还是有线程持有锁，这个锁就会从偏向锁升级为轻量级锁。以确保线程公平竞争锁。
偏向锁的撤销
-
当有另外线程逐步来竞争所的时候，就不能再使用偏向锁了，要升级为轻量级锁
-
竞争线程尝试CAS更新对象头失败，会等待到全局安全点（stop-the-world 此时不会执行任何代码）撤销偏向锁
偏向锁使用一种等到竞争出现才释放锁的机制 (因为这个时候要发生锁升级了)，只有当其他线程竞争锁时，持有偏向锁的原来线程才会被撤销。
撇销需要等待全局安全点(该时间点上没有字节码正在执行)，同时检查持有偏向锁的线程是否还在执行：
① 第一个线程正在执行synchronized方法(处于同步块)，它还没有执行完，其它线程来抢夺，该偏向锁会被取消掉并出现锁升级。此时轻量级锁由原持有偏向锁的线程持有，继续执行其同步代码，而正在竞争的线程会进入自旋等待获得该轻量级锁。
②第一个线程执行完成synchronized方法(退出同步块)，则将对象头设置成无锁状态并撤销偏向锁，重新偏向。（锁又成了无主状态，所有线程公平竞争）
3.4.6 总体步骤流程图示
题外话
Java15逐步废弃偏向锁，需要手动开启。因为偏向锁开销大，废成本
3.5 轻量锁
轻量锁使用场景：多线程竞争，但是任意时刻最多只有一个线程竞争，即不存在锁竞争太过激烈的情(竞争太激烈就要升级为重量级锁了)，也就没有线程阻寨
3.5.1 主要作用
-
有线程来参与锁的竞争，但是获取锁的冲突时间极短
-
本质就是自旋锁CAS
3.5.2 轻量级锁的获取
- 轻量级锁是为了在线程近乎交替执行同步块时提高性能。
- 近乎交替指的是：两个线程轮流获取锁，线程a刚释放锁，线程b恰好来获取锁，线程b刚释放锁，线程a恰好来获取锁。两个线程基本上没有竞争锁的情况。
主要目的：
- 在没有多线程竞争的前提下，通过CAS减少重量级锁使用操作系统互斥量产生的性能消耗．说白了先自旋，不行才升级阻塞。
3.5.3 偏向锁升级为轻量锁的时机：
- 当关闭偏向锁功能或多线程竞争偏向锁会导致偏向锁升级为轻量级锁
- 假如线程A己经拿到锁，这时线程B又来抢该对象的锁，由于该对象的锁己经被线程A拿到，当前该锁己是偏向锁了。
- 而线程B在争抢时发现对象头Mark中的线程ID不是线程B自己的线程ID(而是线程A)，那线程B就会进行CAS操作希望能获得锁。此吋线程B操作中有两种情况：
- 如果锁获取成功，直接替换Mark Word中的线程ID为B自己的ID(A—B)．重新偏向于其他线程(即将偏向锁交给其他线程，相当于当前线程"被"释放了锁)，该锁会保持偏向锁状态，A线程Over，B线程上位：
- 如果锁获取失败，则偏向锁升级为轻量级锁(设置偏向锁标识为0并设置锁标志位为00)，此时轻量级锁由原持有偏向锁的线程持有，继续执行其同步代码，而正在竞争的线程B会进入自旋等待获得该轻量级锁。
3.5.4 轻量级锁的加锁
JVM会为每个线程在当前线程的栈帧中创建用于存储锁记录的空间，官方称为Displaced Mark Word。若一个线程获得锁时发现是轻量级锁，会把锁的MarkWord(锁本质还是一个对象，当然有MarkWord)复制到自己的Dispaced Mark Word里面。然后线程尝试用CAS将锁的Mark Word替换为指向锁记录的指针。如果成功，当前线程获得锁，如果失败，表示Mark Word已经被替换成了其他线程的锁记录，说明在与其它线程竞争锁，当前线程就尝试使用自旋来获取锁。
自旋CAS：不断尝试去获取锁，能不升级就不往上捅，尽量不要阻塞
3.5.5 轻量级锁的释放
在释放锁时，当前线程会使用CAS操作将Displaced Mark Word的内容复制回锁的Mark Word里面。如果没有发生竞争，那么这个复制的操作会成功。如果有其他线程因为自旋多次导致轻量级锁升级成了重量级锁，那么CAS操作会失败，此时会释放锁并唤醒被阻塞的线程。
3.5.6 轻量级锁升级重量锁的情况
步骤流程图示
- 轻量级锁状态下，CAS自旋达到一定次数也会升级为重量级锁
自适应自旋锁的大致原理
Java6之后是自适应自旋锁
自适应意味着自旋的次数不是固定不变的，而是根据同一个锁上次自旋的时间、拥有锁线程的状态来决定
- 线程如果自旋成功了，那下次自旋的最大次数会增加，因为JVM认为既然上次成功了，那么这一次也大概率会成功
- 如果很少会自旋成功，那么下次会减少自旋的次数甚至不自旋，避免CPU空转
总之，自适应意味着自选的次数不是固定不变的，而是根据：同一个锁上一次自旋的时间和拥有锁线程的状态来决定。
3.5.7 轻量锁和偏向锁的区别
- 争夺轻量锁失败时，自旋尝试抢占锁
- 轻量级锁每次退出同步块都需要释放锁，而偏向锁是在竞争发生时才释放锁
3.6 重量锁
使用场景：
- 有大量线程参与锁的竞争，冲突性很高
64位对象标记图
重量级锁的原理
Java中synchronized的重量级锁，是基于进入和退出Monitor对象实现的。在编译时会将同步块的开始位置插入monitor enter指令，在结束位置插入monitor exit指令
当线程执行到monitor enter指令时，会尝试获取对象所对应的Monitor所有权，如果获取到了，即获取到了锁，会在Monitor的owner中存放当前线程的id，这样它将处于锁定状态，除非退出同步块，否则其他线程无法获取到这个Monitor
Code演示
package com.bilibili.juc.syncup;
import org.openjdk.jol.info.ClassLayout;
public class SynchronizedUpDemo5 {
private static Object objectLock = new Object();
public static void main(String[] args) {
new Thread(() -> {
synchronized (objectLock) {
System.out.println(ClassLayout.parseInstance(objectLock).toPrintable());
}
}, "t1").start();
new Thread(() -> {
synchronized (objectLock) {
System.out.println(ClassLayout.parseInstance(objectLock).toPrintable());
}
}, "t2").start();
new Thread(() -> {
synchronized (objectLock) {
System.out.println(ClassLayout.parseInstance(objectLock).toPrintable());
}
}, "t3").start();
new Thread(() -> {
synchronized (objectLock) {
System.out.println(ClassLayout.parseInstance(objectLock).toPrintable());
}
}, "t4").start();
}
}
输出结果：
java.lang.Object object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) fa 45 dd ab (11111010 01000101 11011101 10101011) (-1411561990)
4 4 (object header) cb 01 00 00 (11001011 00000001 00000000 00000000) (459)
8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
12 4 (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
java.lang.Object object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) fa 45 dd ab (11111010 01000101 11011101 10101011) (-1411561990)
4 4 (object header) cb 01 00 00 (11001011 00000001 00000000 00000000) (459)
8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
12 4 (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
java.lang.Object object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) fa 45 dd ab (11111010 01000101 11011101 10101011) (-1411561990)
4 4 (object header) cb 01 00 00 (11001011 00000001 00000000 00000000) (459)
8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
12 4 (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
java.lang.Object object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) fa 45 dd ab (11111010 01000101 11011101 10101011) (-1411561990)
4 4 (object header) cb 01 00 00 (11001011 00000001 00000000 00000000) (459)
8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
12 4 (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
可以看到最后两位是10，是重量级锁
3.7 小总结
复习一下锁指向：
- 偏向锁：MarkWord存储的是偏向的线程ID
- 轻量锁：MarkWord存储的是指向线程栈中LockRecord的指针
- 重量锁：MarkWord存储的是指向堆钟的monitor对象的指针
还是这张图：
现在提出一个问题：
- 在无锁状态下，MarkWord中有31位保存了hashcode。但我们可以看到，锁升级为轻量锁或重量锁之后，MarkWord中保存的分别是线程栈帧里的锁记录指针和重量级锁指针，已经没有位置再保存hashcode，GC年龄了。现在问题来了：这些信息哪去了？
上面这段话的翻译：
1.在无锁状态下，Mark Word中可以存储对象的identity hash code值。当对象的hashCode()方法第一次被调用时，JVM会生成对应的dentity hash code值并将该值存储到Mark Word中
2.对于偏向锁，在线程获取偏向锁时，会用Thread ID和epoch值覆盖identity hash code所在的位置。如果一个对象的hashCode()方法已经被调用过一次之后，这个对象不能被设置偏向锁。因为如果可以的话，那Mark Word中的identity hash code必然会被偏向线程Id给覆盖，这就会造成同一个对象前后两次调用hashCode()方法得到的结果不一致
ps：这里我也想过一个问题，为啥不额外开辟一点空间存储hashcode和GC年龄，而是要用线程ID把这部分给覆盖掉？为什么线程ID不能只使用无锁情况下未使用的25位？
我通过查询资料，感觉应该是：
1.偏向锁不使用额外空间记录信息是为了保持设计的紧凑性和低成本，适用于没有竞争的场景。而轻量级锁和重量级锁之所以使用额外空间，是因为它们需要处理更多的同步场景和竞争情况。偏向锁膨胀为重量级锁是为了保证哈希码的一致性和正确性，即使这意味着需要放弃偏向锁的性能优势。因此偏向锁不会额外使用空间存储hashcode等信息，而是直接覆盖。
2.从而导致偏向锁和hashcode()方法不共存。因为如果共存，由于线程ID把hashcode覆盖了，hashcode()方法获取的就是线程ID中的一部分了(刚刚解释了为什么线程ID会覆盖hashcode)
3.升级为轻量级锁时，JVM会在当前线程的栈帧中创建一个锁记录（Lock Record）空间，用于存储对象的Mark Word拷贝，该拷贝中可以包含identity hash code，所以轻量级锁可以和identity hash code共存，哈希码和GC年龄自然保存在此，释放锁后会将这些信息写回到对象头
4.升级为重量级锁后，Mark Word保存的重量级锁指针，代表重量级锁的ObiectMonitor类里有字段记录非加锁状态下的Mark Word，锁释放后也会将信息写回到对象头
总之：轻量级锁和重量级锁都有额外的空间记录MarkWord，当调用hashCode时，偏向锁会膨胀为重量锁
代码验证
情况1：
- 当一个对象已经计算过identity hash code，它就无法进入偏向锁状态，跳过偏向锁，直接升级轻量级锁
import org.openjdk.jol.info.ClassLayout;
import java.util.concurrent.TimeUnit;
public class SynchronizedUpDemo6 {
public static void main(String[] args) {
// 先睡眠5s，保证开启偏向锁
try {
TimeUnit.SECONDS.sleep(5);
} catch (InterruptedException e) {
e.printStackTrace();
}
Object o = new Object();
System.out.println("本应是偏向锁");
System.out.println(ClassLayout.parseInstance(o).toPrintable());
// 没有重写一致性哈希，重写后无效
// 当一个对象已经计算过identity hash code，它就无法进入偏向锁状态
o.hashCode();
synchronized (o) {
System.out.println("本应是偏向锁，但是由于计算过一致性哈希，会直接升级为轻量级锁");
System.out.println(ClassLayout.parseInstance(o).toPrintable());
}
}
}
输出结果：
本应是偏向锁
java.lang.Object object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 05 00 00 00 (00000101 00000000 00000000 00000000) (5)
4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0)
8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
12 4 (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
本应是偏向锁，但是由于计算过一致性哈希，会直接升级为轻量级锁
java.lang.Object object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 28 f7 1f 9a (00101000 11110111 00011111 10011010) (-1709181144)
4 4 (object header) c7 00 00 00 (11000111 00000000 00000000 00000000) (199)
8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
12 4 (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
可以看到原先是101（偏向锁），执行了o.hashCode()后，变成了00（轻量级锁）
情况2：
- 在偏向锁的状态中遇到一致性哈希计算请求，立马撤销偏向模式，膨胀为重量级锁
package com.bilibili.juc.syncup;
import org.openjdk.jol.info.ClassLayout;
import java.util.concurrent.TimeUnit;
public class SynchronizedUpDemo6 {
public static void main(String[] args) {
// 先睡眠5s，保证开启偏向锁
try {
TimeUnit.SECONDS.sleep(5);
} catch (InterruptedException e) {
e.printStackTrace();
}
Book book = new Book("Java");
System.out.println("本应是偏向锁");
System.out.println(ClassLayout.parseInstance(book).toPrintable());
// 重写后无效，还是偏向锁
book.hashCode();
synchronized (book) {
System.out.println("本应是偏向锁，由于计算过一致性哈希，且hashCode()方法被重写了，还是偏向锁");
System.out.println(ClassLayout.parseInstance(book).toPrintable());
}
}
}
class Book {
private String name;
public Book(String name) {
this.name = name;
}
@Override
public int hashCode() {
return name.hashCode();
}
}
输出结果：
本应是偏向锁
com.bilibili.juc.syncup.Book object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 05 00 00 00 (00000101 00000000 00000000 00000000) (5)
4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0)
8 4 (object header) 92 c3 00 f8 (10010010 11000011 00000000 11111000) (-134167662)
12 4 java.lang.String Book.name (object)
Instance size: 16 bytes
Space losses: 0 bytes internal + 0 bytes external = 0 bytes total
本应是偏向锁，由于计算过一致性哈希，且hashCode()方法被重写了，还是偏向锁
com.bilibili.juc.syncup.Book object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 05 98 4e 54 (00000101 10011000 01001110 01010100) (1414436869)
4 4 (object header) 5f 02 00 00 (01011111 00000010 00000000 00000000) (607)
8 4 (object header) 92 c3 00 f8 (10010010 11000011 00000000 11111000) (-134167662)
12 4 java.lang.String Book.name (object)
Instance size: 16 bytes
Space losses: 0 bytes internal + 0 bytes external = 0 bytes total
可以看到原先是101（偏向锁），执行了o.hashCode()后，但是hashCode()方法被重写了，还是101（偏向锁），因为重写了hashCode()方法后，获取的不是这个锁对象的hashcode，而是属性name的hashcode，本质上还是未计算过这个对象的identity hash code
情况3：
- 偏向锁过程中遇到一致性哈希计算请求，立马撤销偏向模式，膨胀未重量级锁
package com.bilibili.juc.syncup;
import org.openjdk.jol.info.ClassLayout;
import java.util.concurrent.TimeUnit;
public class SynchronizedUpDemo7 {
public static void main(String[] args) {
// 先睡眠5s，保证开启偏向锁
try {
TimeUnit.SECONDS.sleep(5);
} catch (InterruptedException e) {
e.printStackTrace();
}
Object o = new Object();
System.out.println("本应是偏向锁");
System.out.println(ClassLayout.parseInstance(o).toPrintable());
synchronized (o) {
o.hashCode();
System.out.println("偏向锁过程中遇到一致性哈希计算请求，立马撤销偏向模式，膨胀为重量级锁");
System.out.println(ClassLayout.parseInstance(o).toPrintable());
}
}
}
输出结果：
本应是偏向锁
java.lang.Object object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 05 00 00 00 (00000101 00000000 00000000 00000000) (5)
4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0)
8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
12 4 (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
偏向锁过程中遇到一致性哈希计算请求，立马撤销偏向模式，膨胀为重量级锁
java.lang.Object object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) ca 4f 5f 1c (11001010 01001111 01011111 00011100) (476008394)
4 4 (object header) f4 01 00 00 (11110100 00000001 00000000 00000000) (500)
8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
12 4 (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
3.7.2 锁优缺点对比
3.7.3 synchronized锁升级和实现原理
synchronized锁升级过程总结：一句话，就是先自旋，不行再阻塞。
实际上是把之前的悲观锁（重量级锁）变成在一定条件下使用偏向锁以及使用轻量级（自旋锁CAS）的形式
synchronized在修饰方法和代码块在字节码上实现方式有很大差异，但是内部实现还是基于对象头的MarkWord来实现的。
JDK1.6之前synchronized使用的是重量级锁，JDK1.6之后进行了优化，拥有了无锁->偏向锁->轻量级锁->重量级锁的升级过程，而不是无论什么情况都使用重量级锁。
- 偏向锁：适用于单线程适用的情况，在不存在锁竞争的时候进入同步方法/代码块则使用偏向锁。
- 轻量级锁：适用于竞争较不激烈的情况(这和乐观锁的使用范围类似)，存在竞争时升级为轻量级锁，轻量级锁采用的是自旋锁，如果同步方法/代码块执行时间很短的话，采用轻量级锁虽然会占用cpu资源但是相对比使用重量级锁还是更高效。
- 重量级锁：适用于竞争激烈的情况，如果同步方法/代码块执行时间很长，那么使用轻量级锁自旋带来的性能消耗就比使用重量级锁更严重，这时候就需要升级为重量级锁。
4 JIT编译器对锁的优化
JIT：Just In Time Compiler，一般翻译为即时编译器
4.1 锁消除
从JIT角度看相当于无视它，synchronized(o)不存在了，
这个锁对象并没有被共用扩散到其它线程使用，
极端的说就是根本没有加这个锁对象的底层机器码，消除了锁的使用
4.2 锁粗化
假如方法中首位相接，前后相邻的都是同一个锁对象，那JIT编译器就会把这几个synchronized块合并成一个大块，
加粗加大范围，一次申请使用即可，避免次次都申请和释放锁，提升了性能
1199
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
