线程安全问题的原因和解决方案

朱wwww

于 2023-04-03 22:30:48 发布

阅读量935

点赞数 2

文章标签： java jvm 开发语言

本文链接：https://blog.csdn.net/weixin_64597430/article/details/129914953

版权

一、线程安全问题的原因

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

1.1 抢占式执行

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

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

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

1.3 原子性

如果修改操作是原子性的，那么出现线程安全问题的概率还是比较低的。但如果是非原子的（++操作，其可以被拆分为load，add，save三个操作），那么出现问题的概率就非常高了。

1.4 内存可见性问题

如果一个线程读，一个线程改。这样的操作就可能引起内存可见性问题，也会出现线程安全问题。

1.5 指令重排序

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

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

二、解决方案

2.1 加锁

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

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

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

class Counter {
    public int count;
    public void add(){
        count++;
    }
}
public class Main {
    public static void main(String[] args) throws InterruptedException {
        Counter counter = new Counter();
        Thread t1 = new Thread(()->{
           for(int i = 0;i<50000;i++){
               counter.add();
           }
        });

        Thread t2 = new Thread(()->{
            for(int i = 0;i<50000;i++){
                counter.add();
            }
        });
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println(counter.count);
    }
}

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

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

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


class Counter {
    public int count;
    public synchronized void add(){
        count++;
    }
}
public class Main {
    public static void main(String[] args) throws InterruptedException {
        Counter counter = new Counter();
        Thread t1 = new Thread(()->{
           for(int i = 0;i<50000;i++){
               counter.add();
           }
        });

        Thread t2 = new Thread(()->{
            for(int i = 0;i<50000;i++){
                counter.add();
            }
        });
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println(counter.count);
    }
}

下图就是其原理图。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线程并没有结束，程序仍然在运行。

import java.util.Scanner;

class Counter {
    public int flag;
}

public class ThreadDemo {
    public static void main(String[] args) {

        Counter counter = new Counter();
        Thread t1 = new Thread(()->{
           while(counter.flag==0){
               //此处为了代码简洁好演示，什么都不做
           }
        });

        Scanner sc = new Scanner(System.in);
        Thread t2 = new Thread(()->{
            counter.flag = sc.nextInt();
        });

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

这是为什么呢？这里比较这个操作我们可以分为两步来进行理解，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关键字之后，程序就可以正常运行了。

import java.util.Scanner;

class Counter {
    public volatile int flag;
}

public class ThreadDemo {
    public static void main(String[] args) {

        Counter counter = new Counter();
        Thread t1 = new Thread(()->{
           while(counter.flag==0){
               //此处为了代码简洁好演示，什么都不做
           }
        });

        Scanner sc = new Scanner(System.in);
        Thread t2 = new Thread(()->{
            counter.flag = sc.nextInt();
        });

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

2.3 wait和notify

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

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

还是两个线程t1和t2，这两个线程的工作就是使用for循环对count进行++操作50000次。在没有处理线程安全问题的时候，结果肯定不是100000。而我们通过wait和notify来实现上述操作的话，结果如下：

import java.util.Scanner;

class Counter {
    public int count;

    public void add() {
        count++;
    }
}

public class ThreadDemo {
    public static void main(String[] args) throws InterruptedException {
        Object o1 = new Object();
        Counter counter = new Counter();
        Thread t1 = new Thread(()->{
            for(int i = 0;i<50000;i++){
                counter.add();
            }
            synchronized (o1){
                o1.notify();
            }
        });

        Thread t2 = new Thread(()->{
            synchronized (o1){
                for(int i = 0;i<50000;i++){
                    counter.add();
                }
            }
        });
        t1.start();
        Thread.sleep(500);
        t2.start();
        t1.join();
        t2.join();
        System.out.println(counter.count);
    }
}

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

我们要注意的是，虽然我们的wait是阻塞在了synchronized代码块里了，但是实际上，这里的阻塞是释放了锁的。此时其他的线程是可以获取到o1这个对象的锁的。

这个notify方法是和wait方法配套使用的，这里为什么要使用synchronized代码块来包裹住呢？这是因为，notify是根据对象来进行通知的。如果wait，synchronized和notify使用的是同一个对象，那么才可以生效。如果wait和notify使用的对象不是同一个对象，此时notify不会有任何效果。

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

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

这就是我对线程安全问题的原因与如何解决的看法，由于本人学疏才浅，文章难免有错误之处。并且解决线程安全问题肯定也不止这三种方法。因此希望各位大佬能在评论区之处错误与疏漏之处，小子不胜感激！

朱wwww

关注

2
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
线程安全问题的原因和解决方案

我们的预期是，当t2修改了flag的值之后，使flag不再为0，此时跳出循环，线程t1结束。这里我们也发现，说是保证原子性，不是让这里的三个操作一次执行完成，也不是这三步操作过程中不进行调度，而是让其他想操作的线程阻塞等待了。根据比较结果，来进行下一步的操作。总的来说，就是wait和notify规定了t1和t2线程的执行顺序，因此也就使t1和t2的执行有了顺序，解决了抢占式执行，随机调度。我们要注意的是，虽然我们的wait是阻塞在了synchronized代码块里了，但是实际上，这里的阻塞是释放了锁的。
复制链接

扫一扫