Java编程基础知识之线程篇（其三）

比眉伴天荒 2024-04-07 13:21 12阅读 0赞

前面文章回顾：

[Java编程基础知识之线程篇（其一）][Java]

[Java编程基础知识之线程篇（其二）][Java 1]

.........

**目录**

前言：

一、多线程带来的的风险-线程安全 (重点)

1.线程安全的概念

2.线程不安全的原因

1）线程抢占式执行

2）线程修改共享数据&&非原子操作

3）内存可见性

4）代码重序性

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

## 前言： ##

本章主要介绍线程的不安全问题及其造成原因。

## 一、**多线程带来的的风险****-****线程安全** **(****重点****)**  ##

### 1.线程安全的概念 ###

>  **如果多线程环境下代码运行的结果是符合我们预期的，即在单线程环境应该的结果，则说这个程序是线** **程安全的。**

### 2.线程不安全的原因 ###

运行下面代码：

static class Counter {
        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);
    }

结果：

![2e0f896e7f644af683070471f7e596da.png][]

> 运行结果会发现并不是我们想要的100000 ，而是其他结果，并且运行三次的结果都不一样，这个时候就是线程不安全。其不安全的原因，我们在介绍线程不安全的几个原因后解答。

#### 1）线程抢占式执行 ####

> 线程的抢占式执行是导致线程不安全的万恶之源，抢占式导致了线程调度的随机性，因为这个随机性对于非原子性（后面提到）的指令或者代码带来了千奇百怪的运行顺序
> 
> 这也是为了效率而带来的代价。在线程中，安全和效率是二者不可兼得的，必须得做出对一边的牺牲。

#### 2）线程修改共享数据&&非原子操作 ####

>  上面的线程不安全的代码中,  涉及到多个线程针对  counter.count  变量进行修改 . 此时这个counter.count  是一个多个线程都能访问到的  " 共享数据 "  
> counter.count 这个变量就是在堆上.  因此可以被多个线程共享访问 .

![ca5581d2779349d9b1e4161bd340dc2d.png][]

> 原子性，就是不可再分，这里的不可再分是指代码不可再分或者是指令不可再分。**一条** **java** **语句不一定是原子的，也不一定只是一条指令。**

举个非原子性的例子：

> 这个代码的操作是i++，这个i++虽然是一条语句，但是包含了三条指令
> 
> 1.  将数据从内存读到CPU寄存器
> 2.  在CPU将数据进行更新
> 3.  将数据更新写到内存

对此，我们可以得出在线程的随机调度情况下，如果同一个进程中两个线程并行执行，并且他们都对同一块数据进行++修改操作，这个时候由于++的非原子性，导致了指令的执行顺序有各种奇奇怪怪的运行顺序，如下：

![1e5a690754e449a2844721faeeb87317.png][]

![349f3224f29b41c399c8907e39d79806.png][]

这么多种顺序下，只有前面两种是正确的（这两种都是三条指令执行完才刚刚好到另外三条指令），其他都会出现错误。我们演示一下，后面其中一组带来的错误运行

![605161f1958e442f9b8a7ecde06f1074.png][]

其它错误情况也就是以此类推。

**补充说明：**

> 如果多个线程对数据进行读操作或者对不同变量进行修改，都是完全ok的，并不会出现不安全事件

> 最后解答上面代码出现问题的原因，两个线程理论上，counter的计数应该为10w，但是由于出现了上面提到的线程在并行修改内存时，两个线程的非原子指令在同一条时间线上，按错误顺序执行从而导致出现1+1=1的错误问题，使得程序的结果不是理想结果，但是这个结果一定在5w~10w之间

#### 3）内存可见性 ####

>  可见性指, 一个线程对共享变量值的修改，能够及时地被其他线程看到。内存可见性也会带来线程不安全

> 例如：线程1和线程2都会使用到同一个数据，其中线程1是在进行对数据的反复读和判断，而线程2是对数据的进行修改
> 
>  理想情况下，当线程2修改时，线程1将会马上反应过来，并读到最新的消息。但是事实上可能会出现一些“意外”，就是java编译器（javac）可能会对代码进行优化，也可能是JVM（java）和操作系统对代码做出来的优化处理。
> 
> 在这个例子中，被优化的数据将不会再从内存中读，而是到CPU寄存器为中读取数据，这就很可能使内存中的数据被修改后，线程1无法察觉到！！！
> 
> 为什么代码会被这么优化呢？？？主要原因在于CPU跑到CPU中读数据比到内存中读数据快上3~4个数量级，总是跑到内存读，时间又长，说不定还是一样的数据，浪费了宝贵的时间，此时java编译器就会将代码优化，使其跑CPU寄存器读内存，从而使效率跟高。但是前面也提到过的，效率和安全二者不可兼得，所以难免会碰上不安全问题。然后就出问题了，效率是提高了，但是从此以往，线程1将不会再前往内存读取数据，即使线程2将内存的值修改了，线程1也不会知道

#### 4）代码重序性 ####

> **什么是代码重排序** 
> 
> 一段代码是这样的： 
> 
> 1.  去前台取下 U 盘 
> 2.  去教室写 10 分钟作业 
> 3.  去前台取下快递 
> 
> 如果是在单线程情况下， JVM 、 CPU 指令集会对其进行优化，比如，按  1->3->2 的方式执行，也是没问题，可以少跑一次前台。这种叫做指令重排序

>  编译器对于指令重排序的前提是 " 保持逻辑不发生变化 ".  这一点在单线程环境下比较容易判断 ,  但是在多线程环境下就没那么容易了,  多线程的代码执行复杂程度更高 ,  编译器很难在编译阶段对代码的执行效果进行预测,  因此激进的重排序很容易导致优化后的逻辑和之前不等价

举一个简单的例子：

![92ab637d76d9432ca83c28b0ca0cb41e.png][]

[Java]: https://blog.csdn.net/weixin_59216829/article/details/126577304
[Java 1]: https://blog.csdn.net/weixin_59216829/article/details/126640726
[2e0f896e7f644af683070471f7e596da.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/6079a3c2d0674041b58883d515f90e97.png
[ca5581d2779349d9b1e4161bd340dc2d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/430ab0c2d29349bcb0e3d0a63a8806c4.png
[1e5a690754e449a2844721faeeb87317.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/0216adede2894543ab2eba53a7e83274.png
[349f3224f29b41c399c8907e39d79806.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/eaeb3e7fc201477ea8231df92daaf952.png
[605161f1958e442f9b8a7ecde06f1074.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/a0397674d427495398bb81cbe878d494.png
[92ab637d76d9432ca83c28b0ca0cb41e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/455e89aa49a645968797152bf0e268f9.png