此时我们进行下面的代码段，首先我们默认isQuit是0，t2线程输入isQuit的值，t1线程中如果isQuit一直都是0的话，一直死循环，如果isQuit !=0的时候，我们才判断t1线程结束。

public class test1 {private static int isQuit=0;public static void main(String[] args) {Thread t1=new Thread(()->{while (isQuit==0){}System.out.println("t1线程退出");});Thread t2=new Thread(()->{System.out.println("请输入isQuit: ");Scanner scanner=new Scanner(System.in);//一旦用户输入的值，不为0，此时就会使t1线程执行结束isQuit=scanner.nextInt();});t1.start();t2.start();}
}

此时我输入isQuit是1，然后t1线程理想的结果是跳出循环，然后输出t1线程退出。

但是，当我真正输入1的时候，此时t1线程并没有结束，t1线程正在执行，并且是RUNNABLE状态。很明显，实际效果和预期效果是不一样的，由于多线程引起的，也是线程安全的问题。之前是俩个线程同时修改同一个变量，现在是一个线程读，一个线程修改，也可能出现问题。此处 的问题，就是"内存可见性"情况引起的。

• 1> load读取内存中的isQuit的值到寄存器中
• 2>通过cmp指令比较寄存器的值是否是0，决定是否要继续循环

因为读寄存器的速度>>读内存的速度，所以短时间内，就会进行大量的循环，也就是进行大量的load和cmp操作。此时，编译器jvm就发现了，虽然进行了这么多次load但是load出现的结果都是一样的，并且load操作又非常的消耗时间，一次load花的时间相当于上万次的cmp了。所以编译器就做出了优化，只是第一次循环的时候，才读内存，后面都不再读内存了，而是直接从寄存器中，取出isQuit即可。

原本是load读取到内存中到寄存器中，然后cmp指令在寄存器中比较，依次来，但是由于cmp指令速度太快了大于load操作。编译器的初心是好的，它是希望提高程序的效率，但是提高效率的前提是保证逻辑不变。此时由于修改isQuit代码是另一个线程的操作，编译器没有正确的判定，所以编译器以为没人修改isQuit，就做出了上述优化，也就进一步引起了bug了。

后续 t2线程修改isQuit之后，t1感知不到isQuit变量的变化(感知不到内存的变化），所以一直比较，一直死循环。

解决上述 这个问题，volatile就是解决方案，在多线程的环境下，编译器对于是否要进行这样的优化，判定不一定准。就需要程序员通过volatile关键字告诉编译器，你不要优化（优化是算的快，但是算不准）。

这也告诉我们编译器也不是万能的，也会有一些短板的地方，此时就需要程序员进行补充了。只需要给isQuit加volatile关键字修饰，此时编译器自然就会禁止上述优化过程。

此时，程序就可以顺利退出了。

但是还有一种方式，就是让cmp指令比较的速度变慢，让处于休眠状态，这时候，load操作的开销就不大了，优化就没必要了。

public class test1 {private static int isQuit=0;public static void main(String[] args) {Thread t1=new Thread(()->{while (isQuit==0){try {Thread.sleep(1000);} catch (InterruptedException e) {throw new RuntimeException(e);}}System.out.println("t1线程退出");});Thread t2=new Thread(()->{System.out.println("请输入isQuit: ");Scanner scanner=new Scanner(System.in);//一旦用户输入的值，不为0，此时就会使t1线程执行结束isQuit=scanner.nextInt();});t1.start();t2.start();}
}

但是我们编译器什么时候对其进行优化这是说不清楚的事情，所以用volatile修饰是最靠谱的事情。

🎈volatile 不保证原子性

class Counter{volatile public int count = 0;void increase() {count++;}
}public  class Test2 {public static void main(String[] args) throws InterruptedException {Counter counter = new Counter();Thread t1 = new Thread(() -> {for (int i = 0; i < 50000; i++) {counter.increase();}});Thread t2 = new Thread(() -> {for (int i = 0; i < 50000; i++) {counter.increase();}});t1.start();t2.start();t1.join();t2.join();System.out.println(counter.count);}}

此时的结果依旧不是1w。所以可以证明volatile是不能保证原子性的。

🎈synchronized 也能保证内存可见性

• 去掉 isQuit 的 volatile
• 给 t1 的循环内部加上 synchronized, 并借助object对象加锁.

public class Test3 {private static  int isQuit=0;public static void main(String[] args) {Object object=new Object();Thread t1=new Thread(()->{while (true){synchronized (object){if(isQuit!=0){break;}}}System.out.println("t1线程退出");});Thread t2=new Thread(()->{System.out.println("请输入isQuit: ");Scanner scanner=new Scanner(System.in);//一旦用户输入的值，不为0，此时就会使t1线程执行结束isQuit=scanner.nextInt();});t1.start();t2.start();}
}

🎈Volatile与Synchronized比较

• Volatile是轻量级的synchronized，因为它不会引起上下文的切换和调度，所以Volatile性能更好。
• Volatile只能修饰变量，synchronized可以修饰方法，静态方法，代码块。
• Volatile对任意单个变量的读/写具有原子性，但是类似于i++这种复合操作不具有原子性。而锁的互斥执行的特性可以确保对整个临界区代码执行具有原子性。
• 多线程访问volatile不会发生阻塞，而synchronized会发生阻塞。
• volatile是变量在多线程之间的可见性，synchronize是多线程之间访问资源的同步性。

🚩wait和notify

我们之前学的join方法，它是让一个线程执行完之后，再执行另一个线程，这就是哪个线程调用了join，哪个线程就阻塞。

join控制的是结束的先后顺序，但是理想情况下，是希望在结束前，先后顺序的控制。由于线程之间是抢占式执行的, 因此线程之间执行的先后顺序难以预知. 但是实际开发中有时候我们希望合理的协调多个线程之间的执行先后顺序。

就比如在打篮球的时候，球场上每个运动员都是独立的"执行流"，可以认为是一个"线程“，而完成一个具体的进攻得分动作，则需要多个运动员相互配合，按照一定的顺序执行一定的动作，线程1先"传球",线程2才能"扣球"，然后线程1就等待时机。阻塞等待又被唤醒继续执行，这种操作就是再一直的执行程序，而不是先完成一个线程之后第二线程再完成，然后就结束了。

比如,t1和t2两个线程,希望t1先执行,执行的差不多了,在让t2来干.就可以让t2先wait(阻塞,主动放弃cpu),等t1执行的差不多了,再通过notify来通知t2,把t2唤醒,让t2接着干.

• 使用join,则必须让t1彻底执行完,t2才能运行.如果是希望t1先干50%的活,就让t2开始行动,此时join无能为力.
• 使用sleep,指定一个休眠的时间.但是t1执行完这些代码,到底花了多少时间,不好估计.
• 使用wait和notify可以更好的解决上述的问题.

🎈wait()方法

wait,notify和notifyAll这几个类都是Object类的方法,所以Java里随便一个对象,都可以有这三种方法.

• wait() / wait(long timeout): 让当前线程进入等待状态.
• notify() / notifyAll(): 唤醒在当前对象上等待的线程.

注意: wait, notify, notifyAll 都是 Object 类的方法.

注意,wait也需要这个异常,这个异常,很多带有阻塞功能的方法都带.这些方法都是可以被interrupt方法通过这个异常给唤醒的。后续会再阻塞队列中讲到。

public class wait_notify_test {public static void main(String[] args) throws InterruptedException {Object object=new Object();synchronized (object){System.out.println("wait之前");// 将wait放到synchronized里面调用，保证确实拿到了这个锁，才能释放锁object.wait();System.out.println("wait之后");}}
}

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

🎈解决线程饿死方式

就拿ATM机来举例子，1号滑稽进去之后，就要取钱，发现ATM里面没钱了，取不了，当1号滑稽释放锁之后，此时其他滑稽开始尝试竞争这个锁，但是刚才的1号滑稽，也能参与竞争这个锁。

所以每次都是1号滑稽进去之后，取不了钱，然后又进去，又取不了钱，又进去，其他线程等待锁，都是阻塞状态，没在cpu上执行，当1号滑稽释放锁之后，这些滑稽想去cpu，还需要有一个系统调度的过程，而1号自身，已经在cpu上执行，没有这个调度的过程了，1号近水楼台先得月，更容易拿到锁得。这就导致了一直是1号滑稽进入ATM机中，循环此处，每次都是取不了钱，但是还是1号滑稽占用了这个线程，这样长此以往就形成了”线程饿死“的状态。

🎈notifyAll()方法

        唤醒的方式就有2种方法。notifyAll唤醒的时候，wait要涉及到一个重新获取锁的过程，也是需要串行执行的而并不是并行执行。虽然提供了notifyAll，相比之下notify更可控，用的更多一些。

🚩wait 和 sleep 的对比（面试题）

• 1. wait 需要搭配 synchronized 使用. sleep 不需要.
• 2. wait 是 Object 的方法 sleep 是 Thread 的静态方法

人拥有可以反复尝试的自由，也拥有停步或者回头的权利。