【JavaEE初阶】多线程 _ 基础篇 _ 线程安全问题（下篇）
☕导航小助手☕
写在前面
一、内存可见性
二、内存可见性的解决办法 —— volatile关键字
三、wait 和 notify 关键字
3.1 wait() 方法
3.2 notify() 方法
3.3 notifyAll() 方法
3.4 wait 和 sleep 的对比
写在前面
在上一篇博客中，已经介绍了 线程安全问题的部分内容，我们知道了 线程安全问题 是什么，也知道了线程安全问题出现的五种原因（当然，这五种原因 只是一些典型的情况，并不能说明 线程不安全只是这五种情况造成的），并且还知道 怎样去解决 由于不是原子的操作 而引发的线程安全问题（加锁 是解决 线程的某些修改操作 不是原子性的办法）~
那么，接下来将介绍剩下的内容 ......
一、内存可见性
现在，就来介绍一下 怎样解决 由于内存可见性而引发的 线程安全问题~
内存可见性 所存在的场景 是：一个线程读、一个线程写的场景~
package thread;
import java.util.Scanner;
public class Demo16 {
//写一个 内部类，此时这个内部类 就处在 Demo16 的内部，就可以解决 前面已经写过 Counter 的问题
static class Counter {
public int flg = 0;
}
public static void main(String[] args) {
Counter counter = new Counter();
Thread t1 = new Thread(() -> {
while (counter.flg == 0) {
//执行循环，但是此处循环 啥都不做
}
System.out.println("t1循环结束");
});
t1.start();
Thread t2 = new Thread(() -> {
//让用户输入一个数字，赋值给 flg
Scanner scanner = new Scanner(System.in);
System.out.println("请输入一个整数：");
counter.flg = scanner.nextInt();
});
t2.start();
}
}预期效果：
t2线程 输入一个非零的整数后，此时 t1线程 循环结束，随之进程结束~
运行结果：
这，就是内存可见性的问题~
分析：
t1线程 的工作：
- load 读取内存的数据到 CPU 的寄存器
- test 检测 CPU寄存器的值是否和预期的一样
同时，反复进行，频繁进行~
由于 读内存比读 CPU寄存器 慢上几千倍、上万倍，意味着 t1线程 的主要操作就在 load上，但是 每一次读取到的值又没有啥变化，于是 直接进行了优化，就相当于 只从内存中只读取一次数据，后续就直接从寄存器里面 进行反复 test 就好了~
编译器看到这个线程（t1线程）对变量 flg 也没有做修改，于是就进行了优化操作~
但是，这里出现了一个特殊情况，有其他的线程（t2线程）对这个变量做出了修改~
但是，t1线程 仍然是 采用之前的数据来读寄存器，此时 读到的数据和内存的数据是不一致的，这种情况就叫做 内存可见性问题（即 内存改了，但是线程没有看见；或者说，没有及时读取到内存中的最新数据）~
二、内存可见性的解决办法 —— volatile关键字
由于 编译器优化，是属于编译器自带的功能，正常来说，程序员并不好干预~
但是 因为上述的场景，编译器知道自己可能会出现误判，因此就给程序猿提供了一个 干预优化的途径 —— volatile关键字~
这个关键字是写到要修改的变量上，要保证哪个变量的内存可见性 就往哪个变量里面加~
注意 volatile 可以修饰变量的位置，也是在 public 左右~
此时，运行结果：
volatile 操作 相当于是 显示得禁止了编译器进行上述优化，相当于是给这个对应的变量加上了 "内存屏障"（特殊的二进制指令），JVM 再读取这个变量的时候，因为内存屏障的存在，就知道每次都要重新读取这个变量的内容，而不是草率的进行优化了~
虽然频繁的读取内存，使得速度变慢了，但是数据却是算的对了~
当然，编译器的优化，是根据代码的实际情况来运行的，在一开始的代码中，由于 循环体是空，所以循环的转速极快，导致了 读内存的操作非常频繁，所以就出发了优化~
但是，如果在循环体中加上 sleep，让循环转速一下子就慢了，读取内存的操作 就不是特别频繁了，就不会被触发优化了~
package thread;
import java.util.Scanner;
public class Demo16 {
//写一个 内部类，此时这个内部类 就处在 Demo16 的内部，就可以解决 前面已经写过 Counter 的问题
static class Counter {
public int flg = 0;
}
public static void main(String[] args) {
Counter counter = new Counter();
Thread t1 = new Thread(() -> {
while (counter.flg == 0) {
//执行循环，此处加上 sleep 操作
try {
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
System.out.println("t1循环结束");
});
t1.start();
Thread t2 = new Thread(() -> {
//让用户输入一个数字，赋值给 flg
Scanner scanner = new Scanner(System.in);
System.out.println("请输入一个整数:");
counter.flg = scanner.nextInt();
});
t2.start();
}
}运行结果：
所以说，编译器到底什么时候会优化，仍然是一个 "玄学"问题，它内部有一个完整的优化体系，但是也不关咱们啥事~
由于咱们也不好确定 什么时候优化，什么时候不优化，所以还得要在必要的时候加上 volatile~
注意：
- volatile关键字 保证的是 内存可见性 的问题，它不保证原子性的问题~
- volatile 解决的是 一个线程读、一个线程写 的问题~
- 当然，volatile 也可以解决指令重排序的问题~
- synchronized 保证的是 原子性的问题，解决的是 两个线程写 的问题~
三、wait 和 notify 关键字
前面已经介绍到，线程它是随机调度的，这个随机性很讨厌，我们希望可以控制线程的执行顺序~
我们可以用 join关键字 来控制 线程结束 的顺序了~
但是，我们仍希望 让两个线程按照既定的顺序配合执行~
wait 和 notify 关键字就可以做到这个效果，相比于 jion，它们可以更好的控制线程之间的执行顺序~
wait 叫做 "等待"，调用 wait 的线程，就会进入线程阻塞等待的状态（即 Waiting状态）~
notify 叫做 "通知 / 唤醒"，调用 notify 的线程，就可以把对应的 wait 线程给唤醒（即 从阻塞状态恢复回就绪状态）~
wait 和 notify 都是 Object 的成员方法（随便哪个对象都可以调用）~
比如说：
如果有 o1.wait();
那么 o1.notify()就可以唤醒调用 o1.wait() 的线程，而 o2.notify() 是不能够唤醒调用 o1.wait() 的线程的~
3.1 wait() 方法
wait() 内部的执行过程：
- 释放锁
- 等待通知
- 当通知到达后，就会被唤醒，并且尝试重新获取锁
wait() 一上来就要释放锁，这就说明 在调用 wait 之前，就需要先拿到锁；
换句话说，wait 必须要放到 synchronized 中使用，并且 synchronized 加锁的对象 和 调用 wait 方法的对象 是同一个对象~
此时，使用 object.wait() 之后就会一直等待下去，但是程序肯定不会这么一直等待下去了，所以这个时候就需要一个唤醒的方法 —— notify() ~
3.2 notify() 方法
notify() 内部执行的过程：进行通知~
package thread;
import java.util.Scanner;
//创建两个线程，一个线程调用 wait，一个线程调用 notify
public class Demo18 {
//这个对象用来作为锁对象
public static Object locker = new Object();
public static void main(String[] args) {
Thread waitTask = new Thread(() -> {
synchronized (locker) {
System.out.println("wait 开始");
try {
locker.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("wait 结束");
}
});
waitTask.start();
//创建一个用来 通知/唤醒 的线程
Thread notifyTask = new Thread(() -> {
//让用户来控制，用户输入内容后，再执行通知~
Scanner scanner = new Scanner(System.in);
System.out.println("输入任意内容，开始通知：");
//next 会阻塞，直到用户真正输入内容以后
scanner.next();
synchronized (locker) {
System.out.println("notify 开始");
locker.notify();
System.out.println("notify 结束");
}
});
notifyTask.start();
}
}
运行结果：
当然，wait 和 notify 机制，还能够有效避免 "线程饿死"~
线程饿死：有些情况下，调度器可能分配的不均匀，导致 有些线程反复占用 CPU，有些线程始终捞不着 CPU......
线程 在拿到锁之后，判定当下的任务是否可以进行~
如果 可以进行，那么就干活；如果不可以进行，那么就 wait~
等到合适的时候（条件满足的时候）就再继续执行（notify） / 再继续参与竞争锁~
注意：
- notify 在调用的时候，会尝试唤醒进行通知，如果当前对象没有在其他线程里 wait，则不会有副作用~
- 如果 wait 是一个对象，notify 是另一个对象，则没啥用，无法被唤醒~
3.3 notifyAll() 方法
当然，在 Java 中，还有一个唤醒线程的方法 —— notifyAll() 方法~
当有多个线程等待的时候，notify 是从若干个线程里面随机挑选一个唤醒，是一次唤醒一个；而 notifyAll 则是直接唤醒所有线程，再有这些线程去竞争锁~
举个例子理解 notify 和 notifyAll 的区别：
notify 只是唤醒等待队列中的一个线程，其他的线程还是 需要乖乖的等着，如：
而 notifyAll 则是一下子将这些线程全部唤醒，这些进程则需要重新竞争锁，如：
由于 最终的结果 notifyAll 还是只能进去一个线程，并且 其他的线程还可能出现 "线程饿死" 的情况，所以说 一般的还是 notifyAll 用的比较少~
3.4 wait 和 sleep 的对比
都会让线程进入阻塞~
阻塞的原因和目的不同，进入的状态也不同，被唤醒的条件也不同~
wait 是用来控制线程之间的执行先后顺序，而 sleep 在实际开发中实际很少会用到（等待的时间太固定了，如果有突发情况 想提前唤醒并不是那么容易）~
wait 进入的是 Waiting 状态，sleep 进入的是 Time Waiting 状态~
wait 是主动被唤醒，而 sleep 是时间到了就会自动被唤醒~
wait 其实是涵盖了 sleep 的功能，即可以死等，也可以等待最大时间，所以一般在实际开发中用的多的是 sleep~
关于线程安全问题的博客就暂时介绍到这里了~
如果感觉这一篇博客对你有帮助的话，可以一键三连走一波，非常非常感谢啦 ~
