详细剖析多线程2----线程安全问题（面试高频考点）

Dusk_L&U

已于 2024-04-04 16:04:22 修改

阅读量761

点赞数 28

分类专栏： JavaEE 文章标签：面试 java 线程安全多线程死锁

于 2024-03-24 16:45:35 首次发布

本文链接：https://blog.csdn.net/m0_74299308/article/details/136981296

版权

JavaEE 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

文章目录

一、概念
二、线程不安全的原因
三、解决线程不安全问题--加锁（synchronized）
- synchronized的特性
四、死锁问题
五、内存可见性导致的线程安全问题
六、指令重排序导致的线程安全问题
七、wait和notify

一、概念

想给出⼀个线程安全的确切定义是复杂的，但我们可以这样认为：
在多线程环境下程序能够按照预期的方式运行，并且不会出现数据竞争或不一致性的情况。因此，如果一个程序在单线程环境下能够正常运行，在多线程环境下也能够保持一致性和正确性，那么可以认为这个程序是线程安全的。反之，如果一个程序在多线程环境下出现了竞态条件、死锁、数据竞争等问题，那么可以认为这个程序是线程不安全的。

二、线程不安全的原因

首先观察一下下面的这段代码，判断他能否按预期输出10w?

package Thread;
//线程安全问题
public class ThreadDemo16 {
    private static int count=0;
    public static void main(String[] args) throws InterruptedException {
        Thread t1=new Thread(()->{
            for (int i = 0; i < 50000; i++) {
                count++;
            }
        });
        Thread t2=new Thread(()->{
            for (int i = 0; i < 50000; i++) {
                count++;
            }
        });
        t1.start();
        t2.start();
        // 如果没有这俩 join, 肯定不⾏的. 线程还没⾃增完, 就开始打印了
        //很可能打印出来的 count是初始值0，或者计算中间的值，总之是不确定的结果
        t1.join();
        t2.join();
        // 预期结果应该是 10w
        System.out.println("count: " + count);

    }
}

运行之后我们发现打印的结果并不是10w，并且每一次运行的结果都是随机的，由此可见这个线程是不安全的，那么为什么会出现线程不安全这个问题呢？
在这里插入图片描述

由此总结线程不安全的原因-----

【根本原因】==操作系统上的线程是“抢占式执行”的，线程调度是随机的，==这是线程不安全的一个主要原因。随机调度会导致在多线程环境下，程序的执行顺序不确定，程序员必须确保无论哪种执行顺序，代码都能正常运行。
【代码结构】共享资源：多个线程同时访问并修改同一变量。当多个线程同时访问和修改共享资源时容易引发竞态条件和数据不一致的问题。
①一个线程修改一个变量是安全的
②多个线程修改一个变量是不安全的
③多个线程修改不同变量是安全的
【直接原因】修改操作不是“原子的”。多线程操作中的原子性指的是一个操作是不可中断的，要么全部执行完成，要么都不执行，不能被其他线程干扰。这对于并发编程非常重要，因为如果一个操作在执行过程中被中断，可能导致数据不一致或者其他意外情况发生。（在上述多线程操作中，count++操作不是“原子的”，而是由多个CPU指令组成的，一个线程执行这些指令时，可能会在执行过程中被抢占，从而给其他线程“可乘之机”。要保证原子性操作，每个CPU指令都应该是“原子的”，即要么完全执行，要么完全不执行。）
内存可见性问题：在多线程环境下调用不可重入的函数（即不支持多线程调用的函数），可能导致数据混乱或程序崩溃。
指令重排序问题：在多线程环境下，由于编译器或处理器对指令进行重排序优化，可能导致预期之外的程序行为。

三、解决线程不安全问题–加锁（synchronized）

针对前述代码我们通过加锁解决线程安全问题

private static int count=0;
    public static void main(String[] args) throws InterruptedException {
        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();
        // 如果没有这俩 join, 肯定不⾏的. 线程还没⾃增完, 就开始打印了. 很可能打印出来的 cou
        t1.join();
        t2.join();
        // 预期结果应该是 10w
        System.out.println("count: " + count);
    }

synchronized的特性

1）互斥
synchronized 会起到互斥效果, 某个线程执⾏到某个对象的 synchronized 中时, 其他线程如果也执⾏到同⼀个对象 synchronized 就会阻塞等待.
• 进⼊ synchronized 修饰的代码块, 相当于加锁
• 退出 synchronized 修饰的代码块, 相当于解锁

理解 “阻塞等待”.
针对每⼀把锁, 操作系统内部都维护了⼀个等待队列. 当这个锁被某个线程占有的时候, 其他线程尝试进⾏加锁, 就加不上了, 就会阻塞等待, ⼀直等到之前的线程解锁之后, 由操作系统唤醒⼀个新的线程,再来获取到这个锁.
注意:
• 上⼀个线程解锁之后, 下⼀个线程并不是⽴即就能获取到锁. ⽽是要靠操作系统来 “唤醒”. 这也就是操作系统线程调度的⼀部分⼯作.
• 假设有 A B C 三个线程, 线程 A 先获取到锁, 然后 B 尝试获取锁, 然后 C 再尝试获取锁, 此时 B 和 C
都在阻塞队列中排队等待. 但是当 A 释放锁之后, 虽然 B ⽐ C 先来的, 但是 B 不⼀定就能获取到锁,⽽是和 C 重新竞争, 并不遵守先来后到的规则.
synchronized的底层是使⽤操作系统的mutex lock实现的

2)可重入
我们来看一段代码

package Thread;
//下面这个代码能打印hello吗？
public class ThreadDemo17 {
    public static void main(String[] args) {
        Object lock=new Object();
        Thread t=new Thread(()->{
            synchronized (lock){//真正加锁，同时把计数器+1（初始为0，+1之后就说明当前这个对象被该线程加锁一次）同时记录线程是谁
                synchronized (lock){//先判定当前加锁线程是否持有锁的线程，如果不是同一个线程，阻塞
                                    //如果是同一个线程，就只是++计数器即可，没有其他操作
                    System.out.println("hello");
                }//1  把计数器-1，由于计数器不为0，不会真的解锁
            }//2---应该在2这里解锁，避免1和2之间的逻辑失去锁的保护，执行到这里，再次把计数器-1，此时计数器归零，真正解锁
            //总之就是最外层的{进行加锁，最外层的}进行解锁
        });
        t.start();
    }
}

能够打印hello
在这里插入图片描述
这段代码看起来有锁冲突，但是最终不会出现阻塞，关键在于，这两次加锁，其实是对同一个线程进行的；当前由于是同一个线程，此时锁对象就知道了第二次加锁的线程，就是持有锁的线程，第二次操作，就可以直接放行通过，不会线程阻塞，这个特性，称为“可重入”。可重入锁就是为了防止程序员在写代码时不小心写出来双重锁的效果而使代码出现问题，意思就是就算不小心写了那种双重锁代码，丰富的程序机制也不会让代码有问题。

对于可重入锁来说，内部会持有两个信息
1)当前这个锁是被哪个线程持有的
2)加锁次数的计数器

四、死锁问题

死锁是多线程中一类经典问题
加锁是能解决线程安全问题，但如果加锁方式不当，就可能产生死锁。

死锁的三种典型场景

一个线程一把锁
如果锁是不可重入锁，并且一个线程对这把锁加锁两次，就会出现死锁。（判定一个锁是可重入锁还是不可重入锁的关键在于是否允许同一个线程多次获取同一个锁。可重入锁允许同一个线程多次获取同一个锁，而不可重入锁则不允许。）

两个线程，两把锁线程1获取到锁A，线程2获取到锁B，接下来，1尝试获取B，2尝试获取A，就同样出现死锁了。一旦出现死锁，线程就”卡住“无法继续工作。
eg.

//这是一个死锁代码，严重bug 
public class ThreadDemo18 {
   public static void main(String[] args) {
       Object A = new Object();
       Object B = new Object();
       Thread t1 = new Thread(() -> {
           synchronized (A) {
               // sleep 一下, 是给 t2 时间, 让 t2 也能拿到 B
               try {
                   Thread.sleep(1000);
               } catch (InterruptedException e) {
                   e.printStackTrace();
               }
               // 尝试获取 B, 并没有释放 A
               synchronized (B) {
                   System.out.println("t1 拿到了两把锁!");
               }
           }
       });

       Thread t2 = new Thread(() -> {
           synchronized (B) {
               // sleep 一下, 是给 t1 时间, 让 t1 能拿到 A
               try {
                   Thread.sleep(1000);
               } catch (InterruptedException e) {
                   e.printStackTrace();
               }
               // 尝试获取 A, 并没有释放 B
               synchronized (A) {
                   System.out.println("t2 拿到了两把锁!");
               }
           }
       });
       t1.start();
       t2.start();
   } }

这个死锁问题也可以通过约定加锁顺序解决，先对A加锁，然后对B加锁
在这里插入图片描述

N个线程M把锁（哲学家就餐问题）

产生死锁的四个必要条件----

互斥使用。获取锁的过程是互斥的，一个线程拿到这把锁，另一个线程也想获取，就需要阻塞等待。
不可抢占。一个线程拿到锁之后，只能主动解锁，不能让其他线程强行抢走锁。
请求保持。一个线程拿到锁A之后，在持有A的前提下，尝试获取B。
循环等待/环路等待。

想要解决死锁问题，核心思想是破坏上述的必要条件，只要破坏一个就好，前面2个条件是锁的基本特性，不好破坏，条件3需要看代码实际需求，也不太好破坏，只有循环等待最容易破坏。
只要指定一定的规则，就可以有效避免循环等待~
对上述哲学家就餐问题，指定加锁顺序，针对五把锁都进行编号，约定每个线程获取锁的时候，一定要先获取编号小的锁，后获取编号大的锁。

在这里插入图片描述

面试问题：谈谈你对死锁的理解？
前面四大点都是要点，需要逻辑严密，条理清楚的和面试官谈论

五、内存可见性导致的线程安全问题

如果一个线程写，一个线程读，是否会引起线程安全问题呢？我们来看下面这段代码

private static int flag=0;
    public static void main(String[] args) {
        Thread t1=new Thread(()->{
            while(flag==0){
                //循环里不做处理
            }
            System.out.println("让t线程结束");
        });
        Thread t2=new Thread(()->{
            System.out.println("请输入flag的值:");
            Scanner scanner=new Scanner(System.in);
            flag=scanner.nextInt();
        });
        t1.start();
        t2.start();//t2要等待用户输入，无论t1先启动还是t2先启动，等待用户输入的过程中，t1必然都是已经循环很多次了
    }

当我们输入一个非0的值的时候会发现t1并没有真的结束,当下这个情况，也是bug
相当于t2修改了内存，但是t1没有看到这个内存的变化，就称为“内存可见性”问题
在这里插入图片描述

总的来说，一个线程循环，一个线程修改，在多线程的情况下，编译器对代码的优化做出了错误判断，本来期待编译器把读内存的操作优化掉，变成读寄存器中缓存的值，这样的优化，有助于提高我们循环的执行效率，并且编译器发现没有修改flag,编译器做了错误判断，那么在这样的情况下，t2通过用户输入进行修改flag会导致并未在t1中生效，就出现了不能让t1顺利结束的bug。

1）如果我们对循环里面做处理，让代码休眠10ms,会出现什么结果呢？
在这里插入图片描述
我们发现，输入一个非0的值的时候会发现t1线程结束

为什么会这样呢？

内存可见性高度依赖编译器的优化的具体实现，编译器啥时候触发优化是不确定的(尽量不要出现这种问题)意味着上述代码如果稍微改动可能结果截然不同，就如上述代码，不加sleep，一秒钟循环上百亿次，load操作的整体开销非常大，优化的迫切程度更多；加了sleep，load整体开销没那么大，优化的迫切程度就降低了。

2）给 flag 加上 volatile

private volatile static int flag=0;
// 执⾏效果
// 当⽤⼾输⼊⾮0值时, t1 线程循环能够⽴即结束.

java中提供了volatile就可以使上诉优化被强制关闭，可以确保每次循环条件都会重新从内存中读取数据;就是强制读取内存，开销是大了，效率是低了，数据正确性/逻辑正确性也提高了。
volatile关键字其中一个核心功能就是保证内存可见性，另一个功能，禁止指令重排序。

总结一下：volatile 和 synchronized 有着本质的区别. synchronized 能够保证原⼦性, volatile 保证的是内存可⻅性.

六、指令重排序导致的线程安全问题

指令重排序是指处理器在执行指令时，可能会对指令的顺序进行重新排序以提高性能。重排序不会影响单线程的执行结果，但可能会导致多线程程序出现问题。因此，指令重排序可能会导致线程之间的数据竞争问题，从而让线程不安全。为了确保线程安全，需要通过加锁、volatile变量、原子操作等方式来防止指令重排序。

下面这段代码有线程安全问题吗？

package Thread;
public class ThreadDemo31 {
    private static boolean flag = false;
    private static int value = 0;

    public static void main(String[] args) {
        Thread t1 = new Thread(() -> {
            value = 10;
            flag = true;
        });

        Thread t2 = new Thread(() -> {
            if (flag) {
                System.out.println("Value: " + value);
            }
        });

        t1.start();
        t2.start();
    }
}

这是一个线程不安全代码，在这段代码中，线程t1首先更新value的值为10，然后设置flag为true。而线程t2在flag为true时，打印出value的值。由于指令重排序的影响，有可能在多线程环境下出现以下情况：

线程t1的写操作先于flag的写操作被执行，t1线程在未设置flag为true之前就被执行完毕；
线程t2的读操作先于flag的写操作被执行，导致t2线程在flag还未被设置为true时就开始读取value的值。

为了解决这个线程不安全的问题，可以使用volatile关键字来修饰flag变量，确保其能够及时刷新到主内存中，避免指令重排序的影响。
在这里插入图片描述
通过添加volatile关键字修饰flag变量，确保其不会被重排序，从而解决线程不安全问题。

七、wait和notify

wait和notify是等待通知机制，和join用途类似，由于线程之间是抢占式执⾏的, 因此线程之间执⾏的先后顺序难以预知，但是实际开发中有时候我们希望合理的协调多个线程之间的执⾏先后顺序.引入wait和notify就是为了能够从应用层面上，干预到多个不同线程代码的执行顺序。相当于是在应用程序代码中，让后执行的线程，主动放弃被调度的机会，就可以让先执行的线程，先把对应的代码执行完了。

代码示例——

import jdk.nashorn.internal.ir.Block;

//t1线程启动，就会调用wait进入阻塞等待
//t2线程启动，就会先sleep，sleep时间之后再进行notify唤醒t1
public class TreadDemo21 {
    public static void main(String[] args) {
        Object locker=new Object();
        Thread t1=new Thread(()->{
            System.out.println("t1 wait之前");
            synchronized (locker){//wait必须放到synchronized里面，因为要释放锁，前提是加上锁
                try {
                    locker.wait();//wait和sleep,join一类的，都可能会被interrupt提前唤醒因此要try.catch
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
                System.out.println("t1 wait之后");
            }
        });
        Thread t2=new Thread(()->{
            try {
                Thread.sleep(5000);
                //注意sleep要写到synchronized外面，否则，由于t1 t2执行顺序不确定，就可能t2先拿到锁
                //此时t1就没有执行到wait，t2就先notify了，结果不符合预期(这里需要确保代码现在执行wait后执notify)
                synchronized (locker){
                    //notify其实可以不用放到synchronized里面，不需要先加锁的，但是java中特别约定要放到synchronized里面
                    System.out.println("t2 notify之前");
                    locker.notify();
                    System.out.println("t2 notify之后");
                }
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        });
        t1.start();
        t2.start();
    }
}

在这里插入图片描述

上述代码的执行过程:

1)t1执行起来之后就会立即拿到锁，并且打印t1 wait之前，并且进入wait方法（释放锁+阻塞等待）
2)t2执行起来之后，先进行sleep操作，由于sleep的时间对计算机来说挺长的，就可以让t1先拿到锁
3)t2 sleep结束之后，由于t1是wait状态，锁是释放的，t2就能拿到锁,接下来打印t2 notify之前,执行notify操作，这个操作就能唤醒t1（此时t1就从WAITING状态恢复回来了)
4)但是由于t2此时还没有释放锁，t1 WAITING恢复之后，尝试获取锁就可能出现一个小小的阻塞，这个阻塞是锁竞争引起的（肉眼很难看到BLOCKED状态，这个状态的变换是非常快的）
5)执行完t2 notify之后，释放锁，t2执行完毕，t1的wait就可以获取到锁了，继续打印t1 wait之后

wait 做的事情:
• 使当前执⾏代码的线程进⾏等待. (把线程放到等待队列中)
• 释放当前的锁
• 满⾜⼀定条件时被唤醒,重新尝试获取这个锁.
wait 要搭配 synchronized 来使⽤. 脱离 synchronized 使⽤ wait 会直接抛出异常

notify ⽅法是唤醒等待的线程.
• ⽅法notify()也要在同步⽅法或同步块中调⽤，该⽅法是⽤来通知那些可能等待该对象的对象锁的其它线程，对其发出通知notify，并使它们重新获取该对象的对象锁。
• 如果有多个线程等待，则有线程调度器随机挑选出⼀个呈 wait状态的线程。(并没有 “先来后到”)
• 在notify()⽅法后，当前线程不会⻢上释放该对象锁，要等到执⾏notify()⽅法的线程将程序执⾏完，也就是退出同步代码块之后才会释放对象锁。

notifyAll(较少使用)—唤醒这个对象上所有等待的线程
假设有很多个线程，都使用同一个对象wait，针对这个对象notifyAll此时就会全都唤醒
但是这些线程在wait返回的时候，要重新获取锁，就会因为锁的竞争，使这些线程实际上是一个一个串行执行的（谁先拿到锁也是不确定的）

wait 和 sleep 的对比(经典面试题)

1. wait和sleep都有带时间的函数，时间到解除阻塞被提前唤醒，不过wait通过notify唤醒，sleep通过interrupt唤醒。
2. wait通常用于线程间的通信，在未知条件下等待；sleep用于暂停当前线程一段时间，通常在已知条件下使用。
3. wait需要在synchronized块内使用，否则会抛出IllegalMonitorStateException异常；sleep可以在任何地方使用，不需要synchronized块。
4. wait 是 Object 的方法 sleep 是 Thread 的静态方法。

最后，码字不易，如果觉得对你有帮助的话请点个赞吧，关注我，一起学习，一起进步！

Dusk_L&U

关注

28
点赞
踩
8

收藏

觉得还不错? 一键收藏
2
评论
详细剖析多线程2----线程安全问题（面试高频考点）

想给出⼀个线程安全的确切定义是复杂的，但我们可以这样认为：在多线程环境下程序能够按照预期的方式运行，并且不会出现数据竞争或不一致性的情况。因此，如果一个程序在单线程环境下能够正常运行，在多线程环境下也能够保持一致性和正确性，那么可以认为这个程序是线程安全的。反之，如果一个程序在多线程环境下出现了竞态条件、死锁、数据竞争等问题，那么可以认为这个程序是线程不安全的。
复制链接

扫一扫