多线程编程4——线程安全问题

一、线程之间是并发执行的，是抢占式随机调度的。

多个线程之间是并发执行的，是随机调度的。我们只能确保同一个线程中代码是按顺序从上到下执行的，无法知道不同线程中的代码谁先执行谁后执行。

比如下面这两个代码：

代码一：

这俩红框框打印的顺序是随机的。

主线程调用start，创建一个线程，是主线程先接着往下执行代码，还是线程先执行run中的代码，这是随机的，看哪行代码先在CPU上调度，就先执行哪行代码。

代码二：

运行结果：

主线程先sleep休眠1秒，这时线程趁着主线程休眠，打印thread，然后也进入sleep休眠1秒

主线程和线程谁会先从sleep中醒过来是不确定的。醒来后会回到就绪队列，等待CPU调度。CPU调度是随机的，谁先被调度谁先执行下一行代码。也就是说，控制台输出的结果，是hello在前，还是thread在前，是不确定的。完全看调度器的调度结果。哪行代码先被调度执行先输出哪个结果。

观察运行结果我们发现，有时是thread hello，有时是 hello thread，谁先打印很随机，不可预期。

二、一段出现线程安全问题的代码

什么样的代码会产生线程安全问题呢？

我们来看一下。

创建两个线程，分别对同一个对象（new Counter()）的属性(count)进行5w次的自增，打印这个属性的值。我们的预期结果是：属性的值是10_0000

代码如下：

运行结果如下：

我们发现，

结果很随机，每次都不同，但不是10_0000，说明代码出现了bug，出现了线程安全问题。

这段代码为什么会出现线程安全问题呢？

问题就出现在 count++ 这个代码上。

一个线程具体要执行，需要先编译成很多的CPU指令。可以这样理解，一个线程是完成某个任务，这个任务可以拆分成一个一个的小步骤，每个小步骤就是一个指令。CPU调度时只认得指令，它不认识count++这个操作。（指令：可以视为机器语言，由0和1组成。 load，add，save这些相当于汇编指令，比机器指令好记，和机器指令是一一对应的，通过编译器可以将汇编指令转换成机器指令。不同的CPU会支持不同的机器指令，load，add，save这三个操作是CPU中已经支持的指令）

count++操作本质上要分成3步：

1、先把内存中的值，读取到CPU的寄存器中（load）

2、把CPU寄存器里的数值进行 +1 运算（add）

3、把得到的结果写回内存中（save）

load，add，save这三个操作，就是CPU上执行的3条指令。

就拿我们写的其中的一部分代码举例，

上面这个代码要执行就需要编译成很多CPU指令：

本质上是 cmp指令

方法调用，是 call指令

load、add、save这三条指令

针对 i 的load、add、save这三条指令

那为什么说count++操作本质上要分成三条指令，就导致了线程安全问题呢？

我们已经知道，count++最终落实到CPU上执行，会分成这三个指令来去执行（load、add、save），那么，如果是两个线程并发的执行count++，此时就相当于两组 load add save 进行执行。由于线程的抢占式执行，导致当前执行到任意一个指令的时候，线程都有可能被调度走，CPU让别的线程来执行，正是这样的切换，导致会出现不同的线程调度顺序，出现线程安全问题。（哪个线程中的count++先执行是随机的。调度一次执行到了这个count++哪个指令也是随机的。）

调度顺序会出现无数种可能性，下面列出几种：

（1）load、add、save 是一起的，都执行完才被调度走

（2）执行到任意一个指令，线程都有可能被调度走，CPU去执行别的线程，过一会又回来接着执行这个线程了

（3）左：两个CPU某一时刻同时调度到了两个线程的相同指令；右：一个线程才执行完load，另一个线程已经执行好几轮load、add、save操作了

这些不同的调度顺序，产生了不同的结果。

比如说，，如果是这个顺序，我们来分析一下是怎么执行的。

为了方便画图，我们假设线程t1 只会被左边那个CPU调度，线程t2 只会被右边那个CPU调度（真正在你的电脑上跑这串代码，肯定是可以被你电脑上任意CPU调度的。）

第一步：load —— 把内存中的值加载到CPU的寄存器中（CPU里有个重要的组成部分，寄存器。CPU里进行的运算都是针对寄存器里的数据进行的，也就是说，CPU不能直接操作内存）

于是，第一个CPU寄存器中存了个 0

第二步：add —— CPU寄存器里的数值进行+1运算

于是，第一个CPU寄存器里的值变为1

第三步：save —— 得到的结果写回内存中

于是，内存中的值变为1

第四步：load —— 把内存中的值加载到CPU的寄存器中

于是，第二个CPU寄存器中存了个1

第五步：add —— CPU寄存器里的数值进行+1运算

于是，第二个CPU寄存器里的值变为2

第六步：save —— 得到的结果写回内存中

于是，内存中的值变为2

count自增2次，结果为2，符合预期。

我们再来看另一种可能的调度顺序，，如果是这个顺序，我们来分析一下是怎么执行的。

第一步：load —— 把内存中的值加载到CPU的寄存器中

于是，第二个CPU寄存器中存了个0

第二步：load —— 把内存中的值加载到CPU的寄存器中

于是，第一个CPU寄存器中也存了个 0

第三步：add —— CPU寄存器里的数值进行+1运算

于是，第二个CPU寄存器里的值变为1

第四步：save —— 得到的结果写回内存中

于是，内存中的值变为1

第五步：add —— CPU寄存器里的数值进行+1运算

于是，第一个CPU寄存器里的值变为1

第六步：save —— 得到的结果写回内存中

于是，内存中的值变为1

count自增2次，结果为1，不符合预期。 线程t1 load的值，是线程t2修改之前的值，t1 读到了 t2 还没save 的数据。于是出现问题。

也就是说，只要其中一个线程读到了另一个线程还没save 的数据，结果就会出问题。

这么多种调度顺序，，只有这两种情况是满足不会读到还没save 的数据的。所以，只有两个线程每次的调度顺序都是这两种，才会打印10_0000。这种概率非常非常小。输出结果基本上都是小于10_0000。

那么结果一定会大于5_0000吗？

不一定。也有可能出现，一个线程才执行完load，另一个线程已经执行好几轮load、add、save操作了 这种情况。这就是，count自增好几次，结果为1了。

所以，这段代码一定会出现线程安全问题，且结果很随机。

三、出现线程安全问题的原因

为什么会产生线程安全问题呢？

1、根本原因：操作系统是抢占式执行，随机调度的。

2、代码结构：多个线程同时修改同一个变量。（上述代码中，两个线程修改同一个变量count。出现线程安全问题的概率非常大。）

一个线程，修改一个变量，没事
多个线程，同时读取同一个变量，没事
多个线程，同时修改不同的变量，也没事

3、原子性：修改操作不是原子性的。如果修改的操作是原子的，出现线程安全问题的概率比较小。如果是非原子的，出现线程安全问题的概率就非常大了。（原子：不可拆分的基本单位。单个指令就是原子的。上述代码中，count++可以拆分成load、add、save这三个指令，所以count++不是原子的，出现线程安全问题的概率非常大。）

4、内存可见性问题：如果是一个线程读取，一个线程修改，也可能出现线程安全问题，读取的结果不符合预期。

5、指令重排序：编译器对你写的代码进行优化，保证逻辑不变的情况下，进行调整，来加快程序的执行效率。调整时，可能会调整代码的执行顺序，从而可能会出现线程安全问题。

上述是5个典型的线程安全问题的原因，但并不是全部。

一个代码究竟线程安全不安全，要具体问题具体分析。如果一个代码踩中了上面的原因，也可能线程安全。如果一个代码没踩中上面的原因，也可能线程不安全。

要结合原因，结合需求，具体问题具体分析。多线程运行代码，只要不出bug，就是线程安全的。

四、如何解决线程安全问题？

根据出现线程安全问题的原因，从中入手解决线程安全问题。

我们可以通过调节代码结构来规避线程安全问题。

但是代码结构也是来源于需求的，不一定就能调整。是方案没错，但普适性不是特别强。

最主要的解决线程安全问题的方法就是从原子性入手。把非原子的操作变成 “原子” 的。

就比如上面那段出现线程安全问题的代码，

正是因为 count++操作不是原子的，本质上要分成load、add、save这三条指令，当两个线程并发的执行count++时，就相当于两组 load add save 进行执行。由于线程的抢占式执行，导致当前执行到任意一个指令的时候，线程都有可能被调度走，CPU让别的线程来执行，正是这样的切换，导致会出现不同的线程调度顺序，后一个线程 读到了还没save 的数据，出现线程安全问题。

我们从原子性入手，就非常好解决了。只要把count++这个非原子操作，变成 “原子” 的，保证线程的load、add、save 3个操作都执行完才会被调度走，让后一个线程读到的是 save过的数据，问题就解决了。

如何把非原子的操作变成 “原子” 的呢？

通过 synchronized关键字加锁。

synchronized

synchronized 是一个关键字，表示加锁。要明确锁对象，是对对象进行加锁！！！

synchronized 的使用方法：

1、修饰方法：（1）修饰普通方法（2）修饰静态方法

2、修饰代码块

虽然 synchronized 修饰方法和代码块，但锁不是加到方法或其他上面，是线程对对象加锁，加锁是给对象加锁，一定要明确锁对象是哪个！！！

修饰普通方法：锁对象是this

修饰静态方法：锁对象是类对象（Counter.class）

修饰代码块：手动指定锁对象

加锁的规则：（就3条，很简单，不要自己加戏）

1、如果两个线程针对同一个对象加锁，会出现锁冲突/锁竞争，一个线程能够获取到锁（先到先得），另一个线程只能阻塞等待（BLOCKED），一直阻塞到上一个线程释放锁（解锁），它才能获取锁（加锁）成功。【注：另一个线程对这个对象加锁不成功，线程阻塞。但不代表这个锁对象不能用，还是可以获取锁对象的属性，调用锁对象的没加锁的方法的。只能说线程阻塞了，不能说对象不能用了。这两个概念不一样。】

2、如果两个线程针对不同的对象加锁，不会出现锁冲突/锁竞争。这俩线程都能获取到各自的锁，不会有阻塞等待了。

3、如果两个线程，一个线程加锁，一个线程不加锁，也不会出现锁冲突/锁竞争。

对 synchronized 的使用方法进行分别介绍

1、修饰普通方法

进入方法就加锁，出了方法就解锁。锁对象是this，谁调用这个方法谁就是this

比如通过 synchronized关键字修饰 add方法，进入add方法就加锁，出了add方法就解锁。以此来把方法中count++变成 “原子的” 。

synchronized关键字可以放在public前，也可以放在public后，下面两种都可以。

加了 synchronized关键字后，我们再来看一下这个调度顺序，，会不会发生改变呢？

肯定会的。

如上，

（1）首先，加了 synchronized关键字后，load前面和save后面会多个lock(加锁) 和 unlock(解锁)操作。

（2）线程t2 进入add方法，对counter 进行加锁（counter调用add方法，counter就是this，就是锁对象），接着往下执行load，此时 t1也想去加锁，不好意思，加锁不能成功，只能阻塞等待。

（3）一直等到 t2 unlock 之后，t1才可能lock成功。

t1 加锁的阻塞等待，就把 t1的load 推迟到 t2的save之后，t1读到的就是t2 save过的数据。这就避免了线程安全问题，输出的结果就是符合预期的 10_0000啦。