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); } }
按照正常逻辑来看这段代码，结果应该是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 关键字
其中 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); } }
通过对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 关键字就可以使上述的优化被强制关闭，可以确保每次循环条件都会重新从内存中读取数据。
强制读取内存，虽然开销大了，效率也低了，但是数据的准确性、逻辑的准确性都提高了。
只需要对 flag 添加一个 volatile 关键字即可解决这一问题。
3.4、总结 volatile 关键字
1、保证内存可见性，每次访问变量必须都要重新读取内存，而不会优化到寄存器/缓存中
2、禁止指令重排序，针对被 volatile 修饰的变量的读写操作相关指令，是不能被重排序的。
