【Java多线程】线程安全问题与解决方案

╰半橙微兮° 2024-04-20 11:47 36阅读 0赞

**目录**

1、线程安全问题

1.2、线程安全原因

2、线程加锁

2.1、synchronized 关键字

2.2、完善代码

2.3、对同一个线程的加锁操作

3、内容补充

3.1、内存可见性问题

3.2、指令重排序问题

3.3、解决方法

3.4、总结 volatile 关键字

![78237260ab27413aaef6c9932bbdac52.gif][]

## 1、线程安全问题 ##

>  *  某个代码，无论是**单线程**下执行还是**多线程**下执行都**不会产生bug**，被称之为**“线程安全”**；
>  *  如果在单线程下执行正确，但是**多线程下会产生bug**，被称之为**“线程不安全”**或者**“存在线程安全问题”**；

**线程安全问题的典型例子**：

public class ThreadDemo {
        private static int count = 0;
    
        public static void main(String[] args) throws InterruptedException {
            // 创建两个线程. 每个线程都针对上述 count 变量循环自增 50w 次
            Thread t1 = new Thread(() -> {
                for (int i = 0; i < 500000; i++) {
                    count++;
                }
            });
            Thread t2 = new Thread(() -> {
                for (int i = 0; i < 500000; i++) {
                    count++;
                }
            });
            t1.start();
            t2.start();
    
            t1.join();
            t2.join();
            System.out.println("count = " + count);
        }
    }

![694575ea6309436aacfd904f742c5f2a.png][]

> 按照正常逻辑来看这段代码，结果应该是100w，但是通过多次运行发现这里给的却是一个50w到100w的随机值， 这就是因为出现了**线程安全问题**导致的结果错误。
> 
> **问题分析：**
> 
> count++操作实际上分成三步：
> 
> **1）**load 从内存中读取数据到cpu的寄存器
> 
> **2）**add 把寄存器中的值+1
> 
> **3）**save 把寄存器的值写回内存中
> 
> 而由于线程调度是随机调度，抢占式执行的，这就导致了两个线程的count++操作三步骤是会被打乱顺序的。
> 
> 例如 t1 线程先执行到 1）的同时， t2 线程也刚好随机调度开始执行 1），导致t1 和 t2 读取到的数据都是0，此时 t1 线程对 寄存器中值0+1，并将 1 写回内存中，接着 t2 也执行相同操作，再次将 1 写回内存中。**此时就出现了线程安全问题，两次count++却只让count自增了1次。这就是这段代码为什么不是100w的原因细节。**

### 1.2、线程安全原因 ###

**透过两个线程分别对count++，可以看到线程的不安全，有以下原因：**  
**1、根本原因**，操作系统上线程的调度策略是“随机调度，抢占式执行”的，这就给线程之间执行的顺序带来了很多的变数。是线程安全问题的**“罪魁祸首”。**  
**2、代码结构问题**，代码中多个线程同时修改一个变量。  
**3、直接原因**，上述多线程修改操作，本身不是**“原子的”**，即实际count++操作又被分成了三步操作。如果操作本身是“原子的”，那么它要么执行，要么不执行，就不会出现执行一半，就被调度走，让其他线程“可乘之机”。

*  **针对原因1**，系统底层对调度线程的逻辑就是随机调度，抢占式执行，无法干预做出任何调整。
 *  **针对原因2**，代码结构问题有时候是需求决定的，并不是每次都可以从这里入手，因此对于原因2也不好调整。
 *  **针对原因3**，既然操作非**“原子的”**，那么可以通过一些特殊手段将其打包成为“整体”，这也是我们接下来要讲到的**加锁**。

## 2、线程加锁 ##

### 2.1、synchronized 关键字 ###

![ae7eaba50aa444f288030a65e57980c4.png][]

> 其中 locker 可以是任意对象，进入 synchronized 修饰的代码块, 相当于加锁，退出 synchronized 修饰的代码块, 相当解锁。
> 
> 如果一个线程，针对一个对象加上锁之后，其他线程也尝试对这个对象加锁，就会**导致锁竞争**进而引起**阻塞（BLOCKED）**，这个阻塞会一直持续到上一个线程释放锁为止。  
> 如果是两个线程分别针对**不同的对象**进行加锁，此时不会由锁竞争，也就不会阻塞。

可以形象的理解成，每个对象在内存中存储的时候，都存有一块内存表示当前的 **"锁定" 状态**(类似于**厕所的 "有人/无人"**)。

如果当前是 "无人" 状态，那么就可以使用，使用时需要设为 "有人" 状态。

如果当前是 "有人" 状态，那么其他人无法使用，只能排队。

### 2.2、完善代码 ###

public class ThreadDemo {
        private static int count = 0;
    
        public static void main(String[] args) throws InterruptedException {
            // 随便创建个对象都行
            Object locker = new Object();
    
            // 创建两个线程. 每个线程都针对上述 count 变量循环自增 50w 次
            Thread t1 = new Thread(() -> {
                for (int i = 0; i < 500000; i++) {
                    synchronized (locker) {   //对count++进行加锁操作，打包三步为一步
                        count++;
                    }
                }
            });
            Thread t2 = new Thread(() -> {
                for (int i = 0; i < 500000; i++) {
                    synchronized (locker) {   //对count++进行加锁操作，打包三步为一步
                        count++;
                    }
                }
            });
            t1.start();
            t2.start();
    
            t1.join();
            t2.join();
            System.out.println("count = " + count);
        }
    }

![9f8ec085571549d7986b59f07431d382.png][]

> 通过对count++的整体加锁，使得每一次的count++都是一个整体，解决了此处的线程安全问题。

### 2.3、对同一个线程的加锁操作 ###

public static void main(String[] args) {
        Object locker = new Object();
        Thread t = new Thread(() -> {
            synchronized (locker) {
                synchronized (locker) {
                    System.out.println("hello synchronized");
                }
            }
        });
        t.start();
    }

> 需要注意的是，这里最直观的感觉是进行了两次加锁，会发生锁冲突。第一次针对locker加锁之后，在还没释放锁的时候又尝试对locker加锁，**理论会出现锁冲突，但是这里却可以正常打印。**
> 
> 最关键的问题在于，**【Java中的锁是可重入锁】。**这两次加锁，其实是在**同一个线程**中进行的，如果是同一个线程对同一个锁的多次加锁，是不会冲突的。

## 3、内容补充 ##

当然，还有其他能够导致出现线程安全问题的原因：**内存可见性问题****以及****指令重排序问题**

### 3.1、内存可见性问题 ###

> 下列代码**原本用意是：**当用户输入非0数字时，结束线程t1。

package thread;
    
    import java.util.Scanner;
    
    public class ThreadDemo {
        private static int flag = 0;   
    
        public static void main(String[] args) {
            Thread t1 = new Thread(() -> {
                while (flag == 0) {
                    // 循环体里, 啥都不写会触发内存可见性问题
                }
                System.out.println("t1 线程结束!");
            });
    
            Thread t2 = new Thread(() -> {
                System.out.println("请输入 flag 的值: ");
                Scanner scanner = new Scanner(System.in);
                flag = scanner.nextInt();
            });
    
            t1.start();
            t2.start();
        }
    }

> 实际运行结果时发现无法结束，t2修改了内存，但是t1内有看到这个内存的变化，就称之为“内存可见性”问题。出现这一问题是**JVM的代码优化导致**的。
> 
> **t1 线程中的while语句每次循环是都有两个操作：**
> 
> 1、load 读取内存中 flag 的值到 cpu 寄存器中
> 
> 2、拿到寄存器的值和 0 比较

> 上述循环中循环的执行速度非常之快，反复的执行1和2，即使是1秒也可能反复执行了几百万次。而在执行的过程中，有两个关键要点：
> 
> 1、JVM识别到 load 操作执行的几百万次结果每次都一样（输入前的等待时间里）。
> 
> 2、而由于 load 操作花费的开销远远超过剩余的其他操作（访问寄存器的操作速度远远超过访问内存）
> 
> 每次循环可能就是百分之九十九的时间都消耗在 load 操作上，而百分之一的时间消耗在其他操作上，**而且JVM发现每次 load 操作读取到的数据都是一样的，那么此时JVM就会认为此处每次 load 的操作是否有存在的必要呢，于是乎JVM就可能会自动执行了代码优化，将上述的 load 操作优化了（只有前几次进行了 load，后续发现 load 一直没有变化，分析代码也没发现哪里修改了flag，因此激进的将load操作优化成了直接使用寄存器中之前“缓存”的值），从而达到大幅度提高循环的执行速度的目的。**

### 3.2、指令重排序问题 ###

> 指令重排序也是编译器优化的一种方式。保证逻辑不变的前提下，调整原有代码的执行顺序，提高程序的效率。

### 3.3、解决方法 ###

> 由于上述两种问题**都是由于JVM代码优化导致的**。
> 
> Java提供的 **volatile 关键字**就可以使上述的优化被**强制关闭**，可以确保每次循环条件都会重新从内存中读取数据。  
> 强制读取内存，虽然开销大了，效率也低了，但是数据的准确性、逻辑的准确性都提高了。

![06c437ff0f324da4918f954d8c4853ab.png][]

> 只需要对 flag 添加一个 **volatile 关键字**即可解决这一问题。

![bd73a49993f249b3961e2970bf3e8a51.png][]

###  ###

### 3.4、总结 volatile 关键字 ###

> **1、保证内存可见性，每次访问变量必须都要重新读取内存，而不会优化到寄存器/缓存中  
> 2、禁止指令重排序，针对被 volatile 修饰的变量的读写操作相关指令，是不能被重排序的。**

![4503566693ac4a32848b31440efdc845.gif][]

**【博主推荐】**

[【Java多线程】Thread类的基本用法-CSDN博客![icon-default.png?t=N7T8][icon-default.png_t_N7T8]https://blog.csdn.net/zzzzzhxxx/article/details/136121421?spm=1001.2014.3001.5501][Java_Thread_-CSDN_icon-default.png_t_N7T8_icon-default.png_t_N7T8_https_blog.csdn.net_zzzzzhxxx_article_details_136121421_spm_1001.2014.3001.5501] [【Java多线程】对进程与线程的理解-CSDN博客![icon-default.png?t=N7T8][icon-default.png_t_N7T8]https://blog.csdn.net/zzzzzhxxx/article/details/136115808?spm=1001.2014.3001.5501][Java_-CSDN_icon-default.png_t_N7T8_icon-default.png_t_N7T8_https_blog.csdn.net_zzzzzhxxx_article_details_136115808_spm_1001.2014.3001.5501]

[【数据结构】二叉树的三种遍历（非递归讲解）-CSDN博客![icon-default.png?t=N7T8][icon-default.png_t_N7T8]https://blog.csdn.net/zzzzzhxxx/article/details/136044643?spm=1001.2014.3001.5501][-CSDN_icon-default.png_t_N7T8_icon-default.png_t_N7T8_https_blog.csdn.net_zzzzzhxxx_article_details_136044643_spm_1001.2014.3001.5501]

**如果觉得作者写的不错，求给博主一个大大的点赞支持一下，你们的支持是我更新的最大动力！**

[78237260ab27413aaef6c9932bbdac52.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/89a91fa0de9c4182a19dc1466a9b8019.gif
[694575ea6309436aacfd904f742c5f2a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/2e76227e81cb4b00af8f240ab526357b.png
[ae7eaba50aa444f288030a65e57980c4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/a754a78658b34c3eb396a48c591a7e59.png
[9f8ec085571549d7986b59f07431d382.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/e66ba86196ad4ee6905cfc42cebb09f2.png
[06c437ff0f324da4918f954d8c4853ab.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/1d60775d013847bc82b26e711bdb0871.png
[bd73a49993f249b3961e2970bf3e8a51.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/79877c8105b440678ea034253525654a.png
[4503566693ac4a32848b31440efdc845.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/4b88daeb51f0495f849ffa4c09406246.gif
[icon-default.png_t_N7T8]: https://csdnimg.cn/release/blog_editor_html/release2.3.6/ckeditor/plugins/CsdnLink/icons/icon-default.png?t=N7T8
[Java_Thread_-CSDN_icon-default.png_t_N7T8_icon-default.png_t_N7T8_https_blog.csdn.net_zzzzzhxxx_article_details_136121421_spm_1001.2014.3001.5501]: https://blog.csdn.net/zzzzzhxxx/article/details/136121421?spm=1001.2014.3001.5501
[Java_-CSDN_icon-default.png_t_N7T8_icon-default.png_t_N7T8_https_blog.csdn.net_zzzzzhxxx_article_details_136115808_spm_1001.2014.3001.5501]: https://blog.csdn.net/zzzzzhxxx/article/details/136115808?spm=1001.2014.3001.5501
[-CSDN_icon-default.png_t_N7T8_icon-default.png_t_N7T8_https_blog.csdn.net_zzzzzhxxx_article_details_136044643_spm_1001.2014.3001.5501]: https://blog.csdn.net/zzzzzhxxx/article/details/136044643?spm=1001.2014.3001.5501