devbox
凡人多烦事01
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

线程安全问题的原因和解决方案_造成线程安全问题的主要诱因有两点

作者：凡人多烦事01 | 2024-05-03 04:29:33

赞

踩

造成线程安全问题的主要诱因有两点

目录

一、线程安全问题的原因

1.1 抢占式执行

1.2 多个线程同时修改同一个变量

1.3 原子性

1.4 内存可见性问题

1.5 指令重排序

二、解决方案

2.1 加锁

2.2 volatile

volatile 和 synchronized 有着本质的区别

 volatile 不保证原子性

synchronized 既能保证原子性, 也能保证内存可见性

2.3 wait和notify

线程安全问题是多线程中的重点和难点，面试中重点考察，要求掌握

一、线程安全问题的原因

导致线程安全的原因有很多，这里我列出五个较为常见的原因。

1.1 抢占式执行——罪魁祸首

CPU的调度方法为抢占式执行，随机调度，这个是导致线程安全问题的最根本的原因。但是这个原因我们无能为力，无法改变。

1.2 多个线程同时修改同一个变量

当修改变量这个操作并非原子性的。这样在并发的环境下就很容易出现线程安全问题。这种情况可以通过代码结构来进行一定的规避，但是这种方法不是一个普适性特别高的方案。

1.3 原子性

如果修改操作是原子性的，那么出现线程安全问题的概率还是比较低的。但如果是非原子的（++操作，其可以被拆分为load，add，save三个操作），那么出现问题的概率就非常高了。能够把修改行为变成原子操作，就是解决线程安全问题的关键方法！（synchronized关键字）

1.4 内存可见性问题

内存可见性是指当一个线程修改了共享变量的值，其他线程能够立即感知这个修改。

如果一个线程读，一个线程改（这样的操作就可能引起内存可见性问题，也会出现线程安全问题）。此时前一个线程读取到的值，不一定是修改之后的值，即读线程没有感知到变量的变化——归根结底是编译器/JVM在多线程环境下优化时产生了误判。（volatile关键字）

1.5 指令重排序

指令重排序是因为编译器对我们的代码进行了一些“自作主张”的优化，编译器会在保持逻辑不变的情况下。调整代码的顺序，从而加快代码的执行效率。这样也会出现线程安全问题。

上面就是五种较为典型的导致线程安全问题的原因。

二、解决方案

2.1 加锁

从上述造成线程安全问题的原因分析，原子性是导致线程安全问题的一大原因！那么如何从原子性入手来解决线程安全问题？那么就是加锁！加锁就可以将不是原子的操作转换成原子的。在这里我使用synchronized来进行加锁。

下面举一个有线程安全问题的例子：

这个例子是创建了两个线程，这两个线程想对同一个对象（count）来进行++操作，每个线程共操作50000次，一共100000次。按常理说在线程执行完之后，我们的预期是100000。但是这里我们发现，输出的结果不是100000，并且每次运行的结果都是不同的！

  1. class Counter {
  2.     public int count;
  3.     public void add(){
  4.         count++;
  5.     }
  6. }
  7. public class Main {
  8.     public static void main(String[] args) throws InterruptedException {
  9.         Counter counter = new Counter();
  10.         Thread t1 = new Thread(()->{
  11.            for(int i = 0;i<50000;i++){
  12.                counter.add();
  13.            }
  14.         });
  15.  
  16.         Thread t2 = new Thread(()->{
  17.             for(int i = 0;i<50000;i++){
  18.                 counter.add();
  19.             }
  20.         });
  21.         t1.start();
  22.         t2.start();
  23.         t1.join();
  24.         t2.join();
  25.         System.out.println(counter.count);
  26.     }
  27. }

这就是多个线程修改一个变量而导致的线程安全问题。其原因就是++这个操作并不是原子性的，它分为load，add，save三个操作。

而我们使用了synchronized之后就不同了：

我将add方法加上了synchronized，此时答案就是我们预期的结果100000。加了synchronized之后，进入了方法就会加锁，出了方法就会解锁。如果两个线程同时尝试加锁，此时只有一个线程可以获取锁成功，而另一个线程就会阻塞等待。阻塞到另一个线程释放锁之后，当前线程才能获取锁成功。
 

  1. class Counter {
  2.     public int count;
  3.     public synchronized void add(){
  4.         count++;
  5.     }
  6. }
  7. public class Main {
  8.     public static void main(String[] args) throws InterruptedException {
  9.         Counter counter = new Counter();
  10.         Thread t1 = new Thread(()->{
  11.            for(int i = 0;i<50000;i++){
  12.                counter.add();
  13.            }
  14.         });
  15.  
  16.         Thread t2 = new Thread(()->{
  17.             for(int i = 0;i<50000;i++){
  18.                 counter.add();
  19.             }
  20.         });
  21.         t1.start();
  22.         t2.start();
  23.         t1.join();
  24.         t2.join();
  25.         System.out.println(counter.count);
  26.     }
  27. }

 

下图就是其原理图。t1和t2在竞争锁，但是t1竞争成功了，因此t2就只能阻塞等待。直到t1释放锁的时候，才能让lock继续执行，t2才能继续向下执行。

 lock的操作把刚才的t2的load推迟到了t1的save之后，就避免了脏读问题。这里我们也发现，说是保证原子性，不是让这里的三个操作一次执行完成，也不是这三步操作过程中不进行调度，而是让其他想操作的线程阻塞等待了。加锁的本质就是把并发变成了串行。

synchronized使用方法：

1.修饰方法：

1）修饰普通方法。锁对象是this。

2）修静态方法。锁对象是类对象。

2.修饰代码块。

锁对象是显式/手动指定的。

注意：

        如果两个线程对同一个对象进行加锁，此时就会出现锁竞争/锁冲突，一个线程能够获取到锁，而另一个线程只能阻塞等待，等到上一个线程解锁，它才能获取锁成功！

        如果两个线程对不同对象进行加锁，那么就不会发送锁竞争/锁冲突，两个线程都能获取到各自的锁，不会有阻塞等。

2.2 volatile

当一个线程读，一个线程写的时候，此时就容易出现内存可见性问题。而这里的volatile就是用来解决内存可见性问题的。下面我给大家举一个内存可见性的例子： 

这个例子是创建了两个线程，一个线程不断地读一个变量，而一个线程修改一个变量。我们的预期是，当t2修改了flag的值之后，使flag不再为0，此时跳出循环，线程t1结束。但是事与愿违，当我们的t2修改了flag的值之后，t1线程并没有结束，程序仍然在运行。

  1. import java.util.Scanner;
  2.  
  3. class Counter {
  4.     public int flag;
  5. }
  6.  
  7. public class ThreadDemo {
  8.     public static void main(String[] args) {
  9.  
  10.         Counter counter = new Counter();
  11.         Thread t1 = new Thread(()->{
  12.            while(counter.flag==0){
  13.                //此处为了代码简洁好演示，什么都不做
  14.            }
  15.         });
  16.  
  17.         Scanner sc = new Scanner(System.in);
  18.         Thread t2 = new Thread(()->{
  19.             counter.flag = sc.nextInt();
  20.         });
  21.  
  22.         t1.start();
  23.         t2.start();
  24.     }
  25. }

 

这是为什么呢？这里比较这个操作我们可以分为两步来进行理解，load和cmp。load就是把内存中的flag的值读取到寄存器中。cmp就是把寄存器中的值和0进行比较。根据比较结果，来进行下一步的操作。

而上述代码中，我们的比较操作是在一个while循环中进行的，它的执行速度极快。而循环比较了这么多次，在t2修改flag之前，flag的值和load读取到的结果是一样的。并且，load和cmp操作相比，速度慢很多。由于load的执行速度相对于cmp而言太慢了，这时候编译器就做出了一个大胆的决定！不再重复执行load，只读取一次load放入寄存器中，这时候就导致t2即使修改了flag的值，也没用了，因为已经不进行load操作了。此时读线程没有感知到变量的变化。这就是内存可见性问题。归根结底就是编译器优化在多线程环境下优化时产生了误判。

此时，volatile就能发挥作用了。将flag变量加上volatile关键字，告诉编译器，这个变量是“易变”的，不用进行编译器优化。

下面是添加了volatile之后的例子：

添加了volatile关键字之后，程序就可以正常运行了。 
 

  1. import java.util.Scanner;
  2.  
  3. class Counter {
  4.     public volatile int flag;
  5. }
  6.  
  7. public class ThreadDemo {
  8.     public static void main(String[] args) {
  9.  
  10.         Counter counter = new Counter();
  11.         Thread t1 = new Thread(()->{
  12.            while(counter.flag==0){
  13.                //此处为了代码简洁好演示，什么都不做
  14.            }
  15.         });
  16.  
  17.         Scanner sc = new Scanner(System.in);
  18.         Thread t2 = new Thread(()->{
  19.             counter.flag = sc.nextInt();
  20.         });
  21.  
  22.         t1.start();
  23.         t2.start();
  24.     }
  25. }

面试题：volatile 和 synchronized 有着本质的区别

synchronized 既能保证原子性 , 也能保证内存可见性。
volatile 保证的是内存可见性，不能保证原子性
 volatile 不保证原子性
代码示例
这个是最初的演示线程安全的代码 .
  • 给 increase 方法去掉 synchronized
  • 给 count 加上 volatile 关键字. 
  1. static class Counter {
  2.     volatile public int count = 0;
  3.     void increase() {
  4.         count++;
  5.    }
  6. }
  7. public static void main(String[] args) throws InterruptedException {
  8.     final Counter counter = new Counter();
  9.     Thread t1 = new Thread(() -> {
  10.         for (int i = 0; i < 50000; i++) {
  11.             counter.increase();
  12.        }
  13.    });
  14.     Thread t2 = new Thread(() -> {
  15.         for (int i = 0; i < 50000; i++) {
  16.             counter.increase();
  17.        }
  18.    });
  19.     t1.start();
  20.     t2.start();
  21.     t1.join();
  22.     t2.join();
  23.     System.out.println(counter.count);
  24. }
此时可以看到 , 最终 count 的值仍然无法保证是 100000.
synchronized 既能保证原子性, 也能保证内存可见性
对上面的代码进行调整 :
  • 去掉 flag 的 volatile
  • 给 t1 的循环内部加上 synchronized, 并借助 counter 对象加锁. 
  1. static class Counter {
  2.     public int flag = 0;
  3. }
  4. public static void main(String[] args) {
  5.     Counter counter = new Counter();
  6.     Thread t1 = new Thread(() -> {
  7.         while (true) {
  8.             synchronized (counter) {
  9.                  if (counter.flag != 0) {
  10.                     break;
  11.                }
  12.            }
  13.             // do nothing
  14.        }
  15.         System.out.println("循环结束!");
  16.    });
  17.     Thread t2 = new Thread(() -> {
  18.         Scanner scanner = new Scanner(System.in);
  19.         System.out.println("输入一个整数:");
  20.         counter.flag = scanner.nextInt();
  21.    });
  22.     t1.start();
  23.     t2.start();
  24. }

2.3 wait和notify

通过上面的了解我们知道，导致线程安全问题的最主要原因就是抢占式执行，随机调度。那么如何控制线程有顺序的工作呢？那么就需要用到wait和notify了。其中wait，notify还有notifyAll这三个方法都是Object类的方法。

如何使用wait和notify来处理上面的线程安全问题？下面我们给出一个例子：

  1. public class ThreadDemo3 {
  2.     public static void main(String[] args) throws InterruptedException {
  3.         Object object = new Object();
  4.  
  5.         Thread t1 = new Thread(()->{
  6.             //这个线程负责进行等待
  7.             System.out.println("t1: wait 之前");
  8.             try {
  9.                 synchronized (object){//1
  10.                     object.wait();//2
  11.                 }
  12.             } catch (InterruptedException e) {
  13.                 e.printStackTrace();
  14.             }
  15.             System.out.println("t1: wait 之后");
  16.         });
  17.  
  18.         Thread t2 = new Thread(()->{
  19.            //这个线程负责通知
  20.             System.out.println("t2: notify 之前");
  21.             synchronized (object){//3
  22.                 //notify务必要获取到锁，才能进行通知
  23.                 object.notify();//4
  24.             }
  25.             System.out.println("t2: notify 之后");
  26.         });
  27.  
  28.         t1.start();
  29.         Thread.sleep(500);
  30.         t2.start();
  31.         //此处如果直接执行(没有sleep),由于线程调度的不确定性
  32.         //此时不能保证一定是先执行wait,后执行notify
  33.         //因此在t1.start后加个sleep

 

我们要理解wait操作是干什么的。wait操作首先释放了锁， 然后进行阻塞等待，接着等到收到通知之后，重新尝试获取锁，并且在获取锁之后，继续往下执行。如果迟迟获取不到通知的话，那么就会一直阻塞等待，此时线程处于WAITING状态。当然，wait也有定时等待的版本，阻塞等待到一定时间之后，如果收不到通知，就不会再阻塞等待了。

我们要注意的是，wait操作需要搭配synchronized来使用，synchronized先获取锁，wait再释放锁，单独使用wait会报错（锁状态异常）。虽然我们的wait是阻塞在了synchronized代码块里了，但是实际上，这里的阻塞是释放了锁的。此时其他的线程是可以获取到o1这个对象的锁的。

这个notify方法是和wait方法配套使用的，这里为什么要使用synchronized代码块来包裹住呢？这是因为，notify是根据对象来进行通知的。注意：1234四个对象必须相同，才能够正确生效（即锁对象相同），即wait，synchronized和notify使用的是同一个对象，那么才可以生效。如果wait和notify使用的对象不是同一个对象，此时notify不会有任何效果。

在代码中，两个start方法之间夹了一个Thread.sleep(500)操作。因为线程调度的不确定性，无法保证一定是wait先执行，notify后执行。这个操作的原因就是避免notify在wait之前执行。如果notify在wait之前执行，那么就相当于notify白通知了一次，此时此处的wait也就无法被唤醒了。

总的来说，就是wait和notify规定了t1和t2线程的执行顺序，因此也就使t1和t2的执行有了顺序，解决了抢占式执行，随机调度。因此也就解决了上述线程安全问题。

面试题：wait 和 sleep 的对比（面试题）
其实理论上 wait 和 sleep 完全是没有可比性的，因为一个是用于线程之间的通信的，一个是让线程阻塞一段时间，
唯一的相同点就是都可以让线程放弃执行一段时间
那么上述场景,使用join 或者sleep行不行呢?
使用join，则必须要t1彻底执行完,，t2才能运行。如果是希望t1先千50%的活，就让t2开始行动，join 无能为力。
使用sleep，指定一个休眠时间的。但是t1执行的这些活，到底花了多少时间不知道。
总结：
1. wait 需要搭配 synchronized 使用 . sleep 不需要 .
2. wait 是 Object 的方法 sleep 是 Thread 的静态方法 .
声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/凡人多烦事01/article/detail/527805
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号