「JavaEE」线程安全2：内存可见性问题& wait、notify

🎇个人主页 ：Ice_Sugar_7

🎇所属专栏 ：JavaEE

🎇欢迎点赞收藏加关注哦！

内存可见性问题& wait、notify

[🍉Java 标准库的线程安全类](#🍉Java 标准库的线程安全类)
🍉内存可见性问题
- [🍌volatile 关键字](#🍌volatile 关键字)
[🍉wait & notify](#🍉wait & notify)
- [🍌wait 和 join、sleep 的区别](#🍌wait 和 join、sleep 的区别)
🍉小结

🍉Java 标准库的线程安全类

线程安全	线程不安全
Vector（不推荐使用）	ArrayList
HashTable（不推荐使用）	LinkedList
ConcurrentHashMap	HashMap
StringBuffer	TreeMap
String	HashSet
	TreeSet
	StringBuilder

这几个线程安全的类在关键的方法上加了 synchronized

不过也不是说加了 synchronized 就一定是线程安全的，关键还得看具体代码是怎么写的。就比如一个线程加锁，一个不加锁，或者两个线程给不同对象加锁，虽然都有 synchronized，但仍然存在线程安全问题

🍉内存可见性问题

先来看一个代码：

java 复制代码

public class Main {
    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(()-> {
            System.out.println("请输入 flag 的值：");
            Scanner in = new Scanner(System.in);
            flag = in.nextInt();
        });
        t1.start();
        t2.start();
    }
}

程序运行起来后，我们会发现输入一个非 0 的数后等不到 "t1 线程已经结束" 这句话，说明 t1 线程始终在循环里面

这个 bug 和内存可见性问题有关

t1 线程中的 while 循环有两条核心指令：

load 读取内存中 flag 的值到 cpu 寄存器中
拿寄存器的值和 0 进行比较（这涉及到条件跳转指令）

因为循环体是空的，所以循环执行速度会非常快，在 t2 线程执行输入之前，t1 就已经执行了上百亿次循环，而这些循环每次 load 操作的执行结果都是一样的（flag 都为 0）

频繁执行 load 指令会有很大的开销，并且每次 load 的结果都一样，那此时 JVM 就会怀疑这里的 load 操作是否真有存在的必要。所以 JVM 可能优化代码，把上面的 load 给优化掉（就相当于没有 load 这一步了，这种做法比较激进，不过确实可以提高循环的执行速度）

load 被优化之后，就不会再读取内存中 flag 的值了，而是直接使用寄存器之前缓存的值，也就是 flag == 0，所以即使后面我们通过输入改了 flag 的值，但为时已晚

这里就相当于 t2 修改了内存，但是 t1 没看到内存的变化，这就称为内存可见性问题

补充：很多代码会涉及到代码优化，JVM 会智能分析出当前写的代码哪里不太合理，然后在保证原有逻辑不变的前提下调整代码，提高程序效率。不过 "保证逻辑不变"不是一件易事，如果是单线程，那还比较好调整，而如果是多线程，那么很容易出现误判（可以视为 bug）

内存可见性问题高度依赖编译器优化，啥时候会触发这个问题，啥时候不会触发，其实不好说

🍌volatile 关键字

不过我们更希望无论代码怎么写，都不会出现这个问题，所以可以用 volatile 关键字，它可以强制关闭上述的编译器优化，这样就可以确保每次循环都会从内存中读取数据

既然是强制读取内存数据，那么开销势必会变大，效率也会因此降低，不过数据的准确性和逻辑的正确性都提高了

volatile 除了可以保证内存可见性，还可以禁止指令重排序，这个后面再讲

🍉wait & notify

我们知道，多个线程之间是随机调度的，而引入 wait 和 notify 是为了能从应用层面上干预不同线程的执行顺序。
注意这里所说的"干预"不是影响系统的线程调度策略（系统调度线程仍是无序的），而是让后执行的线程主动放弃被调度的机会，这样就能让先执行的线程把对应的代码执行完

考虑这样一个场景：有多个线程在竞争同一把锁，其中线程 t1 拿到了锁，但是它不具备执行逻辑的前提条件，也就是说它拿到锁后没法做啥
t1 释放锁之后还会和其他线程一起竞争锁，它就有可能再次拿到锁。反复获取锁但是啥都没做导致其他线程无法拿到锁，这种情况称为线程饿死（线程饥饿）

这种问题属于概率性事件，并且发生概率还不低，因为 t1 在拿到锁时处于 RUNNABLE 状态，其他线程由于锁冲突而处于 BLOCKED 状态，需要唤醒后才能参与到锁竞争，而 t1 不用，所以 t1 在释放锁之后比较容易再次拿到锁。好在线程饿死不像死锁那样"一旦出现，程序就会挂"，但是也会极大影响其他线程运行。

在这种情况下，它就应该主动放弃争夺锁（主动放弃到 cpu 上调度执行），进入阻塞状态，等到条件具备了再解除阻塞，参与竞争。这个过程简单概括就是"把机会留给有需要的人"

此时就可以使用 wait 和 notify。看 t1 是否满足当前条件，若不满足则 wait，等到有其他线程让条件满足之后，再通过 notify 唤醒 t1

wait 内部会做三件事：

释放锁
进入阻塞等待
当其他线程调用 notify 时，解除阻塞，并重新获取到锁

通过 1、2 这两步，就可以让其他线程有机会拿到锁

接下来说一下如何使用 wait

既然要释放锁，说明要先拿到锁，所以 wait 必须放在 synchronized 中使用。并且 wait 和 sleep、join 一样有可能会被 interrupt 提前唤醒，所以也要用 try-catch 语句

至于 notify，Java中特别约定要把它也放在 synchronized 里面
这两个方法都是由锁对象调用

下面拿段代码演示一下

java 复制代码

public class Main {
    public static void main(String[] args) {
        Object locker = new Object();
        Thread t1 = new Thread(()->{
            synchronized (locker) {
                System.out.println("t1 wait 之前");
                try {
                    locker.wait();
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
                System.out.println("t1 wait 之后");
            }
        });
        Thread t2 = new Thread(()-> {
            try {
                Thread.sleep(3000);
                synchronized (locker) {
                    System.out.println("t2 notify 之前");
                    locker.notify();
                    System.out.println("t2 notify 之后");
                }
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        });

        t1.start();
        t2.start();
    }
}

运行结果：

由结果来梳理一下上述代码的执行过程：

t1 执行后会先拿到锁（因为 t2 sleep 5秒，这个时间够 t1 拿到锁了），并且打印第一句，执行 wait 方法后释放锁并进入阻塞状态
t2 sleep 结束后顺利拿到锁并打印第二句，接着执行 notify 唤醒 t1
由于 t2 还没释放锁，所以 t1 从 WAITING 状态恢复后尝试获取锁，此时会出现一个小阻塞，这个阻塞是由锁竞争引起的
t2 打印第三句之后 t2 线程执行完毕，此时 t1 可以获取到锁了，就会继续打印第四句

wait 和 notify 是通过 Object 对象联系起来的，需要同一个锁对象才能唤醒，比如下面这样是无法唤醒的

java 复制代码

locker1.wait();
locker2.notify();

如果两个 wait 是同一个对象调用的，那 notify 会随机唤醒其中一个

如果想要一次性唤醒所有等待的线程，可以用 notifyAll。不过全唤醒后这些线程要重新获取锁，就会因为锁竞争导致它们实际上是串行执行的（谁先拿到，谁后拿到，是不确定的）

🍌wait 和 join、sleep 的区别

join 是等待另一个线程执行完才会继续执行（死等的情况下）
wait 则是等待其他线程通过 notify 通知才继续执行（也是死等的情况下），相比于 join 就不要求另一个线程必须执行完

和 join 一样，wait 也提供了带有超时时间的等待，超过超时时间没有线程来 notify 的话，就不会再等下去了

wait 和 sleep 都可以被提前唤醒。分别通过 notify 和 interrupt 唤醒
wait 主要是在不知道要等待多久的前提下使用的；而 sleep 是在知道要等多久的前提下使用的，虽然可以提前唤醒，但由于它是通过异常唤醒的，而这说明程序可能出现了一些特殊的情况，所以这种操作不应该作为正常的业务流程

🍉小结

至此，多线程的一些基础用法已经讲得差不多了，在这里总结一下学了啥

线程的基本概念、线程的特性、 线程和进程的区别
Thread 类创建线程
Thread 类一些属性
启动线程、终止线程、等待线程
获取线程引用
线程休眠
线程状态
线程安全问题
①产生原因
②如何解决------使用 synchronized 加锁
③死锁问题
④内存可见性导致的线程安全问题------使用 volatile 保证内存可见性
wait 和 notify 控制线程执行顺序