本文详细探讨了Java中的Synchronized锁的优化历程，从无锁、偏向锁、轻量级锁到重量级锁的升级过程。在Java6之后，为了提高性能，引入了偏向锁和轻量级锁，减少了锁操作的开销。文章解释了不同锁的工作原理，如偏向锁在单线程环境下提高效率，轻量级锁通过自旋避免阻塞，以及在竞争激烈时如何升级为重量级锁。此外，还提到了JIT编译器对锁的优化策略，如锁消除和锁粗化。
目录
8.1.1 当一个对象已经计算过hashcode，它无法进入偏向锁状态，直接升级为轻量级锁
8.1.2 偏向锁过程中遇到hashcode计算，立马撤销偏向模式，膨胀为重量级锁
1、Synchronized 锁优化的背景
用锁能够实现数据的安全性，但是会带来性能下降。
无锁能够基于线程并行提升程序性能，但是会带来安全性下降。
我们能不能不出现这中非黑即白的情况，中间需要一个缓冲过程，所以锁也需要这样一个升级的过程。也就是说在安全性和性能中找一个折中方案
1.1 synchronized是如何做到锁升级的
由对象头中的Mark Word根据锁标志位的不同而被复用及锁升级策略。
2、Synchronized的性能变化
2.1 java6之前
只有无锁和重量级锁之间的转换，假如锁的竞争比较激烈的话，性能下降(因为重量级锁会出现用户态到内核态直接的切换)
java的线程是映射到操作系统原生线程之上的，如果要阻塞或唤醒一个线程就需要操作系统介入，需要在户态与核心态之间切换，这种切换会消耗大量的系统资源，因为用户态与内核态都有各自专用的内存空间，专用的寄存器等，用户态切换至内核态需要传递给许多变量、参数给内核，内核也需要保护好用户态在切换时的一些寄存器值、变量等，以便内核态调用结束后切换回用户态继续工作。
在Java早期版本中，synchronized属于重量级锁，效率低下，因为监视器锁（monitor）是依赖于底层的操作系统的Mutex Lock来实现的，挂起线程和恢复线程都需要转入内核态去完成，阻塞或唤醒一个Java线程需要操作系统切换CPU状态来完成，这种状态切换需要耗费处理器时间，如果同步代码块中内容过于简单，这种切换的时间可能比用户代码执行的时间还长”，时间成本相对较高，这也是为什么早期的synchronized效率低的原因 Java 6之后，为了减少获得锁和释放锁所带来的性能消耗，引入了轻量级锁和偏向锁
2.2 为什么每一个对象都可以成为一个锁
markOop.hpp
Monitor可以理解为一种同步工具，也可理解为一种同步机制，常常被描述为一个Java对象。Java对象是天生的Monitor，每一个Java对象都有成为Monitor的潜质，因为在Java的设计中 ，每一个Java对象自打娘胎里出来就带了一把看不见的锁，它叫做内部锁或者Monitor锁。
Monitor的本质是依赖于底层操作系统的Mutex Lock实现，操作系统实现线程之间的切换需要从用户态到内核态的转换，成本非常高。
Monitor(监视器锁)
Jvm中的同步就是基于进入和退出管程(Monitor)对象实现的。每个对象实例都会有一个Monitor，Monitor可以和对象一起创建、销毁。Monitor是由ObjectMonitor实现，而ObjectMonitor是由C++的ObjectMonitor.hpp文件实现
Mutex Lock
Monitor是在jvm底层实现的，底层代码是c++。本质是依赖于底层操作系统的Mutex Lock实现，操作系统实现线程之间的切换需要从用户态到内核态的转换，状态转换需要耗费很多的处理器时间成本非常高。所以synchronized是Java语言中的一个重量级操作。
Monitor与java对象以及线程是如何关联 ？
1.如果一个java对象被某个线程锁住，则该java对象的Mark Word字段中LockWord指向monitor的起始地址
2.Monitor的Owner字段会存放拥有相关联对象锁的线程id
Mutex Lock 的切换需要从用户态转换到核心态中，因此状态转换需要耗费很多的处理器时间。
2.3 java6开始，优化Synchronized
Java 6之后，为了减少获得锁和释放锁所带来的性能消耗，引入了轻量级锁和偏向锁
需要有个逐步升级的过程，别一开始就捅到重量级锁。
3、Synchronized锁种类及升级步骤
3.1 多线程访问的几种情况
1）只有一个线程来访问，有且唯一Only One
2）有2个线程A、B来交替访问
3）竞争激烈，多个线程来访问
3.2 升级流程
Synchroinized用的锁是存在Java对象头里的Mark Work中，锁升级功能主要依赖MarkWork中锁标志位和释放偏向锁标志位
4、无锁
public class NoLock {
public static void main(String[] args) {
Object o = new Object();
// o.hashCode() 调用后对象头才会记录，如果没有调用对象头中是没有的
System.out.println("10进制hash码："+o.hashCode());
System.out.println("16进制hash码："+Integer.toHexString(o.hashCode()));
System.out.println("2进制hash码："+Integer.toBinaryString(o.hashCode()));
System.out.println(ClassLayout.parseInstance(o).toPrintable());
}
}
01 5e 55 a4 (00000001 01011110 01010101 10100100) (-1537909247)
41 00 00 00 (01000001 00000000 00000000 00000000) (65)
真实顺序: 00000000 00000000 00000000 01000001 10100100 01010101 01011110 00000001
hash: 前25位无用 1000001 10100100 01010101 010111105、 偏向锁
5.1 什么是偏向锁
偏向锁：单线程竞争
当线程A第一次竞争到锁时，通过操作修改Mark Word中的偏向线程ID、偏向模式。
如果不存在其他线程竞争，那么持有偏向锁的线程永远不需要进行同步。
5.2 主要作用
当一段同步代码一直被同一个线程多次访问，由于只有一个线程那么该线程在后续访问时便会自动获取锁。
现实案例：
一个饭店，同一个老顾客来访，直接说老规矩就可以知道该顾客要吃什么了
public class SaleTicketDemo {
public static void main(String[] args) {
Ticket ticket = new Ticket();
new Thread(() -> {
for(int i = 0; i < 55; i++){
ticket.sale();
}
},"t1").start();
new Thread(() -> {
for(int i = 0; i < 55; i++){
ticket.sale();
}
},"t2").start();
new Thread(() -> {
for(int i = 0; i < 55; i++){
ticket.sale();
}
},"t3").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);
}
}
}
}看以下结果：大部分票都是由t1卖出的
t1卖出第： 50 还剩下：49
t1卖出第： 49 还剩下：48
t2卖出第： 48 还剩下：47
t2卖出第： 47 还剩下：46
t2卖出第： 46 还剩下：45
t2卖出第： 45 还剩下：44
t2卖出第： 44 还剩下：43
t2卖出第： 43 还剩下：42
t2卖出第： 42 还剩下：41
t2卖出第： 41 还剩下：40
t2卖出第： 40 还剩下：39
t1卖出第： 39 还剩下：38
t1卖出第： 38 还剩下：37
t1卖出第： 37 还剩下：36
t1卖出第： 36 还剩下：35
t1卖出第： 35 还剩下：34
t1卖出第： 34 还剩下：33
t1卖出第： 33 还剩下：32
t1卖出第： 32 还剩下：31
t1卖出第： 31 还剩下：30
t1卖出第： 30 还剩下：29
t1卖出第： 29 还剩下：28
t1卖出第： 28 还剩下：27
t1卖出第： 27 还剩下：26
t1卖出第： 26 还剩下：25
t1卖出第： 25 还剩下：24
t1卖出第： 24 还剩下：23
t1卖出第： 23 还剩下：22
t1卖出第： 22 还剩下：21
t1卖出第： 21 还剩下：20
t1卖出第： 20 还剩下：19
t1卖出第： 19 还剩下：18
t1卖出第： 18 还剩下：17
t1卖出第： 17 还剩下：16
t1卖出第： 16 还剩下：15
t1卖出第： 15 还剩下：14
t1卖出第： 14 还剩下：13
t1卖出第： 13 还剩下：12
t1卖出第： 12 还剩下：11
t1卖出第： 11 还剩下：10
t1卖出第： 10 还剩下：9
t1卖出第： 9 还剩下：8
t1卖出第： 8 还剩下：7
t1卖出第： 7 还剩下：6
t1卖出第： 6 还剩下：5
t1卖出第： 5 还剩下：4
t1卖出第： 4 还剩下：3
t1卖出第： 3 还剩下：2
t1卖出第： 2 还剩下：1
t1卖出第： 1 还剩下：0Hotstop的作者经过研究发现，大多数情况下：
多线程的情况下，锁不仅不存在多线程竞争，还存在锁由同一个线程多次获得的情况，偏向锁就是在这种情况下出现的，它的出现是为了解决只有在一个线程执行同步时提高性能。
备注：偏向锁会偏向于第一个访问锁的线程，如果在接下来的运行过程中，该锁没有被其他的线程访问，则持有偏向锁的线程将永远不需要触发同步。也即偏向锁在资源没有竞争情况下消除了同步语句，懒的连CAS操作都不做了，直接提高程序性能。
5.3 偏向锁持有
落地理论：
在实际应用运行过程中发现，"锁总是同一个线程持有，很少发生竞争"，也就是说锁总是被第一个占用他的线程拥有，这个线程就是锁的偏向线程。
那么只需要在锁第一次被拥有的时候，记录下偏向线程ID。这样偏向线程就一直持有着锁(后续这个线程进入和退出这段加了同步锁的代码块时，不需要再次加锁和释放锁。而是直接会去检查锁的对象头(MarkWord)里面是不是放的自己的线程ID)。
如果相等：表示偏向锁是偏向于当前线程的，就不需要再尝试获得锁了，直到竞争发生才释放锁。以后每次同步，检查锁的偏向线程ID与当前线程ID是否一致，如果一致直接进入同步。无需每次加锁解锁都去CAS更新对象头。如果自始至终使用锁的线程只有一个，很明显偏向锁几乎没有额外开销，性能极高。
如果不等：表示发生了竞争，锁已经不是总是偏向于同一个线程了，这时候会尝试使用CAS来替换MarkWord里面的线程ID为新线程的ID，
竞争成功：表示之前的线程不存在了，MarkWord里面的线程ID为新线程的ID，锁不会升级，认为偏向锁
竞争失败：这时候可能需要升级为轻量级锁，才能保证线程间公平竞争锁
注意：偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，线程是不会主动释放偏向锁的
技术实现：
一个synchronized方法被一个线程抢到了锁时，那这个方法所在的对象就会在其所在的Mark Word中将偏向锁修改状态位，同时还 会有占用前54位来存储线程指针作为标识。若该线程再次访问同一个synchronized方法时，该线程只需去对象头的Mark Word 中去判断一下是否有偏向锁指向本身的ID，无需再进入 Monitor 去竞争对象了。
案例说明：
偏向锁的操作不用直接捅到操作系统，不涉及用户到内核转换，不必要直接升级为最高级，我们以一个account对象的"对象头"为例。
假如有一个线程执行到synchronized代码块的时候，JVM使用CAS操作把线程指针ID记录到Mark Word当中，并修改标偏向标示，标示当前线程就获得该锁。锁对象变成偏向锁（通过CAS修改对象头里的锁标志位），字面意思是“偏向于第一个获得它的线程”的锁。执行完同步代码块后，线程并不会主动释放偏向锁。
这时线程获得了锁，可以执行同步代码块。当该线程第二次到达同步代码块时会判断此时持有锁的线程是否还是自己（持有锁的线程ID也在对象头里），JVM通过account对象的Mark Word判断：当前线程ID还在，说明还持有着这个对象的锁，就可以继续进入临界区工作。由于之前没有释放锁，这里也就不需要重新加锁。 如果自始至终使用锁的线程只有一个，很明显偏向锁几乎没有额外开销，性能极高。
结论：JVM不用和操作系统协商设置Mutex(争取内核)，它只需要记录下线程ID就标示自己获得了当前锁，不用操作系统接入。
上述就是偏向锁：在没有其他线程竞争的时候，一直偏向偏心当前线程，当前线程可以一直执行。
5.4 代码体现
5.4.1 查看偏向锁信息
# 查看偏向锁信息
java -XX:+PrintFlagsInitial |grep BiasedLock*
立刻看到偏向锁的效果：
1、配置jvm运行参数
-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0
2、程序延迟4s执行
如果不执行上述情况，或者关闭偏向锁(-XX:-UseBiasedLocking)会直接进入轻量级锁
public class BiasedLockDemo {
@SneakyThrows
public static void main(String[] args) {
// 进入偏向锁 或修改jvm运行参数 -XX:BiasedLockingStartupDelay=0
Thread.sleep(5000);
Object objectLock = new Object();
System.out.println(ClassLayout.parseInstance(objectLock).toPrintable());
System.out.println("=======================================================");
synchronized (objectLock){
System.out.println(ClassLayout.parseInstance(objectLock).toPrintable());
}
}
}
5.5 偏向锁撤销(升级到轻量级锁)
偏向锁使用一种等到竞争出现才释放锁的机制，只有当其他线程竞争锁时，持有偏向锁的原来线程才会被撤销。
撤销需要等待全局安全点(该时间点上没有字节码正在执行)，同时检查持有偏向锁的线程是否还在执行：
1) 第一个线程正在执行synchronized方法(处于同步块)，它还没有执行完，其它线程来抢夺，该偏向锁会被取消掉并出现锁升级。此时轻量级锁由原持有偏向锁的线程持有，继续执行其同步代码，而正在竞争的线程会进入自旋等待获得该轻量级锁。
2) 第一个线程执行完成synchronized方法(退出同步块)，则将对象头设置成无锁状态并撤销偏向锁，重新偏向。
5.6 java 15逐步放弃偏向锁
6、轻量级锁
6.1 是什么？
多线程竞争，但是任意时刻最多只有一个线程竞争，即不存在锁竞争太过激烈的情况，也就是没有线程阻塞。
6.2 主要作用与升级过程
有线程来参与锁的竞争，但是获取锁的冲突时间极短。本质就是自旋锁CAS
轻量级锁是为了在线程近乎交替执行同步块时提高性能。
主要目的:在没有多线程竞争的前提下，通过CAS减少重量级锁使用操作系统互斥量产生的性能消耗，说白了先自旋再阻塞。
升级时机:当关闭偏向锁功能或多线程竞争偏向锁会导致偏向锁升级为轻量级锁。
假如线程A已经拿到锁，这时线程B又来抢该对象的锁，由于该对象的锁已经被线程A拿到，当前该锁已是偏向锁了。而线程B在争抢时发现对象头Mark Word中的线程ID不是线程B自己的线程ID(而是线程A)，那线程B就会进行CAS操作希望能获得锁。
此时线程B操作中有两种情况：
如果锁获取成功，直接替换Mark Word中的线程ID为B自己的ID(A → B)，重新偏向于其他线程(即将偏向锁交给其他线程，相当于当前线程"被"释放了锁)，该锁会保持偏向锁状态，A线程Over，B线程上位;
如果锁获取失败，则偏向锁升级为轻量级锁，此时轻量级锁由原持有偏向锁的线程持有，继续执行其同步代码，而正在竞争的线程B会进入自旋等待获得该轻量级锁。
6.3 轻量级锁的加锁
JVM会为每个线程在当前线程的栈帧中创建用于存储锁记录的空间，官方成为Displaced Mark Word。若一个线程获得时发现是轻量级锁，会把锁的MarkWord复制到自己的Displaced Mark Word里面。然后线程尝试用CAS将锁的MarkWord替换为指向锁记录的指针。如果成功，当前线程获得锁，如果失败，表示Mark Word已经被替换成了其他线程的锁记录，说明在其他线程竞争锁，当前线程就尝试使用自旋锁来获取锁。
自旋CAS：不断尝试去获取锁，能不升级就不升级，尽量不要阻塞。
6.4 轻量级锁释放
在释放锁时，当前线程会使用CAS操作将Displaced Mark Word的内容复制回锁的Mark Word里面。如果没有发生竞争，那么这个复制的操作会成功。如果有其他线程因为自旋多次导致轻量级锁升级成了重量级锁，那么CAS操作会失败，此时会释放锁并唤醒被阻塞的线程。
6.5 代码体现
进入轻量级锁：
关闭偏向锁：关闭之后会默认进入轻量级锁 -XX:-UseBiasedLocking
直接运行也可以，只要在4秒内运行完就可以(原因看5.4)
public class LightweightLockDemo {
public static void main(String[] args) {
Object objectLock = new Object();
new Thread(() ->{
synchronized (objectLock){
System.out.println(ClassLayout.parseInstance(objectLock).toPrintable());
}
}).start();
}
}
6.6 轻量级锁如何升级到重量级锁
6.6.1 java6之前
1、默认启用，默认情况下自旋的次数是10次
2、自旋线程数超过cpu核数一半
上述连个条件只要满足一个就升级到重量级锁
6.6.2 java6之后
自适应自旋锁的大致原理
线程如果自旋成功了，那下次自旋的最大次数会增加，因为JVM认为既然上次成功了，那么这一次也有很大概率会成功。反之，如果很少会自旋成功的，那么下次会减少自旋次数甚至不自旋，避免CPU空转。
6.7 偏向锁和轻量级锁的区别
1、争夺轻量级锁失败时，自旋尝试抢占锁
2、轻量级锁每次退出同步块都需要释放锁，而偏向锁时在竞争发生时才释放锁
7、重量级锁
有大量的线程参与锁的竞争，冲突性很高
7.1 重量级锁原理
Java中synchronized的重量级锁，是基于进入和退出Monitor对象实现的。在编译时会将同步块开始的位置插入monitor enter指令，在结束位置插入monitor exit指令。
当线程执行到monitor enter指令时，会尝试获取对象所对应的Monitor所有权，如果获取到了，即获取到了锁，会在Monirot的owner中存放当前线程的id，这样它将处于锁定状态，除非退出同步块，否则其他线程无法获取到这个Monitor。
8、总结
8.1 锁升级后，hashcode等信息去哪里了
在无锁的状态下：
Mark Word中可以存储对象的Hashcode值。当对象的hashCode()方法第一次被调用时，JVM会生成对应的identity hash code值并将该值存储到Mark Word中。
对于偏向锁：
在线程获取偏向锁时，会用ThreadId 和 epoch值覆盖hashcode所在的位置。如果一个对象的hashCode()方法被调用，这个对象不能被设置成偏向锁。如果被覆盖后，会导致hashcode()方法返回的不一致。
对于轻量级锁：
JVM会在当前线程的栈帧中创建一个锁记录(Lock Recode)空间，用于存储锁对象的Mark Word拷贝，该拷贝中可以包含identity hash code，所以轻量级锁可以和hashcode共存，释放锁后会将这些信息写回到对象头。
对于重量级锁：
Mark Word保存的重量级锁指针，重量级锁的ObjectMonitor类里有字段记录非加锁状态下的Mark Word，锁释放后也会将信息写回到对象头。
8.1.1 当一个对象已经计算过hashcode，它无法进入偏向锁状态，直接升级为轻量级锁
8.1.2 偏向锁过程中遇到hashcode计算，立马撤销偏向模式，膨胀为重量级锁
8.2 各种锁的优缺点对比
synchronized锁升级过程总结：一句话，就是先自旋，不行再阻塞。
实际上是把之前的悲观锁(重量级锁)变成在一定条件下使用偏向锁以及使用轻量级(自旋锁CAS)的形式
synchronized在修饰方法和代码块在字节码上实现方式有很大差异，但是内部实现还是基于对象头的MarkWord来实现的。
JDK1.6之前synchronized使用的是重量级锁，JDK1.6之后进行了优化，拥有了无锁->偏向锁->轻量级锁->重量级锁的升级过程，而不是无论什么情况都使用重量级锁。
偏向锁：适用于单线程适用的情况，在不存在锁竞争的时候进入同步方法/代码块则使用偏向锁。
轻量级锁：适用于竞争较不激烈的情况(这和乐观锁的使用范围类似)， 存在竞争时升级为轻量级锁，轻量级锁采用的是自旋锁，如果同步方法/代码块执行时间很短的话，采用轻量级锁虽然会占用cpu资源但是相对比使用重量级锁还是更高效。
重量级锁：适用于竞争激烈的情况，如果同步方法/代码块执行时间很长，那么使用轻量级锁自旋带来的性能消耗就比使用重量级锁更严重，这时候就需要升级为重量级锁。
9、JIT编译器对锁的优化
just in time compiler 一般翻译为即时编译器
9.1 锁消除
/**
* 锁消除
* 从JIT角度看相当于无视它，synchronized (o)不存在了,这个锁对象并没有被共用扩散到其它线程使用，
* 极端的说就是根本没有加这个锁对象的底层机器码，消除了锁的使用
*/
public class LockClearUPDemo
{
static Object objectLock = new Object();//正常的
public void m1()
{
//每个线程new一把锁
//锁消除,JIT会无视它，synchronized(对象锁)不存在了。不正常的
Object o = new Object();
synchronized (o)
{
System.out.println("-----hello LockClearUPDemo"+"\t"+o.hashCode()+"\t"+objectLock.hashCode());
}
}
public static void main(String[] args)
{
LockClearUPDemo demo = new LockClearUPDemo();
for (int i = 1; i <=10; i++) {
new Thread(() -> {
demo.m1();
},String.valueOf(i)).start();
}
}
}
9.2 锁粗化
/**
* 锁粗化
* 假如方法中首尾相接，前后相邻的都是同一个锁对象，那JIT编译器就会把这几个synchronized块合并成一个大块，
* 加粗加大范围，一次申请锁使用即可，避免次次的申请和释放锁，提升了性能
*/
public class LockBigDemo
{
static Object objectLock = new Object();
public static void main(String[] args)
{
new Thread(() -> {
synchronized (objectLock) {
System.out.println("11111");
}
synchronized (objectLock) {
System.out.println("22222");
}
synchronized (objectLock) {
System.out.println("33333");
}
//--------------------------
synchronized (objectLock) {
System.out.println("11111");
System.out.println("22222");
System.out.println("33333");
}
},"a").start();
}
}
883
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
