JavaEE初阶第七期：解锁多线程，从 “单车道” 到 “高速公路” 的编程升级（五）

专栏：JavaEE初阶起飞计划

个人主页：手握风云

目录

一、死锁

1.1. 死锁的概念

1.2. 造成死锁的原因

1.3. 如何避免出现死锁

二、volatile关键字

2.1. 内存可见性引起的线程安全问题

2.2. volatile

一、死锁

1.1. 死锁的概念

        死锁是指两个或多个并发进程（或线程）在执行过程中，因争夺资源而造成的一种互相等待的现象。如果没有外力作用，这些进程将永远无法继续向前推进。

1.2. 造成死锁的原因

• 同一把锁连续加锁两次

        由于synchronized具有可重入性，对于这种情况可以有效处理，但无法处理其他情况。

• 两个线程两把锁，每个线程都先获取一把锁，再尝试获取对方的锁

        线程t1先拿到了locker1，线程t2也获取到了locker2。然后线程t1尝试获取locker2，线程t2尝试获取locker1。就如同把房门钥匙锁在车里面，而车钥匙又锁在家里面，就这样也构成了死锁。

public class Demo1 { public static void main(String[] args) throws InterruptedException { Object locker1 = new Object(); Object locker2 = new Object(); Thread t1 = new Thread(() -> { synchronized (locker1) { System.out.println(\"t1拿到了locker1\"); // 此处的sleep目的是让t1和t2分别获得对应的locker1和locker2 // 如果t1和t2同时获得对应的locker1和locker2，那么t1和t2会互相等待对方释放锁，造成死锁 try {  Thread.sleep(1000); } catch (InterruptedException e) {  e.printStackTrace(); } synchronized (locker2) {  System.out.println(\"t1拿到了locker2\"); } } }); Thread t2 = new Thread(() -> { synchronized (locker2) { System.out.println(\"t2拿到了locker2\"); try {  Thread.sleep(1000); } catch (InterruptedException e) {  e.printStackTrace(); } synchronized (locker1) {  System.out.println(\"t2拿到了locker1\"); } } }); t1.start(); t2.start(); t1.join(); t2.join(); }}

        通过线程更直观的观察，我们会发现两个线程都各自卡在了尝试获取对方锁的过程中。如果没有人工干预的情况下，那么两个线程将会永远卡住。

• N个线程M把锁

        在计算机科学中，有一个经典的并发编程问题——哲学家就餐问题：五位哲学家围坐圆桌，桌上有五碗意大利面和五把餐叉，每位哲学家两侧各有一把餐叉，哲学家只能用两侧餐叉吃面，且吃面与思考交替进行。当所有哲学家同时拿起左侧的叉子时，由于右侧叉子在别的哲学家手里，每个人就需要等待放下别人手里的叉子，此时就会死锁。

1.3. 如何避免出现死锁

        线程一旦出现死锁，线程就会卡死了，后序的逻辑也无法正常执行了，从而产生了bug。而由于死锁的出现是概率性的，虽然概率小，但是也需要重视。

• 造成死锁的必要条件

1. 互斥性：如果一个线程已经占用了一个资源，其他线程就不能再申请该资源，直到该资源被释放，这是死锁发生的基础。
2. 锁不可被抢占：一旦一个线程获得了一把锁之后，它就一直拥有这把锁，其他线程要想获得，只能阻塞等待。
3. 请求与保持：一个线程在拿到一把锁时，第一把锁还没释放，又去请求第二把锁。
4. 循环等待：等待锁释放的条件顺序构成了循环。

        只有当以上四个条件同时满足时，才可能发生死锁。 只要破坏其中任何一个条件，就可以有效预防死锁的发生。

public class Demo2 { public static void main(String[] args) throws InterruptedException { Object locker1 = new Object(); Object locker2 = new Object(); Thread t1 = new Thread(() -> { synchronized (locker1) { System.out.println(\"t1拿到了locker1\"); try {  Thread.sleep(1000); } catch (InterruptedException e) {  e.printStackTrace(); } } // locker1释放了，t2可以拿到 synchronized (locker2) { System.out.println(\"t1拿到了locker2\"); } }); Thread t2 = new Thread(() -> { synchronized (locker2) { System.out.println(\"t2拿到了locker2\"); try {  Thread.sleep(1000); } catch (InterruptedException e) {  e.printStackTrace(); } synchronized (locker1) {  System.out.println(\"t2拿到了locker1\"); } } }); t1.start(); t2.start(); t1.join(); t2.join(); }}

二、volatile关键字

2.1. 内存可见性引起的线程安全问题

import java.util.Scanner;public class Demo3 { private static int flag = 0; public static void main(String[] args) throws InterruptedException { Thread t1 = new Thread(() -> { while (flag == 0) { } System.out.println(\"t1线程结束\"); }); Thread t2 = new Thread(() -> { Scanner in = new Scanner(System.in); System.out.println(\"请输入flag的值:\"); flag = in.nextInt(); System.out.println(\"t2线程结束\"); }); t1.start(); t2.start(); t1.join(); t2.join(); }}

        当我们输入一个非零值时，线程2结束了，但线程1并没有正确结束。这个Bug产生的原因就是内存的可见性。t2线程中flag变量的修改，但对于t1线程“不可见了”。

        对于Java编程语言的设计者来说，考虑到一个问题：写代码的程序员的水平参差不齐。虽然有的程序员水平不高，写代码效率较低。编译器在编辑执行的时候，分析理解现有代码的意图和效果，然后自动对整个代码进行优化和调整，在确保程序执行逻辑不变的前提下，进而提高效率。但在某些特定场景下，编译器会出现误判。

        对于上面的代码来说，编译器看到的是有一个flag会快速反复读取这个内存的值。因为反复执行(读取、比较……)，每次拿到的flag值是一样的，读取内存的操作相比读取寄存器会耗时很多，于是编译器就会把从内存中读取flag的操作优化掉，直接从寄存器中读取。但在t2线程中对变量flag进行了修改，编译器也不能确定t2线程里的flag到底能不能执行到，以及啥时候执行。

2.2. volatile

        通过这个关键字，提醒编译器，某个变量是“易变的”，此时就不要针对这个变量进行上述优化。

import java.util.Scanner;public class Demo3 { // 加上volatile关键字之后 private static volatile int flag = 0; public static void main(String[] args) throws InterruptedException { Thread t1 = new Thread(() -> { while (flag == 0) { } System.out.println(\"t1线程结束\"); }); Thread t2 = new Thread(() -> { Scanner in = new Scanner(System.in); System.out.println(\"请输入flag的值:\"); flag = in.nextInt(); System.out.println(\"t2线程结束\"); }); t1.start(); t2.start(); t1.join(); t2.join(); }}