Java多线程——synchronized底层实现及优化

妖狐艹你老母 2023-06-03 13:55 29阅读 0赞

## Java多线程——synchronized底层实现及优化 ##

### 一、synchronized底层实现（monitor机制） ###

>   **同步代码块与同步方法是怎样实现同步的？**

####   1、同步代码块底层实现 ####

>   通过操作系统的两大指令**monitorenter（获取锁）和monitorexit（释放锁，解锁）** 来获取锁的**对象的监视器（monitor）**。

#####    ①执行同步代码块前要执行monitorenter指令，执行同步代码块后要执行monitorexit指令。 #####

#####    ②使用synchronized实现同步，关键点就是要`获取对象的监视器monitor对象`，当线程获取到monitor对象后，才可以执行同步代码块，否则就只能等待。 #####

#####    ③`同一时刻`只有`一个线程`可以获取到该对象的monitor监视器。(该特点使得代码块是同步的) #####

#####    ④通常`一个monitorenter`指令会同时对应`多个monitorexit`指令。（JVM要确保所获取的锁，无论是在正常执行情况或异常执行情况都能正常解锁（即便是有异常，也得`先释放锁，再报异常`） #####

####   2、同步方法底层实现 ####

#####    当使用synchronized标记方法时，字节码会出现访问标记(`ACC_SYNCHRONIZED`)，该标记就表示在进入该方法时，JVM需要进行monitorenter操作。在退出该方法时，无论是否正常返回，JVM均需要进行monitorexit操作。 #####

####   总结一下同步的底层实现： ####

#####    无论是同步代码块还是同步方法，其`底层`实现都是应用了`monitor机制`，只不过，同步代码块是直接执行monitorenter与monitorexit，而同步方法是设置了一个ACC\_SYNCHRONIZED访问标记，这个标记的底层还是monitor机制。\*\* #####

>   **到底什么是monitor机制呢？**  
>   **monitor机制的执行流程到底是怎样的？**

####   3、monitor机制 ####

>   **可以将monitor理解为每个锁对象拥有一个`锁计数器`和一个`指向持有该锁的线程的指针`。**

#####    ①当JVM执行monitorenter时，如果目标对象monitor的计数器为`0`，表示此时该对象没有被其他线程所持有。此时JVM会将该锁对象的持有线程设置为当前线程，并且将monitor计数器`+1`。 #####

#####    ②当执⾏ monitorexit 时，Java 虚拟机则需将锁对象的计数器减 1。当计数器减为 0 时，那便代表该锁已经被释放掉了，并`唤醒所有正在等待的线程去竞争该锁`。 #####

#####    ③monitor机制还具有可重入性(锁的可重入性)，可见下文。 #####

####   4、synchronized锁的可重入性 ####

#####    ①可重入性：在目标锁对象的计数器不为0的情况下，如果锁对象的持有线程是当前线程，JVM可以将计数器再次+1（可重入锁）,否则需要等待，直到持有线程释放该锁。 #####

#####    ②可重入性也可以用在父子类继承中，子类完全可以通过“可重入锁”调用父类的同步方法。（父类中的非private方法子类都可以用） #####

#####    ③根据synchronized锁的可重入性可以证明：在一个synchronized方法/块的内部调用本类的其他synchronized方法/块时，一定可以得到锁。（既然能进入到synchronized内部，肯定就已经拿到了当前对象的锁，当然可以访问该对象的其他同步方法） #####

>   **有了monitor机制，能否解释，synchronized为什么锁的是对象而不是其他东西？**

####   5、synchronized锁的是对象的原因： ####

#####    `由于synchronized获取的是当前对象的监视器monitor，类中这么多的同步方法都是属于一个对象的，所以锁的是对象。` #####

>   **说了这么多monitor的好处，monitor机制有什么劣势吗？**

####   6、monitor机制的劣势 ####

#####    对象锁（monitor）机制是JDK1.6之前synchronized底层原理，又称为JDK1.6重量级锁，线程的阻塞以及唤醒均需要操作系统由用户态切换到内核态，开销非常之大，因此效率很低。 #####

>   **monitor机制效率太低，太过笨重，Java还是对synchronized锁进行了优化，使用CAS操作进行全面的优化。**

### 二、synchronized（内建锁）的优化 ###

>   **无论是CAS操作，还是多种锁的产生，都是对synchronized内建锁的优化，都属于synchronized内建锁的一部分。**

####   1、CAS(Compare And Swap)操作 ####

>   **CAS是一种乐观锁策略，但什么是悲观锁？什么是乐观锁呢？**

#####    ①悲观锁：线程获取锁（JDK1.6之前内建锁）是一种悲观锁策略。 #####

######     a）假设每一次执行临界区代码（访问共享资源）都会产生冲突，所以当前线程获取到锁的同时也会阻塞其他未获取到锁的线程。 ######

######     b）每次上厕所都有人和我抢——`只要有一个线程在访问共享资源，都有其他的线程也在竞争锁`，当该线程获取到锁后，其他线程都得等待 ######

#####    ②乐观锁：CAS（无锁）操作，是一种乐观锁策略 #####

######     a）假设所有线程访问共享资源时不会出现冲突，由于不会出现冲突自然就不会阻塞其他线程。因此线程就不会出现阻塞停顿的状态。(上厕所一定没人抢——可以不要锁） ######

######     b）若出现冲突了，无锁操作`使用CAS(比较交换)来鉴别线程是否出现冲突`，出现冲突就重试当前操作，直到没有冲突（获取锁）为止。 ######

######     c）若线程未获取到锁，该线程利用CAS不断的在重试，看在里面的那个线程结束了没，结束了就没有冲突，该线程就可以获取到锁了，此时`该线程没有停止，会在CPU上跑，只不过跑的是无用指令`。（`反复在重试看有无冲突，直到获取锁为止`） ######

>   **CAS(Compare And Swap)到底是怎样操作的？**

#####    ③CAS的操作过程 #####

>   **将CAS理解为CAS(V,O,N)**  
>     **V：当前内存地址中实际存放的值**  
>     **O：期望V中存放的值（旧值）**  
>     **N：更新后的值（新值）**

######     a）当V==O时：旧值与内存中的实际值相等，表明该值没有被其他线程更改过，即值O就是目前最新的值，因此可以将新值N赋值给V； ######

######        当V!=O时，表明该值已经被其他线程修改过了，因此O值并不是当前最新值，返回V，无法修改。 ######

######     b）当多个线程使用CAS操作时，`只有一个线程会成功，其余线程均失败`（多个线程同时进行CAS，肯定会有一个线程优先进入将V值修改为该线程的N值，其余线程再判断当前的V与O当然是不相同的，因此会失败）。`失败的线程会重新尝试（自旋）或挂起线程（阻塞）` ######

>   **说了这么多CAS，那么CAS基于synchronized到底有什么区别和改进？**

#####    ④`synchronized机制与CAS的区别` #####

######     a）`synchronized内建锁`在优化前（老版本）最大的问题在于：在存在线程竞争的情况下，会出现`线程的阻塞以及唤醒带来的性能问题`，这是一种互斥同步（阻塞同步）——`挂起-再唤醒（开销太大）` ######

######     b）`CAS`不是将线程挂起，当CAS失败后会进行一定的尝试操作并非耗时的将线程挂起，这是一种非阻塞同步 ——`失败-重试` ######

>   此时小小的总结一下：  
>    **synchronized机制为什么不好呢？**  
>    答曰：**一个线程获取锁后阻塞了其他线程使其挂起-再唤醒，效率太低。是一种`阻塞同步`**  
>    **CAS操作为什么好呢？**  
>    答曰：**CAS采用失败-重试，减少了挂起-再唤醒所消耗的时间，是一种`非阻塞同步`**

#####    ⑤CAS自旋带来的问题 #####

>   **CAS是完美的吗？CAS会带来什么其他问题？**

######     a）ABA问题 ######

>   ⽐如⼀个旧值A变为了成B，然后再变成A，刚好在做CAS时检查发现旧值并没有变化依然为A，但是实际上的确发⽣了变化

######       解决方案：添加了版本号（版本号不相同，还是不能改） ######

老版本（A->B->A...)
    		新版本（1A->2B->3A...）

######     b）`自旋（CAS）会浪费大量的CPU资源` ######

>   与线程阻塞相比，自旋会浪费大量的处理器资源。因为**当前线程仍处于运行状态，只不过跑的是无用指令**。

######       解决方案：自适应自旋——重量级锁的优化（有阻塞状态） ######

>    根据以往（上一次）自旋等待时，能否获取锁所花费的时间，来**动态调整本次自旋的时间**（重复试探的循环次数）。
> 
> > 如果在上一次自旋时获取到锁，则稍微增加下一次自旋的时长（多重试几次）  
> > 否则会稍微减少下一次自旋时长（少重试几次）
> 
>   **自旋时长结束后就会进入阻塞状态了**

######     "自适应自旋"说白了就是看：上一次CAS自旋是否获取到锁了，若上一次CAS自旋获取到锁了，这次CAS自旋时间就加长一些，反之，减短一些。当自旋时长结束就会进入阻塞状态（和synchronized一样了）。 ######

######     "自适应自旋"就是CAS失败-重试(自旋)操作与synchronized挂起-再唤醒(阻塞)的完美结合。JVM并不知道当前线程到底能否或还有多久获取锁，因此JVM会采用"自适应自旋"尽量做到完美。 ######

######     c）公平性问题 ######

######      `CAS自旋的线程始终比synchronized阻塞的线程 优先获取到锁。` ######

>       公平性：等待时间最长的线程优先获取锁

######       内建锁`无法实现公平机制`，而lock体系可以实现公平锁。 ######

####   2、Java1.6后全新的锁状态分析 ####

>   **了解锁的类型前，先来看看什么是Java对象头？**

#####    ①Java对象头 #####

######     a） Java对象头Mark Word字段存放内容：对象的HashCode、分代年龄、锁标记位 ######

######     b）32位JVM下的Mark Word![在这里插入图片描述][20190717165953755.png] ######

#####    ②Java（状态）锁的分类—对应MarkWord中的标志位 #####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzQ5MDQ0MA_size_16_color_FFFFFF_t_70]

>   **四种锁的级别是什么？四种锁之间相互转换的策略是什么？**

#####    锁的四种状态级别：无锁<偏向锁<轻量级锁<重量级锁 #####

#####    根据竞争状态的激烈程度，锁只能自动升级，不能降级，为了提高锁获取与释放的效率。 #####

>   **偏向锁，轻量级锁，重量级锁到底指的是什么意思？**

####   3、偏向锁 ####

#####    ①偏向锁的引入：大多数情况下，锁不仅`不存在多线程竞争`，而且总是`由同一个线程多次获得`。为了让线程获取锁的开销降低而引入偏向锁。 #####

#####     偏向锁是锁状态中最乐观的一种锁：`从始至终只有一个线程请求一把锁`。 #####

#####    ②偏向锁的获取 #####

######     a）当一个线程访问某对象的同步块并成功获取到该对象的锁时，会在对象头和栈帧中的锁记录字段存储`锁偏向的线程ID`，以后该线程再进入和退出该对象的其他同步块时，不需要进行CAS操作来加锁和解锁，直接进入。（同一线程再尝试获取锁`不需要自旋过程了`） ######

######     b）当线程访问同步块失败时（当前偏向锁已被其他线程锁占用），使用CAS竞争锁，并将`偏向锁升级为轻量级锁`。 ######

#####    ③偏向锁的撤销（开销比较大，一般不撤销，一直让一个线程拿着） #####

######     a）偏向锁使用一种`等待竞争出现才释放锁`的机制，所以当其他线程竞争偏向锁时，持有偏向锁的线程才会释放偏向锁，并将锁膨胀为轻量级锁（持有偏向锁的线程依然存活的时候） ######

######      PS：;两个同时存活的线程，一个已经持有该偏向锁，另一个也来竞争该偏向锁，则偏向锁才会升级为轻量级锁。 ######

######     b）如果当前偏向锁的持有线程已经终止，则将锁对象的对象头设置为无锁状态，其他线程就有机会直接拿到该偏向锁了。（原本拥有该偏向锁的线程已经终止，另一个线程可以直接获取该偏向锁） ######

#####    ④偏向锁头部Epoch字段值![在这里插入图片描述][20190717171243938.png] #####

######     Epoch字段表示：此对象偏向锁的撤销次数 ######

######     默认撤销`40`次时，表示此对象不再适用于偏向锁，当下次（第41次撤销）线程再次获取此对象时，直接变为轻量级锁。（升级锁） ######

#####    ⑤ JDK6之后，偏向锁默认开启（`一个锁最初默认都是偏向锁`，后来会一步步升级） #####

####   4、轻量级锁 ####

#####    ①`多个线程在不同的时间段请求同一把锁`，也就是不存在锁竞争的情况。针对这种状况，JVM采用了轻量级锁来避免线程的阻塞与唤醒。（`只要有竞争，立马升级为重量级锁`） #####

#####    ②轻量级锁加锁 #####

######     将MarkWord中的内容拷到当前线程的栈帧中用于存储锁记录的空间（Displaced Mark Word），然后尝试使用CAS将对象头中的Mark Word替换为指向锁记录的指针。 ######

######     若成功（当前并没有线程获得锁）：当前线程获得锁。 ######

######     若失败（当前已有线程获得锁）：表示其他线程正在占用该锁，当前线程便尝试使⽤⾃旋来获取锁。若自旋到一定次数后还未获取到锁，`轻量级锁就会膨胀成重量级锁。` ######

#####    ③轻量级锁解锁 #####

######     使用CAS操作将Displaced Mark Word替换回到对象头。 ######

######     若成功：表示没有竞争发生。 ######

######     若失败：表示当前锁存在竞争，锁已经膨胀为重量级锁，需要在释放锁的同时唤醒那些被挂起的线程。 ######

####   5、重量级锁 ####

#####    多个线程在同一时刻请求同一把锁，线程之间的切换需要从用户态到内核态，切换成本非常高。 #####

####   6、锁升降级的特点 ####

#####    根据竞争状态的激烈程度，`锁会自动进行升级，但锁不能降级`>——为了提高锁获取与释放的效率（轻量级升级为重量级就证明此时有大量的线程在竞争，不能再还原了） #####

####   有关这三种锁的升级请参考：[Java锁的升级策略][Java] ####

>   **对比一下三种锁的特点**

####   7、`********三种锁的特点比较********` ####

#####    ①`偏向锁`只会在`第一次请求锁时`采用CAS操作，并将锁对象的标记字段记录为当前线程地址。在此后的运行过程中，持有该对象偏向锁的线程再进入其它同步代码块时无需加锁操作。 #####

#####    针对的是`锁仅会被同一线程持有`的情况 #####

#####    `偏向锁升级为轻量级锁`：某个线程访问锁时发现该偏向锁被其他线程所占用，即刻升级为轻量级锁。 #####

#####    ②`轻量级锁`采用CAS操作，将锁对象标记字段替换为一个指针，指向当前线程栈上的一块空间，存储着锁对象原本的标记字段，每次都采用CAS来替换标记的指针。 #####

#####    针对的是`多个线程在不同时间段申请同一把锁`的情况 #####

#####    `轻量级锁升级为重量级锁`：某个线程访问锁时发现该轻量级锁被其他线程所占用，该线程使用CAS自旋获取该轻量级锁，若到一定次数(自旋的次数)还未获取到锁，将该轻量级锁升级为重量锁 #####

#####    ③`重量级锁`会阻塞、唤醒请求加锁的线程。 #####

#####     针对的是`多个线程同时竞争同一把锁`的情况，JVM采用自适应自旋来避免在面对非常小的同步代码块时，仍会被阻塞和唤醒的状况。 #####

####   8、其他优化方式 ####

#####    ①锁粗化 #####

>    **将多次连接在一起的加锁、解锁操作合并为一次操作。将多个连续的锁扩展为一个范围更大的锁。（多次append()，第一次append()加锁，最后一次append()解锁）**

#####    ②锁的消除 #####

>    **删除不必要的加锁操作。根据代码逃逸技术，如果判断一段代码中，堆上的数据不会逃逸出当前线程，则认为此代码时线程安全的，无需加锁。 （不存在共享竞争的问题，就不需要锁了）**

// 虽然StringBuffer的append是一个同步方法，但是StringBuffer对象是在方法体里面创建的，
    	因此每个线程都会有其自己的StringBuffer对象，不存在共享资源的竞争，不需要锁机制。
    	public class Test{
    		 public static void main(String[] args) {
    			 StringBuffer sb = new StringBuffer();
    			 sb.append("a").append("b").append("c");
    		 }
    	}

[20190717165953755.png]: /images/20230601/0fa4cffd4f8b47ca9815f14705211d20.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzQ5MDQ0MA_size_16_color_FFFFFF_t_70]: /images/20230601/35589fc4e9dd4bc4bc3420371bcd35ad.png
[20190717171243938.png]: /images/20230601/50c4ef376352427da1f535dddcf54e31.png
[Java]: https://www.cnblogs.com/pomer-huang/p/10965228.html