【JavaEE精炼宝库】多线程（4）深度理解死锁、内存可见性、volatile关键字、wait、notify

2024-06-07 13:52
文章标签 java 内存 深度 多线程 理解 关键字 ee 死锁 volatile wait 精炼 notify 宝库

本文主要是介绍【JavaEE精炼宝库】多线程（4）深度理解死锁、内存可见性、volatile关键字、wait、notify，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

目录

一、死锁

1.1 出现死锁的常见场景：

1.2 产生死锁的后果：

1.3 如何避免死锁：

二、内存可见性

2.1 由内存可见性产生的经典案例：

2.2 volatile 关键字：

2.2.1 volatile 用法：

2.2.2 volatile 不保证原子性：

2.2.3 volatile 作用总结：

三、wait 和 notify

3.1 wait 详解：

3.2 notify 和 notifyAll：

3.2.1 notify：

3.2.2 notifyAll：

3.3 面试题：wait 和 sleep 的区别：

在上一篇文章，我们了解了什么是线程安全，分析了产生线程不安全的原因。今天我们就要深度刨析一下线程不安全的经典案例：死锁和内存可见性引起的线程不安全问题。

一、死锁

1.1 出现死锁的常见场景：

• 场景一：

锁是不可重入锁（synchronized 是可重入锁），并且一个线程针对一个锁对象，连续加锁两次。

• 场景二：

两个线程两把锁。先让两个线程分别拿到一把锁，然后再去尝试获取对方的锁，这时就出现了死锁的情况。

• 场景三：

多个线程，多把锁。随着线程和锁的数目的增加，情况就会变得更加复杂，死锁就更容易出现。下面就是一个经典的死锁场景：哲学家就餐（除非吃到面条，否则不会放下筷子）。

 如果出现极端的情况，同一时刻所有的哲学家都拿起左边的筷子，这时就会出现死锁。

1.2 产生死锁的后果：

死锁是非常严重的问题。一个进程中线程的个数是有限的，死锁会使线程被卡住，没法继续工作。更加严重的是，死锁这种 bug 往往都是概率性出现（未知才是最可怕的）。测试的时候，怎么测试都没事，一旦发布，就出现了问题。更加要命的是发布也没有问题，等到夜深人静的时候，大家都睡着的时候，突然给你来点问题，直接带走年终奖😭。

1.3 如何避免死锁：

要想避免死锁，我们就要从产生死锁的原因入手。

教科书上经典的产生死锁的四个必要条件（下面给出的四个条件，友友们一定要背下来，面试的经典问题）。

1. 锁具有互斥性：

这时锁的基本特点，一个线程拿到锁之后，其他线程就得阻塞等待。

2. 锁具有不可抢占性（不可剥夺性）：

一个线程拿到锁之后，除非他自己主动释放锁，否则谁也抢不走。

3. 请求和保持：

一个线程拿到一把锁之后，不释放这个锁的前提下，再尝试获取其他锁。

4. 循环等待。

多个线程获取多个锁的过程中，出现了循环等待，A 等待 B ，B 又等待 A。

在任何一个死锁的场景，都必须同时具备上述四点，只要缺少一个，都不会构成死锁。观察上面的四个条件不难发现条件 1 和条件 2 是锁的基本特性，这个我们无法改变，观察到条件 3 和条件 4 都是代码结构的问题，所以我们就从条件 3，4 入手。

• 针对条件 3：

不要让锁嵌套获取即可。如果有些场景必须要嵌套获取锁，那么就破除循环等待（条件 4 ），即使出现嵌套，也不会出现死锁。

• 针对条件 4：

当代码中，确实需要用到多个线程获取多把锁，一定要记得约定好加锁的顺序（每个线程都必须要先获取 A 锁，再获取 B 锁，再.......），就可以有效避免死锁了。

二、内存可见性

2.1 由内存可见性产生的经典案例：

请友友们观察一下下面这段代码，可以粘贴到自己的编译器上跑一下，看看是否符合你的预期。

public class demo1 {static int count = 0;public static void main(String[] args) {Thread t1 = new Thread(() -> {while(count == 0){}System.out.println("t1.end");});Thread t2 = new Thread(() -> {Scanner in = new Scanner(System.in);System.out.println("请输入一个数字:");count = in.nextInt();});t1.start();t2.start();}
}

因为输入数据存在 IO 操作（很慢）所以一定能保证在我们输入数据的时候，t1 线程已经开始执行了。

正常来说，我们输入一个非 0 的数字后，t1 线程里面就会停止循环。但是产生的结果如下：

循环并没有退出，由于是前台线程，所以程序不能够结束。

上述问题产生的原因就是因为内存可见性。

• 案例解析：

上面的案例产生的问题是由于编译器优化 / JVM 优化产生的问题。不是说优化不好，而是 JVM 在这种情况下的优化太激进了。为什么会产生这么激进的优化呢？

我们站在指令的角度来理解有两个方面：

1. 在while 循环体中，每次条件判断的时候，分为两个步骤：1. load：从内存读取数据到 cpu 寄存器。2. cmp：比较，条件成立就会继续执行。 当前循环的旋转速度很快，短时间内出现大量的 load 和 cmp 反复执行的效果，由于 load 执行消耗的时间比 cmp 消耗的时间多很多（量级是几千倍，上万倍）。

2. JVM 发现每次 load 执行的结果是一样的（在 t2 修改之前）。

于是 JVM 就把上述的 load 操作优化掉了，只有第一次是真正的进行 load 后续的 load 就直接读取刚才 load 在寄存器中的值，也就是说不会去内存中去读取值了，这时即使内存中的值已经修改，但是还是 load 不到，这就是我们的线程可见性问题。

其实在这里加上打印，程序就符合我们的预期了。

这是为什么呢？答：因为此时 IO 操作才是程序运行时间的大头，优化 load 就没有必要了，因为程序的瓶颈不是 load 。此外，IO 操作是不能被优化掉的，被优化的前提是反复执行的结果是相同的，IO 操作注定是反复执行的结果是不相同的。

• 小结：

上述问题的本质还是编译器优化引起的，优化掉 load 操作之后，使 t2 线程的修改，没有被 t1 线程感知到，这就是 ”内存可见性“ 问题。

2.2 volatile 关键字：

2.2.1 volatile 用法：

编译器到底啥时候优化这也是个 ”玄学问题“。我们作为程序员显然不希望看到这样的代码出现，因此 Java 就引入的 volatile 关键字，就可以解决内存可见性引起的问题。volatile 修饰的变量，能够保证 "内存可见性"。

代码在写入 volatile 修饰的变量的时候：

• 改变线程工作内存中 volatile 变量副本的值。

• 将改变后的副本的值从工作内存刷新到主内存。

代码在读取 volatile 修饰的变量的时候：

• 从主内存中读取 volatile 变量的最新值到线程的工作内存中。

• 从工作内存中读取 volatile 变量的副本。

前面我们讨论内存可见性时说了，直接访问工作内存（实际是 CPU 的寄存器或者 CPU 的缓存)，速度非常快，但是可能出现数据不一致的情况。加上 volatile ，强制读写内存。速度是慢了，但是数据变的更准确了。

使用案例演示：

public class demo2 {public volatile static int count = 0;public static void main(String[] args) {Thread t1 = new Thread(() -> {System.out.println("t start");while(count == 0){}System.out.println("t end");});Thread t2 = new Thread(() -> {Scanner in = new Scanner(System.in);System.out.println("请输入一个数字:");count = in.nextInt();});t1.start();t2.start();}
}

案例效果：

2.2.2 volatile 不保证原子性：

volatile 和 synchronized 有着本质的区别。synchronized 能够保证原子性，volatile 保证的是内存可见性。例如下面这个案例：

public class demo3 {public volatile static int count = 0;public static void main(String[] args) {Object locker = new Object();Thread t1 = new Thread(() -> {for(int i = 0;i < 50000;i++){
//                synchronized(locker){count++;
//                }}});Thread t2 = new Thread(() -> {for(int i = 0;i < 50000;i++){
//                synchronized(locker){count++;
//                }}});t1.start();t2.start();try {t1.join();} catch (InterruptedException e) {throw new RuntimeException(e);}try {t2.join();} catch (InterruptedException e) {throw new RuntimeException(e);}System.out.println(count);}
}

案例演示效果如下：

可以看到最终的结果还是不符合我们的预期，所以 volatile 不保证原子性。 

2.2.3 volatile 作用总结：

volatile 关键字的作用主要有如下两个：

• 保证内存可见性：

基于屏障指令实现，即当一个线程修改一个共享变量时，另外一个线程能读到这个修改的值。

• 保证有序性：

禁止指令重排序。编译时 JVM 编译器遵循内存屏障的约束，运行时靠屏障指令组织指令顺序。

注意：volatile 不能保证原子性。

三、wait 和 notify

由于线程之间是抢占式执行的，因此线程之间执行的先后顺序难以预知。但是实际开发中有时候我们希望合理的协调多个线程之间的执行先后顺序。就好像足球队一样，线程 1 要先传球，线程 2 才能射门。

针对随即调度，我们程序员也是有手段干预的，即通过 “等待” 的方式，能够让线程一定程度的按照我们预期的顺序来执行。无法主动让某个线程被调度，但是可以主动让某个线程等待（给别的线程机会）。

完成这个协调工作，主要涉及到三个方法：

注意:  wait，notify，notifyAll 都是 Object 类的方法（意味着所有类都可以）。

3.1 wait 详解：

wait 做的事：

• 使当前执行代码的线程进行等待（把线程放到等待队列中）。

• 释放当前的锁（wait 必须要放在锁的代码块里面使用）。

• 满足一定条件时被唤醒，重新尝试获取这个锁。

wait 结束等待的条件：

• 其他线程调用该对象的 notify 方法。

• wait 等待时间超时（wait 方法提供一个带有 timeout 参数的版本，来指定等待时间）。

• 其他线程调用该等待线程的 interrupted 方法，导致 wait 抛出 InterruptedException 异常。

注意：wait 和 sleep 一样会被线程的 interrupt 打断，wait 也会自动清空标志位。

案例演示如下：

public class demo1 {public static void main(String[] args) {Object locker = new Object();Thread t1 = new Thread(() -> {System.out.println("开始");try {synchronized(locker){locker.wait();}} catch (InterruptedException e) {throw new RuntimeException(e);}System.out.println("结束");});t1.start();}
}

案例演示效果如下：

可以发现线程成功被停止了。 

注意：

wait 要搭配 synchronized 来使用。脱离 synchronized 使用 wait 会直接抛出异常。例如我们将上面的那段代码进行修改，将 locker 脱离锁，产生的情况如下：

这样在执行到 object.wait() 之后就一直等待下去，那么程序肯定不能⼀直这么等待下去了。这个时候就需要使用到了另外⼀个方法唤醒的方法 notify()。

3.2 notify 和 notifyAll：

3.2.1 notify：

notify 方法是唤醒等待的线程。具体作用如下：

• 方法 notify() 也要在同步方法或同步块中调用，该方法是用来通知那些可能等待该对象的对象锁的其它线程，对其发出通知 notify，并使它们重新获取该对象的对象锁。

• 如果有多个线程等待，则有线程调度器随机挑选出⼀个呈 wait 状态的线程。(并没有 "先来后到") 。

• 在 notify() 方法后，当前线程不会马上释放该对象锁，要等到执行 notify() 方法的线程将程序执行完，也就是退出同步代码块之后才会释放对象锁。

案例演示如下：

public class demo2 {public static void main(String[] args) {Object locker = new Object();Thread t1 = new Thread(() -> {System.out.println("开始等待");synchronized(locker){try {locker.wait();} catch (InterruptedException e) {throw new RuntimeException(e);}}System.out.println("结束等待");});Thread t2 = new Thread(() -> {Scanner in = new Scanner(System.in);System.out.print("输入内容开始通知:");in.next();synchronized(locker){locker.notify();System.out.println("通知结束");}});t1.start();t2.start();}
}

案例演示效果如下：

3.2.2 notifyAll：

notify 只能随机唤醒一个由 wait 导致的等待线程，例如：

import java.util.*;
public class demo3 {public static void main(String[] args) {Object locker = new Object();Thread t1 = new Thread(() -> {System.out.println("t1:开始等待");synchronized(locker){try {locker.wait();} catch (InterruptedException e) {throw new RuntimeException(e);}}System.out.println("t1:结束等待");});Thread t2 = new Thread(() -> {System.out.println("t2:开始等待");synchronized(locker){try {locker.wait();} catch (InterruptedException e) {throw new RuntimeException(e);}}System.out.println("t2:结束等待");});Thread t3 = new Thread(() -> {Scanner in = new Scanner(System.in);System.out.print("输入内容开始通知:");in.next();synchronized(locker){locker.notify();System.out.println("通知结束");}});t1.start();t2.start();t3.start();}
}

最终跑出的结果如下：

可以清楚的看到只有一个线程被唤醒了。

因此 Java 引入 notifyAll 来一次性唤醒全部。我们就直接将上述代码稍加修改即可。

import java.util.*;
public class demo3 {public static void main(String[] args) {Object locker = new Object();Thread t1 = new Thread(() -> {System.out.println("t1:开始等待");synchronized(locker){try {locker.wait();} catch (InterruptedException e) {throw new RuntimeException(e);}}System.out.println("t1:结束等待");});Thread t2 = new Thread(() -> {System.out.println("t2:开始等待");synchronized(locker){try {locker.wait();} catch (InterruptedException e) {throw new RuntimeException(e);}}System.out.println("t2:结束等待");});Thread t3 = new Thread(() -> {Scanner in = new Scanner(System.in);System.out.print("输入内容开始通知:");in.next();synchronized(locker){locker.notifyAll();//修改处System.out.println("通知结束");}});t1.start();t2.start();t3.start();}
}

案例的演示效果如下：

可以看到我们所有等待的线程都被唤醒了。

注意：虽然是同时唤醒 2 个线程，但是这 2 个线程需要竞争锁，所以并不是同时执行，而仍然是有先有后的执行。

3.3 面试题：wait 和 sleep 的区别：

• wait：用于线程之间的通信。

• sleep：让线程阻塞一段时间。

相同点：是都可以让线程放弃执行一段时间。

大体的区别分为如下 3 点：

（1）wait 需要搭配 synchronized 使用，而 sleep 不需要。

（2）wait 是 Object 的方法，sleep 是 Thread 的静态方法。

（3）(从状态来) wait 被调用后，当前线程进入 waiting 状态并释放锁，并可以通过 notify 和 notifyAll 方法进行唤醒。sleep 被调用后当前线程进入 TIMED_WAITING 状态，不涉及锁相关的操作。

结语：

其实写博客不仅仅是为了教大家，同时这也有利于我巩固知识点，和做一个学习的总结，由于作者水平有限，对文章有任何问题还请指出，非常感谢。如果大家有所收获的话还请不要吝啬你们的点赞收藏和关注，这可以激励我写出更加优秀的文章。

这篇关于【JavaEE精炼宝库】多线程（4）深度理解死锁、内存可见性、volatile关键字、wait、notify的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/1039367。

相关文章

JVM 的类初始化机制

JVM 的类初始化机制

前言 当你在 Java 程序中new对象时，有没有考虑过 JVM 是如何把静态的字节码（byte code）转化为运行时对象的呢，这个问题看似简单，但清楚的同学相信也不会太多，这篇文章首先介绍 JVM 类初始化的机制，然后给出几个易出错的实例来分析，帮助大家更好理解这个知识点。 JVM 将字节码转化为运行时对象分为三个阶段，分别是：loading 、Linking、initialization
阅读更多...
Spring Security 基于表达式的权限控制

Spring Security 基于表达式的权限控制

前言 spring security 3.0已经可以使用spring el表达式来控制授权，允许在表达式中使用复杂的布尔逻辑来控制访问的权限。 常见的表达式 Spring Security可用表达式对象的基类是SecurityExpressionRoot。 表达式描述hasRole([role])用户拥有制定的角色时返回true （Spring security默认会带有ROLE_前缀）,去
阅读更多...
浅析Spring Security认证过程

浅析Spring Security认证过程

类图 为了方便理解Spring Security认证流程，特意画了如下的类图，包含相关的核心认证类 概述 核心验证器 AuthenticationManager 该对象提供了认证方法的入口，接收一个Authentiaton对象作为参数; public interface AuthenticationManager {Authentication authenticate(Authenti
阅读更多...
Spring Security--Architecture Overview

Spring Security--Architecture Overview

1 核心组件 这一节主要介绍一些在Spring Security中常见且核心的Java类，它们之间的依赖，构建起了整个框架。想要理解整个架构，最起码得对这些类眼熟。 1.1 SecurityContextHolder SecurityContextHolder用于存储安全上下文（security context）的信息。当前操作的用户是谁，该用户是否已经被认证，他拥有哪些角色权限…这些都被保
阅读更多...
Spring Security基于数据库验证流程详解

Spring Security基于数据库验证流程详解

Spring Security 校验流程图 相关解释说明（认真看哦） AbstractAuthenticationProcessingFilter 抽象类 /*** 调用 #requiresAuthentication(HttpServletRequest, HttpServletResponse) 决定是否需要进行验证操作。* 如果需要验证，则会调用 #attemptAuthentica
阅读更多...
Spring Security 从入门到进阶系列教程

Spring Security 从入门到进阶系列教程

Spring Security 入门系列 《保护 Web 应用的安全》 《Spring-Security-入门（一）：登录与退出》 《Spring-Security-入门（二）：基于数据库验证》 《Spring-Security-入门（三）：密码加密》 《Spring-Security-入门（四）：自定义-Filter》 《Spring-Security-入门（五）：在 Sprin
阅读更多...
Java架构师知识体认识

Java架构师知识体认识

源码分析 常用设计模式 Proxy代理模式Factory工厂模式Singleton单例模式Delegate委派模式Strategy策略模式Prototype原型模式Template模板模式 Spring5 beans 接口实例化代理Bean操作 Context Ioc容器设计原理及高级特性Aop设计原理Factorybean与Beanfactory Transaction 声明式事物
阅读更多...
NameNode内存生产配置

NameNode内存生产配置

Hadoop2.x 系列，配置 NameNode 内存 NameNode 内存默认 2000m ，如果服务器内存 4G ， NameNode 内存可以配置 3g 。在 hadoop-env.sh 文件中配置如下。 HADOOP_NAMENODE_OPTS=-Xmx3072m Hadoop3.x 系列，配置 Nam
阅读更多...
Java进阶13讲__第12讲_1/2

Java进阶13讲__第12讲_1/2

多线程、线程池 1.  线程概念 1.1  什么是线程 1.2  线程的好处 2.   创建线程的三种方式 注意事项 2.1  继承Thread类 2.1.1 认识  2.1.2  编码实现  package cn.hdc.oop10.Thread;import org.slf4j.Logger;import org.slf4j.LoggerFactory
阅读更多...
认识、理解、分类——acm之搜索

认识、理解、分类——acm之搜索

普通搜索方法有两种：1、广度优先搜索；2、深度优先搜索； 更多搜索方法： 3、双向广度优先搜索； 4、启发式搜索（包括A*算法等）； 搜索通常会用到的知识点：状态压缩（位压缩，利用hash思想压缩）。
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2