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

目录

一、线程安全问题的原因

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，并且每次运行的结果都是不同的！

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();
    }
}

---

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

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

volatile 保证的是内存可见性，不能保证原子性

 volatile 不保证原子性

代码示例

这个是最初的演示线程安全的代码 .

• 给 increase 方法去掉 synchronized
• 给 count 加上 volatile 关键字.

static class Counter {
    volatile public int count = 0;
    void increase() {
        count++;
   }
}
public static void main(String[] args) throws InterruptedException {
    final Counter counter = new Counter();
    Thread t1 = new Thread(() -> {
        for (int i = 0; i < 50000; i++) {
            counter.increase();
       }
   });
    Thread t2 = new Thread(() -> {
        for (int i = 0; i < 50000; i++) {
            counter.increase();
       }
   });
    t1.start();
    t2.start();
    t1.join();
    t2.join();
    System.out.println(counter.count);
}

此时可以看到 , 最终 count 的值仍然无法保证是 100000.

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

对上面的代码进行调整 :

• 去掉 flag 的 volatile
• 给 t1 的循环内部加上 synchronized, 并借助 counter 对象加锁.

static class Counter {
    public int flag = 0;
}
public static void main(String[] args) {
    Counter counter = new Counter();
    Thread t1 = new Thread(() -> {
        while (true) {
            synchronized (counter) {
                 if (counter.flag != 0) {
                    break;
               }
           }
            // do nothing
       }
        System.out.println("循环结束!");
   });
    Thread t2 = new Thread(() -> {
        Scanner scanner = new Scanner(System.in);
        System.out.println("输入一个整数:");
        counter.flag = scanner.nextInt();
   });
    t1.start();
    t2.start();
}

---

2.3 wait和notify

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

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

public class ThreadDemo3 {
    public static void main(String[] args) throws InterruptedException {
        Object object = new Object();

        Thread t1 = new Thread(()->{
            //这个线程负责进行等待
            System.out.println("t1: wait 之前");
            try {
                synchronized (object){//1
                    object.wait();//2
                }
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("t1: wait 之后");
        });

        Thread t2 = new Thread(()->{
           //这个线程负责通知
            System.out.println("t2: notify 之前");
            synchronized (object){//3
                //notify务必要获取到锁，才能进行通知
                object.notify();//4
            }
            System.out.println("t2: notify 之后");
        });

        t1.start();
        Thread.sleep(500);
        t2.start();
        //此处如果直接执行(没有sleep),由于线程调度的不确定性
        //此时不能保证一定是先执行wait,后执行notify
        //因此在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 的静态方法 .