java八股文面试[多线程]——Synchronized的底层实现原理

怼烎@ 2024-03-24 23:22 83阅读 0赞

笔试：画出Synchronized **线程状态流转**实现原理图

![3029e62c878c4528b093ee9635c15e18.png][]

synchronized关键字解决的是多个线程之间访问资源的同步性，synchronized 翻译为中文的意思是**同步**，也称之为”同步锁“。

synchronized的作用是保证在**同一时刻**， 被修饰的代码块或方法只会有一个线程执行，以达到保证并发安全的效果。

**synchronized关键字可以实现什么类型的锁？**  
　　悲观锁：synchronized关键字实现的是悲观锁，**每次访问**共享资源时都会上锁。  
　　**非公平锁**：synchronized关键字实现的是非公平锁，即线程获取锁的顺序并不一定是按照线程阻塞的顺序。  
　　可重入锁：synchronized关键字实现的是可重入锁，即已经获取锁的线程可以**再次获取**锁。  
　　独占锁或者排他锁：synchronized关键字实现的是**独占锁**，即该锁只能被一个线程所持有，其他线程均被阻塞。

**Synchronized的使用方式**  
主要有3种使用方式:  
![25d66466d9464592b6190ed6c7caa89c.png][]

1.修饰**实例方法**：作用于**当前实例**加锁  
public synchronized void method()\{  
// 代码  
\}

2.修饰**静态方法**：作用于**当前类对象**加锁  
public static synchronized void method()\{  
// 代码  
\}

3.修饰**代码块**：指定加锁对象，对**给定对象**加锁  
synchronized(this)\{  
//代码  
\}

![37749da513894adc8ab6b36fbc885309.png][]

**Synchronized的底层实现**  
synchronized的底层实现是**完全依赖JVM虚拟机**的,所以谈synchronized的底层实现，就不得不谈数据在JVM**内存的存储**：Java对象头，以及Monitor对象监视器。

1.Java对象头  
在JVM虚拟机中，对象在内存中的存储布局，可以分为三个区域:  
对象头(Header)  
实例数据(Instance Data)  
对齐填充(Padding)  
Java对象头主要包括两部分数据：

![ce4ba482fd164798ac739af04045214b.png][]

1)类型指针（Klass Pointer）

是对象指向它的**类元数据的指针**，虚拟机通过这个指针来确定这个对象是**哪个类的实例**;

2)标记字段(Mark Word)

用于存储对象**自身的运行时**数据，如**哈希码**（HashCode）、GC分代**年龄**、**锁状态**标志、**线程持有的锁**、**偏向**线程 ID、偏向时间戳等等,它是实现**轻量级锁**和**偏向锁**的关键.

所以，很明显synchronized使用的锁对象是存储在**Java对象头里**的标记字段里。

2.Monitor

monitor描述为**对象监视器**,可以类比为一个**特殊的房间**，这个房间中有一些被保护的数据，monitor保证**每次只能有一个线程能进入这个房间**进行访问被保护的数据，进入房间即为持有monitor，退出房间即为释放monitor。

使用syncrhoized加锁的同步代码块在**字节码**引擎中执行时，主要就是通过锁对象的**monitor的取用**(monitorenter)与**释放**(monitorexit)来实现的。

首先来看在方法上上锁，我们就新定义一个同步方法然后进行反编译，查看其字节码：

![8c16d9caedd34c9d84392bc0fe8a5570.png][]

![c4c7e9ab669448bfa28c1412aa82bc6e.png][]

可以看到在add方法的flags里面多了一个**`ACC_SYNCHRONIZED`**标志，这标志用来告诉JVM这是一个同步方法，在进入该方法之前**先获取相应的锁**，锁的计数器加1，方法结束后计数器-1，如果获取失败就阻塞住，知道该锁被释放。

从反编译的同步代码块可以看到同步块是由monitorenter指令进入，然后monitorexit释放锁，在执行monitorenter之前需要尝试获取锁，如果这个对象没有被锁定，或者当前线程**已经拥有了这个对象的锁，那么就把锁的计数器加1**。当执行monitorexit指令时，锁的计数器**也会减1**。当获取锁失败时会被阻塞，一直等待锁被释放。

但是为什么会有两个monitorexit呢？其实第二个monitorexit是来**处理异常**的，仔细看反编译的字节码，正常情况下第一个monitorexit之后会执行**`goto`指令**，而该指令转向的就是23行的`return`，也就是说正常情况下只会执行第一个monitorexit释放锁，然后返回。而如果在执行中发生了异常，第二个monitorexit就起作用了，它是由**编译器自动生成的**，在发生异常时处理异常然后释放掉锁。

**3.线程状态流转在Monitor上体现**

当多个线程同时请求某个对象监视器时，对象监视器会设置几种状态用来区分请求的线程：

Contention List：所有请求锁的线程将被首先放置到该**竞争队列**  
Entry List：Contention List中那些有资格**成为候选人**的线程被移到Entry List  
Wait Set：那些调用**wait方法被阻塞**的线程被放置到Wait Set  
OnDeck：任何时刻最多只能有一个线程正在竞争锁，该线程称为OnDeck  
Owner：获得锁的线程称为**Owner**  
!Owner：**释放锁**的线程

![3029e62c878c4528b093ee9635c15e18.png][]

每一个锁都对应一个monitor对象，在HotSpot虚拟机中它是由ObjectMonitor实现的（C++实现）。**每个对象都存在着一个monitor与之关联**，对象与其monitor之间的关系有存在多种实现方式，如monitor可以与对象一起创建销毁或当线程试图获取对象锁时自动生成，但当一个monitor被某个线程持有后，它便处于锁定状态。

ObjectMonitor() \{  
\_header = NULL;  
\_count = 0; //锁的计数器，获取锁时count数值加1，释放锁时count值减1  
\_waiters = 0, //等待线程数  
\_recursions = 0; // 线程重入次数  
\_object = NULL; // 存储Monitor对象  
\_owner = NULL; // 持有当前线程的owner  
\_WaitSet = NULL; // wait状态的线程列表  
\_WaitSetLock = 0 ;  
\_Responsible = NULL ;  
\_succ = NULL ;  
\_cxq = NULL ; // 阻塞在EntryList上的单向线程列表  
FreeNext = NULL ;  
\_EntryList = NULL ; // 处于等待锁状态block状态的线程列表  
\_SpinFreq = 0 ;  
\_SpinClock = 0 ;  
OwnerIsThread = 0 ;  
\_previous\_owner\_tid = 0;  
\}

其中 \_owner、\_WaitSet和\_EntryList 字段比较重要，它们之间的转换关系如下图

![ca21a0072cf44e23a5c218f32cd972c6.png][]

ObjectMonitor中有两个队列**\_WaitSet**和**\_EntryList**，用来保存ObjectWaiter**对象列表**(每个等待锁的线程都**会被封装**ObjectWaiter对象)，\_owner指向持有ObjectMonitor对象的线程，当多个线程同时访问一段同步代码时，首先会进入\_EntryList 集合，当线程获取到对象的monitor 后进入 \_Owner 区域并把monitor中的owner变量**设置为当前线程**同时monitor中的计数器count加1，若线程调用 wait() 方法，将释放当前持有的monitor，owner变量恢复为null，count自减1，同时该线程进入 WaitSe t集合中**等待被唤醒**。若当前线程执行完毕也将释放monitor(锁)并复位变量的值，以便其他线程进入获取monitor(锁)。  
monitor对象存在于每个Java对象的**对象头中(存储的指针的指向)**，synchronized锁便是通过这种方式获取锁的，也是为什么J**ava中任意对象可以作为锁的原因**，同时也是notify/notifyAll/wait等方法存在于**顶级对象**Object中的原因(关于这点稍后还会进行分析)

知识来源：

[Synchronized的底层实现原理(看这篇就够了)\_synchronized底层实现原理\_mikechen的互联网架构的博客-CSDN博客][Synchronized_synchronized_mikechen_-CSDN]

[https://www.cnblogs.com/wffzk/p/16639472.html][https_www.cnblogs.com_wffzk_p_16639472.html]

[深入理解synchronized底层原理，一篇文章就够了！ - 知乎][synchronized_ -]

[3029e62c878c4528b093ee9635c15e18.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/8715a28558554d9e9dfcee67ad953775.png
[25d66466d9464592b6190ed6c7caa89c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/454bc99bccb94847859542f97322e453.png
[37749da513894adc8ab6b36fbc885309.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/d50e57675f37439894e64c56fb898093.png
[ce4ba482fd164798ac739af04045214b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/f961a669b6bb4707aef99062e1e10618.png
[8c16d9caedd34c9d84392bc0fe8a5570.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/55bc8ba5a1b0497d81c79aaec71244e6.png
[c4c7e9ab669448bfa28c1412aa82bc6e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/88e6a93ced1a447e90e790c96b1d54b0.png
[ca21a0072cf44e23a5c218f32cd972c6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/13/68bfb0b1a1ab4e4d8e80b2129a0b7e72.png
[Synchronized_synchronized_mikechen_-CSDN]: https://blog.csdn.net/ChenRui_yz/article/details/122448611
[https_www.cnblogs.com_wffzk_p_16639472.html]: https://www.cnblogs.com/wffzk/p/16639472.html
[synchronized_ -]: https://zhuanlan.zhihu.com/p/75880892