多线程带来的的风险-线程安全

我不是女神ヾ 2024-05-06 21:19 150阅读 0赞

![v2-7bdded212ba4d459fb4fe10bcaa0021d\_b][v2-7bdded212ba4d459fb4fe10bcaa0021d_b]

## 多线程带来的的风险-线程安全 ##

~~ 多线程编程中,最难的地方,也是一个最重要的地方，还是一个最容易出错的地方,更是一个面试中特别爱考的地方.❤️❤️❤️

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

万恶之源,罪魁祸首是多线程的抢占式执行,带来的随机性.~~???  
如果没有多线程,此时程序代码执行顺序就是固定的,代码顺序固定,程序的结果就是固定的.  
如果有了多线程,此时在抢占式执行下,代码执行的顺序,会出现更多的变数!!!  
代码执行顺序的可能性就从一种情况变成无数种情况!!!  
所以就需要保证这无数种线程调度顺序的情况下,执行的结果都是正确的!!!只要是有一种情况下,代码结果不正确,就视为线程不安全!!!

**问题来了:能否消除这样的随机性了????**  
调度的源头来自于操作系统的内核实现.  
1.作为程序猿的我们改不了.???  
2.即使改了自己的操作系统,也无法推广开来,因为全世界大多数操作系统都是这样的,已成定局!???

### 观察线程不安全(代码)??? ###

class Counter{
        
        public int count = 0;
        public void add(){
        
            count++;
        }
    }
    public class ThreadDemo13 {
        
        public static void main(String[] args) {
        
            Counter counter = new Counter();
    
            // 创建两个线程, 两个线程 counter 来调用 5W 次的add方法
            Thread t1 = new Thread(()->{
        
                for (int i = 0; i < 5_0000; i++) {
        
                    counter.add();
                }
            });
            Thread t2 = new Thread(()->{
        
                for (int i = 0; i < 5_0000; i++) {
        
                    counter.add();
                }
            });
            // 启动线程
            t1.start();
            t2.start();
    
            // 等待两个线程结束
            try {
        
                t1.join();
                t2.join();
            } catch (InterruptedException e) {
        
                throw new RuntimeException(e);
            }
    
            // 打印最终的 count 值 预期结果: count = 10W
            System.out.println("count = "+ counter.count);
        }
    }

#### 运行结果: ####

![image-20230923031309538][]  
我们的需求是两个线程各自自增 5w次,一共自增 10w次,  
预期结果是 10w,实际结果不是 10w而且每次都不一样.  
程序出现了bug(程序不符合需求,就是bug).  
注:这个就是典型的线程安全问题!!!???

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

~~ 为什么程序就出现了这个情况????

#### **线程与指令之间的关系:** ####

一个线程要执行,就需要先编译成很多的CPU指令,写的任何一个代码都是要编译成很多的CPU指令的!!!  
个人理解:一个线程是来完成一个任务,要做一些工作,而这个工作是可以分解成一个一个的小步骤的,每个小步骤就是一个指令.  
由于线程的抢占式执行,导致当前执行到任意一个指令的时候,线程都有可能被调度走,然后CPU让别的线程来执行.

> **寄存器,CPU里重要的组成部分,寄存器也能存数据,空间更小,访问速度更快,CPU进行的运算都是针对寄存器(准确的说,是通用寄存器,如EAX,EBX,ECX)中的数据进行的**

`count++;`  
\++ 操作本质上要分成三步  
1.先把内存中的值,读取到CPU的寄存器中 ~~load  
2.把CPU寄存器里的数值进行 +1运算 ~~add  
3.把得到的结果写回到内存中 ~~ save  
注:load,add,save就是CPU上执行的三个指令(被视为机器语言).

两个线程并发的执行count++,此时就相当于两组load,add,save进行执行,此时不同的线程调度顺序就可能会产生一些结果上的差异.

#### 作图来理解多线程的调度:❤️❤️❤️ ####

![image-20230923125739880][]

#### **分析执行过程:** ####

![image-20230923133152779][]

#### 思考一下???: ####

出现bug 之后,得到的结果一定是 <= 10w, 结果是一定 >= 5w 嘛?  
极端情况下,所有的执行都是交错执行,是否就是 5w 呢??  
实际上,结果是可以小于 5w ,只是概率更低了!!  
![image-20230923133717932][]

根结底线程安全问题全是因为==线程的无序调度(罪魁祸首,万恶之源)==导致了执行顺序不确定结果就变化了!!!

#### 总结(线程不安全的原因)??? ####

1.  \[根本原因\] 抢占式执行,随机调度 ~~ 对此,我们无能为力.
2.  代码结构:
    
     *  **多个线程** 同时 **修改** **同一个变量** ~~ 不安全!!! ???
     *  一个线程,修改一个变量,安全.
     *  多个线程读取同一个变量,安全.
     *  多个线程修改多个不同的变量,安全.
     *  注1: 因此可以通过代码结构来规避这个线程不安全问题,  
        但是因为需求问题,代码结构无法进行调整(这种方法使用频率并不高).
     *  注2: **修改** => 不可变对象是无法修改的,天然就是线程安全的!!!
3.  原子性. 如果修改操作是原子的,出现问题概率小;如果是非原子的,出现问题概率极高(线程不安全问题,其实本质上是事务的脏读问题,之前博主写的博客解释过相关概念,在此不做解释啦!ヾ(❀^ω^)ﾉﾞ
    
     *  原子: 不可拆分的基本单位.
        
        > 上述 count ++ 操作就不是原子,里面可以拆分成三个操作,load,add,save.某个操作,对应单个CPU指令,就是原子的,如果这个操作对应多个CPU指令,大概率就不是原子的.比如直接使用 = 赋值,就是一个原子的操作
4.  内存可见性,引起的线程不安全
    
     *  一个线程读,一个线程改,可能出现读的结果和预期不符合的问题.
5.  指令重排序,引起的线程不安全
    
     *  本质上是编译器优化,优化出bug了.优化:编译器觉得程序猿写的代码太low了,对代码进行调整,在保持代码逻辑不变的情况下,调整代码的执行顺序,从而加快程序的执行效率.

### 线程不安全问题的解决 ###

\*\*如何解决线程不安全问题?\*\*????  
最主要的手段就是从这个原子性下手,通过加锁不能把非原子的操作变成原子的.  
即解决前面代码的线程不安全问题,就是通过加锁让count++变成原子的.  
`synchronized public void add(){ count++; }`

加了 synchronized 之后,进入方法就会加锁,出了方法就会解锁.  
如果两个线程同时尝试加锁,此时一个能获取锁成功,另一个只能阻塞等待(处于BLOCKED状态),一直阻塞到刚才的状态解锁(释放锁),当前线程才能加锁成功!!! => 操作系统的基本设定,系统里的锁“不可剥夺”特性,一旦一个线程获取到锁,除非它主动释放,否则无法强占.

加锁,说是保证原子性,不是让load,add,save三个操作一次完成,也不是就是让其它也想操作的线程阻塞等待了  
![image-20230923205141702][]

![image-20230923203926850][]

虽然加锁之后,算得慢了,但是还是比单线程要快,加锁只是针对count++加锁了,除了count++之外,还有for循环的代码,for循环代码是可以并发执行的(线程t1和线程t2各自修改各自for循环的局部变量i,是没问题的),只是count++串行执行了.  
一个任务中,一部分可以并发,一部分串行,仍然是比所有代码串行要快的.

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

> **加锁,是要明确执行对哪个对象加锁的.如果两个线程针对同一个对象加锁,会产生阻塞等待(锁竞争/锁冲突),如果两个线程针对不同对象加锁,不会阻塞等待(不会锁冲突/锁竞争).**

#### **synchronized的使用方法**???? ####

1.  修饰方法
    
     *  修饰普通方法 ~~ 把锁加到this对象上
        
         *  进入方法就加锁,离开方法就解锁
     *  修饰静态方法 ~~ 把锁加到类对象上
        
         *  通理也是这样,进入方法就加锁,离开方法就解锁
     *  但是这两种修饰方法,加锁的“对象”不同,修饰普通方法,锁对象就是this,修饰静态方法,锁对象就是类对象.  
        ![image-20230924235103704][]
2.  修饰代码块
    
     *  显示/手动指定锁对象
3.  锁对象
    
    1.  明确锁对象,针对那个对象加锁
    2.  两个线程,针对同一个对象加锁,会发生锁冲突/锁竞争(产生阻塞等待)
        
         *  一个线程获取到锁(先到先得),另一个线程就得塞等待,等待到上一个线程解锁,它才能获取锁成功.
    3.  两个线程,针对不同的对象加锁,不会有任何锁冲突
        
         *  这两个线程都能获取到各自的锁,此时不会有阻塞等待了.

*  两个线程,一个线程加锁,一个线程不加锁,这个时候就不存在锁竞争了.  
    ![image-20230925000413172][]注: 这种写法和没加锁的运行结果一样.

[v2-7bdded212ba4d459fb4fe10bcaa0021d_b]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/2c43476194004cd0a6660c831eb48cca.jpeg
[image-20230923031309538]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/deaee6eeb72a4ad7b186afb0969ecfd1.png
[image-20230923125739880]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/8099b3107ac843b7961737296046d853.png
[image-20230923133152779]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/68424c8ca73b46ae8b201c3aee6b0bb1.png
[image-20230923133717932]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/026a201ad7d94de8a413f5c13207cb09.png
[image-20230923205141702]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/42c9954be1ec4ce08f49b1051a2c3fd9.png
[image-20230923203926850]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/915b497241e2495cac46b020e7b2b4ad.png
[image-20230924235103704]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/c2768337cbfa4e1bb0dadd350881345e.png
[image-20230925000413172]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/7f0e623bec7e4aa69c78b7878233e00d.png