目录
前言
1、线程安全的概念
2、线程不安全的原因
3、产生抢占式执行与原子性问题
4、产生多个线程修改同一个变量的问题
5、解决上述三个导致线程不安全的问题
5.1、锁 synchronized关键字
5.1.1、使用synchronized关键字进行加锁
6、由内存可见性引起的线程不安全问题
7、解决内存可见性产生的线程不安全问题
7.1、使用volatile关键字暂停优化（volatile保证内存的可见性）
8、由指令重排序引起的线程不安全问题
9、解决由指令重排序引起的线程不安全问题
前言
在说线程安全之前，先来了解一下静态方法和类对象这两个概念，静态方法是属于类的方法与对象没有关系。类对象（例如：TestDemo.class）我们写的.Java源代码文件通过javac编译成为.class二进制字节码文件。JVM就可以执行.class文件了，JVM想要执行这个.class文件就得先把文件内容读取到内存中，这个操作叫做类加载，类对象，就可以表示这个.class文件的内容，类对象描述了类的方方面面的详细信息，包括不限于：1、类的名字，2、类的属性，属性的名字、类型、权限，3、类有那些方法，方法的名字，参数，类型，权限，4、类继承自那个类，5、类实现了那些接口。此处类对象，就相当于"对象的图纸"，有了这个图纸，才能了解这个对象是啥样的，进一步的才可以使用反射api来获取这里的一些信息。
1、线程安全的概念
如果在多线程环境下代码运行的结果是符合我们的预期的，即在单线程环境先执行的结果，在多线程环境下执行的结果是不相同的。原因在于多线程的调度是无序的/随机的.所以导致单线程中执行的代码在多线程中执行的结果不同。这种情况就是线程不安全的代码。
本质原因：线程在系统中的调度是无序的/随机的（抢占式执行）
我们通过这个代码来了解一下,写一个count变量来计算，现在创建两个线程，都对这个count变量进行自增，我们的预期结果是通过两次自增，count的结果最终变为10w次，来观察一下实际结果与预期结果。
//线程不安全
class Counter{
private int count = 0;
public void add(){
count++;
}
public int getCount(){
return count;
}
}
public class ThreadDemo13 {
public static void main(String[] args) throws InterruptedException {
Counter counter = new Counter();
//搞两个线程，两个线程分别对这个counter自增5w次
Thread t1 = new Thread(()->{
for (int i = 0; i < 50000; i++) {
counter.add();
}
});
Thread t2 = new Thread(()->{
for (int i = 0; i < 50000; i++) {
counter.add();
}
});
t1.start();
t2.start();
//等待两个线程执行结束，然后看结果
t1.join();
t2.join();
System.out.println(counter.getCount());
}
}
可以看见代码的执行结果多次执行之后每次的结果都不一样，像是一个随机值，但是都没有达到我们的预期结果10w ，产生实际结果与预期结果不相符就是bug，就是由多线程调度的不确定性（抢占式执行）造成的线程不安全问题。
2、线程不安全的原因
线程不安全的原因
- 抢占式执行（罪魁祸首）
- 多个线程修改同一个变量
- 修改操作，不是原子的（原子：不可分割的最小单位）
- 内存可见性，引起的线程不安全
- 执行重排序，引起的线程不安全
上述产生线程不去安全的原因可以总结为三点：
1、原子性
- 多条指令，这些指令之间存在先后依赖关系，在这多条指令执行期间，不能插入其他指令。
2、可见性
- 系统调用CPU执行线程，一个线程对共享变量的修改，另一个线程能够立刻看见。
3、有序性
- 程序执行的顺序按照代码的先后顺序执行（处理器可能会对指令进行重排序）
我们通过上述代码来分析产生前三种线程不安全的原因。
3、产生抢占式执行与原子性问题
我们将add方法的方法体中的count++操作进行仔细分析，本质上是三个cpu指令构成的。
- load：把内存中的数据读取到cpu寄存器中。（count是一个变量，保存在内存中，想要修改count的值，首先要将内存中的值，读取到寄存器中）。
- add：就是把寄存器中的值，进行+1运算。
- save：把寄存器中的值写回到内存中。
我们挑选其中的几种分析他们的执行过程。两个线程可以在一个CPU核心上分时复用（并发）进行执行，也可以在两个CPU核心上执行，我们为了方便理解，画图就使用两个CPU核心执行这两个线程。
1️⃣第一种情况，t1线程执行完毕之后执行t2线程
此时看到，两个线程，各自自增一次，最终结果是2，此时是没有bug的，结果正确。
2️⃣第二种情况：t1线程和t2线程并发式执行。
此时我们按照上述执行过程，两个线程自增两次，最后结果是1，说明出现了bug,其中一次自增的结果，被另一次给覆盖了（无效自增）。
上述的多种情况按照这样的方式执行完成之后，只有两种没有出现bug，其余的都会出现bug.
4、产生多个线程修改同一个变量的问题
上述的第二个情况的说明，两个线程并发式执行，两个线程修改同一个变量，再一个线程没有将数据修改完成之前，有一个线程将内存中的数据读取进行修改，最后两个线程将数据都返回给内存。这个时候就产生了bug.
在上述代码的背景下，这些操作的安全性。
5、解决上述三个导致线程不安全的问题
如何解决线程不安全问题，还是需要从问题产生的原因入手，抢占式执行的问题我们是没有办法修改的，多个线程修改同一变量，在有些情况下是可以安全执行的，具体要看我们的代码如何编写，最后来看原子性问题，将上述代码中的count++操作变成原子的（不可分割的最小单位）。
上述的抢占式执行的问题，我们无法解决，多个线程修改同一个变量的问题在某些情况下，可以安全执行，所以我们只能从原子性原因入手，解决线程不安全的问题。
我们可以通过加锁，将count++操作变成原子的。
5.1、锁 synchronized关键字
💥锁的作用：能够起到保证"原子性"的效果。
❗❗❗锁的两个核心操作：先以一个生活中的例子来了解加锁和解锁。
- 加锁：相当于你进入一个房间之后，将门锁了起来，别人就不能进入这个房间，想要进入只能等待。
- 解锁：只有我们在将锁释放，打开门之后，其他人才能进入这个房间之中。
就代码而言，一旦某个线程加锁了之后，其他线程也想加锁，就不能直接加上，就需要阻塞等待，一直等到拿到锁的线程释放了锁为止。我们可以将上述例子中的人比作线程，当先拿到锁的人，将锁打开（释放）之后，其他人才能获得锁。也就是上面的进入房间。
我们的线程调度是抢占式执行的，所以当第一个线程将锁释放了之后，等待加锁的线程，谁先拿到锁，加锁成功，这是不确定的。
5.1.1、使用synchronized关键字进行加锁
1️⃣第一种写法，使用代码块
我们上述说到锁有两个核心操作，加锁和解锁，此处使用代码块的方式来表示，进入synchronized修饰的代码块的时候，就会触发加锁，出了synchronized代码块，就会触发解锁。这里的{}就相当于我们上述所说的房间，线程进入这个房间，其他线程想进入这个代码块，就需要当前线程，将代码块中的程序执行完成。
📕锁对象：表示的是针对那个对象加锁。
❗❗❗注意：（）里面的锁对象可以写作任意一个Object对象（内置类型不行，但是类类型是可以的）
如果两个线程针对一个对象（counter）加锁，此时就会出现"锁竞争"（一个线程先拿到了锁，另一个线程阻塞等待） ；如果两个线程，针对不同对象（counter、counter2、counter3）加锁，此时不会出现锁竞争，各自索取各自的锁。
2️⃣ 第二种写法，直接给方法加锁
❗❗❗ 注意：
如果直接给方法使用synchronized修饰普通方法此时就相当于以this为锁对象。
如果synchronized修饰静态方法（static），此时就不是给this加锁了，而是针对类对象加锁
当然我们更常见的还是手动指定锁对象。
在上述代码中，t1和t2线程是在竞争同一个锁对象，此时就会产生锁竞争（t1拿到锁，t2就得阻塞）。此时就可以保证++操作就是原子的，不受影响了。对上述代码中的两个线程执行过程进行画图理解。
❓❓❓说到这里很多同学会想到这个加锁操作和等待一个线程的效果一样（join），为什么不直接使用join呢？
❗❗❗其实这个说法是错误的，join是让两个线程完整的进行串行；加锁，是让线程的某个小部分串性了，大部分都是并发的。
例如上述线程t1和t2，这两个线程中大概的一些操做是
- 创建i
- 判定i<5000
- 调用add
- count++
- add返回
- i++
- ......
线程t1和t2在前三步的时候，会是并发执行，但是执行到第四步的时候，因为所对象是同一个counter，所以会发生阻塞。当一个线程将4执行完成之后，另一个线程就会执行4，两个线程将4执行完成之后，第5，6..步又会以并发的方式执行。
❗❗❗ 总结：加锁可能导致阻塞，代码阻塞，对于程序的效率肯定还是会有影响的，此处虽然加了锁，比不加锁慢一点，但是不加锁算的更准一点，比彻底串行化要快一点。
📗锁对象的作用：只是为了标识是否针对同一个对象加锁。如果锁对象不同，那么就不会存在锁竞争了，加不加锁就没有意义了。我们使用锁，就是为了保证某一段代码的原子性，保证线程的安全性，保证多线程执行不出现问题，我们就得引入锁竞争，要产生锁竞争就需要对同一个对象加锁。
6、由内存可见性引起的线程不安全问题
我们通过下面的代码来了解内存可见性的问题。
❗❗❗预期效果：
t1通过flag == 0作为循环条件，初始情况下，将进入循环。t2通过控制台输入一个整数，一旦用户输入了一个非0的值，此时t1的循环就会立即结束。从而t1线程退出！
❗❗❗实际效果：
输入非0的值之后，t1线程并没有退出，循环没有结束，可以通过jconsole可以看到t1线程任然在执行，处在Runnable（运行）的状态。
实际效果不等于预期效果，我们这个代码产生了bug.
import java.util.Scanner;
public class ThreadDemo14 {
public 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(()->{
Scanner scanner = new Scanner(System.in);
System.out.println("请输入一个整数：");
flag = scanner.nextInt();
});
t1.start();
t2.start();
}
}❗❗❗上述代码中出现内存可见性的原因：
两个线程先执行t1线程，while（flag == 0）这个操作存在两个执行指令，一个为load（CPU寄存器从内存中读取数据），另一个为将寄存器中的数据与0进行比较。但是load指令相对于CPU而言时间开销很大，而将寄存器中的数据与0进行比较的操作的开销想读与load很小，而且while循环执行的时间非常短，这样while循环每次执行的时候都要执行这两个指令，且load读取的数据相同。此时编译器认为load操作可以优化掉所以在第一次循环的时候执行一次load，其他次循环的时候load操作直接被省略掉，只进行一个比较的操作（相当于复用之前寄存器中load的值）。
由于t1线程先执行，且循环的速度非常快，t2线程在调度运行的时候，t1线程已经执行了一段时间了这个时候while循环也已经执行了不止一次了，并且t2线程在修改数据的时候，t1线程还在运行过程中，此时while循环已经有很多次了，编译器这个时候认为load读取的数据是相同的，已经将load优化掉了。
但是编译器在将while循环中的load优化掉之后，t2线程中对flag进行了修改，这个时候由于编译器将load指令去掉了，t1线程中的while循环无法得到这个被修改的flag，t1线程中的循环无法结束，t1线程也就无法结束，就会造成我们看到的控制台输入数字，之后没有显示t1线程结束和jconsole中观察到t1线程在运行状态。
上述的bug可以归结为编译器优化产生的bug.
编译器优化：能够智能的调整你的代码执行逻辑，保证程序结果不变的前提下，通过加减语句，通过语句变换，通过一些操作，让整个程序执行的效率大大提升。
编译器对于单线程判定是非常准确的，但是在多线程下就不一定了，可能导致，调整之后效率提高了，但是结果变了（编译器出现了误判）引起bug.
❗❗❗所谓的内存可见性， 就是多线程环境下，编译器对于代码优化，产生了误判，从而引起了bug，进一步导致了代码出现bug.
这里再来了解一个小的知识点
❓❓❓如果针对上述代码我们给while循环中添加一个sleep（1000）效果还会和while循环体中是空的效果一样吗？
❗❗❗答案肯定是不一样的，因为sleep相对于load这个指令来说消耗的时间是非常大的。加了sleep函数之后循环执行的速度就非常慢了，同一时间循环次数下降了，此时load操作 不再是负担了，load就不是主要矛盾了，sleep才是主要矛盾，编译器就没有必要优化load了。
7、解决内存可见性产生的线程不安全问题
此时我们的处理方式，就是让编译器针对这个场景暂停优化。保证t1线程能过立即看见t2线程对flag的修改。
7.1、使用volatile关键字暂停优化（volatile保证内存的可见性）
被volatile修饰的变量，此时编译器就会禁止上述的优化，就能够保证每次循环，flag的值都是从内存中重新读取的数据与0进行比较。
此时t2线程修改flag的值，t1线程就能感知到了，t1线程也就能够结束了。
虽然说将变量用volatile修饰，像上述的while循环中load不被优化掉，这只是让编译器不对代码做优化而已，volatile不保证原子性。
❗❗❗总结：
- volatile使用的场景，是一个线程进行读操作，一个线程进行写操作的情况。
- synchronized则是多个线程进行写的操作的情况。
- volatile的这个效果，称为"保证内存可见性"。
8、由指令重排序引起的线程不安全问题
指令重排序也是编译器优化的策略，调整了代码的执行顺序，让程序更高效。
编译器优化的前提：保证代码逻辑不变，并且调整之后的结果要和之前是一样的。
指令重排序，我们通过生活中的例子来说明，代码不好演示，因为一个代码执行时，不能保证那次代码在执行过程中采用了指令重排序的优化方式。
指令重排序的优化，单线程情况下可以保证调整之前和之后的结果是不变的。但是多线程情况下就不能保证了。我们通过这个伪代码来了解。
Class Student{
public void learn(){
System.out.println("正在学习！");
}
}
public Class Test{
public static void main(String[] args){
Student s ;
Thread t1 = new Thread(()->{
s = new Student();
});
Thread t2 = new Thread(()-> {
if(s != null){
s.learn();
}
});
t1.start();
t2.start();
}
}上述代码中创建Student对象的操作大题的可以分成三步操作
- 申请内存空间。
- 调用构造方法（初始化内存的数据）
- 把对象的引用赋值给s(内存地址的赋值)。
- 如果是单线程环境，此处就可以进行指令重排序1先执行，2和3谁先执行都可以。
- 多线程环境下，假设t1按照1、3、2的顺序执行（最后初始化）。当t1执行完1、3之后，即将执行2的时候，t2线程开始执行，由于t1的3已经执行过了，这个引用已经非空了，（s这个引用现在只是指向了内存中的一块地址）t2开始尝试调用s.learn()，但是由于t1并没有被s所引用的对象进行初始化，此时learn会变成什么样子，就不知道了，很可能产生bug了。
以上就是指令重排序产生线程不安全的问题
9、解决由指令重排序引起的线程不安全问题
1️⃣上述的场景可以通过加锁来解决指令重排序引起的线程不全问题
上述这个例子没有保证创建对象时候的原子性，可以通过对创建对象这个操做进行加锁，给t1和t2线程设置相同的锁对象，让t1和t2产生锁竞争。还是上述的伪代码。
public class Test{
public Object locker = new Object();
public static void main(String[] args){
Student s ;
Thread t1 = new Thread(()->{
synchronized(locker){
s = new Student();
}
});
Thread t2 = new Thread(()-> {
synchronized(locker){
if(s != null){
s.learn();
break;
}
}
});
t1.start();
t2.start();
}
}2️⃣使用volatile对s进行修饰，创建Student对象的时候就会禁止指令重排序。（重点掌握整个方法解决指令重排序问题）
public static void main(String[] args){
volatile Student s ;//创建对象的时候，让代码严格按照上述的1、2、3步骤执行
