【JavaEE】并发编程（多线程）线程安全问题&内存可见性&指令重排序

妖狐艹你老母 2024-03-27 09:06 68阅读 0赞

**目录**

第一个问题：什么是线程安全问题？

第二个问题：为什么会出现线程安全问题？

第三个问题：如何解决多线程安全问题？

第四个问题：产生线程不安全的原因有哪些？

第五个问题：内存可见性问题及解决方案

第六个问题：指令重排序问题？

--------------------

## 第一个问题：什么是线程安全问题？ ##

线程安全就是多线程访问时，采用了加锁机制，当一个线程访问该类的某个数据时，进行保护，其他线程不能进行访问直到该线程读取完，其他线程才可使用。不会出现数据不一致或者数据污染。 线程不安全就是不提供数据访问保护，有可能出现多个线程先后更改数据造成所得到的数据是脏数据。

## 第二个问题：为什么会出现线程安全问题？ ##

出现线程安全的问题的根源其实是在于我们之前说过的多线程“抢占式执行，随机调度”的特性决定的。当我们在使用多线程进行编程的时候，是躲不过这一“万恶之源”的。我们只可以通过一些编程手段来解决这些线程安全的问题。

我们可以看一下下面这部分的代码。

（这是一个典型的多线程的线程安全问题，里面会出现脏数据，也就是多个线程对同一个变量进行更改的问题）

首先我们来看当我们写两个线程进行更改同一个变量的情况：

package Thread;
    
    class Countsum{
        private static int count=0;
        public  void CountAdd(){
            count++;
        }
        public int getCount(){
    
            return count;
        }
    }
    public class ThreadDemo15 {
        public static void main(String[] args) {
            Countsum countsum=new Countsum();
            //第一个线程t1
            Thread t1 =new Thread(()->{
    
                for (int i = 0; i <50000; i++) {
                    countsum.CountAdd();
                }
    
            });
            //第二个线程t2
            Thread t2=new Thread(()->{
                for(int i=0;i<50000;i++){
                    countsum.CountAdd();
                }
            });
            //两个线程操作同一个变量
            t1.start();
            t2.start();
            //让t1，t2两个线程执行完，再执行main线程，这里让main线程阻塞
            try {
                t1.join();
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
            try {
                t2.join();
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
            //打印最后的结果，看和预期值10_0000是否一致。
            System.out.println(countsum.getCount());
        }
    
    
    }

预期值：10\_0000

第一次运行：64603![de737d6e58cb40739bc90a2c83171e22.png][]

第二次运行：73388

![847ec9867a1044908e904648376360f4.png][]

第三次运行：75233

![92e0a699607947e784f1a7a3cf793b11.png][]

每一次的结果都和预期值相差甚远。这就说明期间发生了脏读了，也揭示了线程的不安全性。

那么具体的过程是怎样变成这样的？

首先我们需要知道count++这个过程到底是怎么实现的。

我们从CPU的角度出发：count++主要是由三个指令实现的

**1、（load）把内存中count的值加载到CPU的寄存器当中**

**2、（add）把寄存器中的数值加1**

**3、（save）把寄存器中的值放回到内存中，对原来的值进行覆盖。**

我们画个示意图：

![7eb8ad246b2d4dd8905aa98d7aadcae7.png][]

同样，也正是因为这个过程需要多个步骤来进行实现，就使得多线程的“抢占式执行，随机调度”得以充分发挥作用了。我们都知道排列组合。在这10万次循环中，会有无数种排列的情况出现，所以基本上每一次的结果不会相等，但是不排除相等的情况。

这里我们就列举一种情况来进行说明即可：

比如这种情况：

![0616954f79f14443a4d2b3df53070a91.png][]

我们来分析一下这个过程：

假设初始值为0.

![72fdc3ad01b94ca4bb9c2189a726d8ff.png][] 如果是正常情况下结果应该是2，但是这里结果却是1。这就和上面的程序是一样的道理。

如果要得到正确结果应该是这种的步骤：

![4a922172a1894e5cadd8fd7c0bb10e35.png][]

就是像这样的能够得到正确的数据。

## 第三个问题：如何解决多线程安全问题？ ##

答案：**加锁**

那么java中加锁的方式有很多种，最常使用的是 **synchronized** 关键字。我们可以给上述代码的自增函数内部自增操作上加synchronized 关键字或者直接给自增的方法加上synchronized关键字就是加锁成功了。

加锁成功后在看一下程序：

package Thread;
    
    class Countsum{
        private static int count=0;
        public  void CountAdd(){
            synchronized (this){
                count++;
            }
    
        }
        public int getCount(){
    
            return count;
        }
    }
    public class ThreadDemo15 {
        public static void main(String[] args) {
            Countsum countsum=new Countsum();
            //第一个线程t1
            Thread t1 =new Thread(()->{
    
                for (int i = 0; i <50000; i++) {
                    countsum.CountAdd();
                }
    
            });
            //第二个线程t2
            Thread t2=new Thread(()->{
                for(int i=0;i<50000;i++){
                    countsum.CountAdd();
                }
            });
            //两个线程操作同一个变量
            t1.start();
            t2.start();
            //让t1，t2两个线程执行完，再执行main线程，这里让main线程阻塞
            try {
                t1.join();
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
            try {
                t2.join();
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
            //打印最后的结果，看和预期值10_0000是否一致。
            System.out.println(countsum.getCount());
        }
    
    
    }

![4cf192afade5444c9b0eab45e76c9ae8.png][]

这个结果就和我们的预期值一样了。

## 第四个问题：产生线程不安全的原因有哪些？ ##

**1、线程是抢占式执行的，线程间的调度充满随机性。(线程不安全的根本原因)**

**2、多个线程对同一个变量进行修改操作。**

**3、针对变量的操作不是原子的，通过加锁操作就是把几个指令打包成一个原子的。**

**4、内存可见性。**

这里需要简单理解一下几个名词：

1）原子性 我们可以简单的理解为打包为一个整体

## 第五个问题：内存可见性问题及解决方案 ##

2）内存可见性

内存可见性问题其实是编译器优化的结果。

我们这里以**一个线程读取数字，一个线程修改数字**为例：

t线程负责读取istrue的值，main线程负责修改istrue的值。

package Thread;
    
    import java.util.Scanner;
    
    public class ThreadDemo16 {
        public static int istrue=0;
        public static void main(String[] args) {
            Thread t=new Thread(()->{
                while(istrue==0){
    
                }
                System.out.println("t线程结束！");
            });
            t.start();
            Scanner scanner=new Scanner(System.in);
            System.out.println("请输入一个数字:");
            istrue=scanner.nextInt();
            System.out.println("main线程执行完毕");
    
        }
    }

我们看一下执行结果：

![13a1306cd3d34168b3b356e5e061f235.png][]

当我们输入一个5的时候，我们原来是应该让t线程结束的，然而main线程结束后，t线程却进入了死循环当中，也就是说，此时的istrue还是0，并没有得到修改。这到底是什么原因导致的呢？

原因是这样的：由于从内存中读是要比从寄存器中读慢很多的（好几个数量级吧大概） 这里的t线程需要不断的循环读取istrue的值，如果我们的main线程不做出修改，那么t线程读取到的值就一直是一样的值。于是编译器就可能会进行优化，让t线程直接从寄存器中读取数据，也就是省去了load的操作，这一大胆的行为使得后续我们对istrue进行的修改都无法让t线程感知到，也就是说修改失去了作用。所以t线程并不会终止。

那么如何解决内存可见性的问题呢？

1、使用synchronized 关键字。synchronized 不光能够保证原子性，同时也能够保证内存可见性。被synchronized 包裹起来的代码，编译器就不敢轻易做出上述假设，就相当于手动禁止了编译器的优化。

2、使用volatile关键字。volatile和原子性无关，但是能够保证内存可见性。使得编译器每次都要重新从内存中读取istrue的值。

方案一：使用volatile关键字（最常用）

public static volatile int istrue=0;

![a7078d8dd0f44e5a82867fdaf7331b06.png][]

方案二： 使用synchronized关键字

有时候我们也可以使用一些别的操作，比如sleep啊等等的，不过这些不太可靠哈。

while(istrue==0){
                        try {
                            Thread.sleep(1000);
                        } catch (InterruptedException e) {
                            throw new RuntimeException(e);
                        }
    
                    }

![724942de51f0401d9fbc1111e98584b0.png][]

编译器优化总的来说还是比较玄学的！！！

说到这，还有一个由编译器优化引发的问题！！!

## 第六个问题：指令重排序问题？ ##

指令重排序问题听着挺吓人，其实就是个排序问题罢了。

指令重排序是编译器优化的结果，编译器会对我们写的代码进行重排序从而来提高编译的效率，但是有时候一旦发生指令重排序，就可能会使得程序与我们预期的结果不同了。（在单线程中指令的重排序不会产生太大的影响，但是在多线程中容易出现严重bug，需要多注意！）我们要保证逻辑不变，对顺序进行调整。（使用synchronized可以进行禁止指令的重排序）

[de737d6e58cb40739bc90a2c83171e22.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/9522b42675424176abe9c54902a23a9a.png
[847ec9867a1044908e904648376360f4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/30dfaf12127d47c296af7f2b9ebb2b1e.png
[92e0a699607947e784f1a7a3cf793b11.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/b05d7d20c145487b84f823c92e88b42c.png
[7eb8ad246b2d4dd8905aa98d7aadcae7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/a12dab44130e4b0ea27b71257cd7f3b7.png
[0616954f79f14443a4d2b3df53070a91.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/3702f971e05d48b980f6a5563ce63218.png
[72fdc3ad01b94ca4bb9c2189a726d8ff.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/1c2b3244ac354112a4203f7574ed14c8.png
[4a922172a1894e5cadd8fd7c0bb10e35.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/9b083e7253804080a1de01137580cb54.png
[4cf192afade5444c9b0eab45e76c9ae8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/d55f634be3d64ba191fa254338511b72.png
[13a1306cd3d34168b3b356e5e061f235.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/ddc1ed5820a245cdb07fa7f4f079fd96.png
[a7078d8dd0f44e5a82867fdaf7331b06.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/9d1285eaf5c54338bba82e3cf3213afc.png
[724942de51f0401d9fbc1111e98584b0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/5dae1aa9648b4f0ea5bde30862df8c7c.png