☕导航小助手☕

    🍚写在前面

         🧇一、内存可见性

         🧀二、内存可见性的解决办法 —— 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线程 的工作：

1. load 读取内存的数据到 CPU 的寄存器
2. 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~

---

注意：

1. volatile关键字 保证的是 内存可见性 的问题，它不保证原子性的问题~
2. volatile 解决的是 一个线程读、一个线程写 的问题~
3. 当然，volatile 也可以解决指令重排序的问题~
4. 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() 内部的执行过程：

1. 释放锁
2. 等待通知
3. 当通知到达后，就会被唤醒，并且尝试重新获取锁

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） / 再继续参与竞争锁~ 

---

注意：

1. notify 在调用的时候，会尝试唤醒进行通知，如果当前对象没有在其他线程里 wait，则不会有副作用~
2. 如果 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~

关于线程安全问题的博客就暂时介绍到这里了~

如果感觉这一篇博客对你有帮助的话，可以一键三连走一波，非常非常感谢啦 ~

​​​​​​​