【JavaEE初阶 — 多线程】内存可见性问题 & volatile
1. 内存可见性问题
内存可见性的概念
什么是内存可见性问题呢？
- 当一个线程对共享变量进行了修改，那么另外的线程都是立即可以看到修改后的最新值。
- 在Java中，可以借助 synchronized、volatile 以及各种Lock 实现可见性。
- 如果我们将变量声明为 volatile，这就指示JVM，这个变量是共享且不稳定的，每次使用它都到主存中进行读取，不能优化。
编译器优化
造成内存可见性问题的原因，是因为编译器优化的机制而造成的，我们先介绍一下什么是编译器优化。
背景
为什么要有编译器优化这样的机制呢？由于程序员的水平参差不齐，研究JDK 的大佬们，就希望通过让 编译器 & JVM 对程序员写的代码，自动的进行优化；
优点
- 对于程序员原有的代码，编译器/JVM会在原有逻辑不变的前提下，对代码进行调整，使程序效率更高；这样的操作，就是编译器优化。
- 也就是说，我们写的代码，编译器会在原有逻辑上，帮我们调整代码，通过编译器优化，可保证原有逻辑不变的前提下，对代码进行修改，使得执行效率得到提高。
缺点
- 编辑器在编译代码的时候，其实它并没有执行代码，它只是根据这个编译的一个静态的代码，来分析这个程序应该怎么去进行调整；所以编译器 “保证原因逻辑不变，再进行优化 ”，这样的 “保证” 并非是能够 100% 生效的；
- 尤其是很多线线程的程序中，因为并发编程随机调度的特点，使得执行多线程程序的过程中，可能会出现诸多变数，这些变数可能会导致编译器出现判断失误；
- 因此，编译器在针对不同的程序，能够做出的判断是有限，并且容易失误的。所以在经过编译器优化后的代码逻辑，与优化前的逻辑，可能会出现偏差。
案例描述
内存可见性问题是造成线程安全问题的原因之一，我们通过下面的代码来感受一下，内存可见性是如何造成线程安全问题的：
代码逻辑：
- 我们定义一个成员变量 flag ，用来作为 t1 线程 run() 方法中的循环终止条件；
- t2 线程用来修改 flag 的值；
- 这样的操作，相当于一个线程进行读取，另一个线程进行修改；
原子性问题和可见性问题代码演示的区别
- 这里演示因为内存可见性，造成线程安全问题，是令一个线程进行读取另一个线程进行修改；
- 演示因为操作非原子性，而造成线程安全问题，是令两个线程同时修改同一个变量，所以两个线程都是在进行修改操作；
预期效果：
- 只要我们通过 t2 ，输入给 flag 的数字是一个非零的值，就会使得我们 t1 线程的循环能够结束；
程序运行结果：
但是当我真正输入一个非零值的时候，回车，发现 t1 线程并没有结束循环，打印结束日志。
通过 Jconsole 观察 t1 线程的状态
- 因为 t2 线程只有一次输入修改 flag 的操作，已经终止；
- 观察到 t1 的线程状态是Runnable，正在持续执行循环；
- 在 t2 线程输入非零值，能让 t1 线程循环结束，进而 t1 终止，这是我们预期结果；
- 但是实际执行结果却并非如此；
- 一个线程读取，一个线程修改，t2(修改线程) 修改的值，并没有被 t1（读取线程）读到，这就是因为编译器优化而造成的"内存可见性问题”；
分析出现内存可见性问题的原因
对于上述代码中，t1 线程的循环判断条件 flag== 0，对其进行细分，会分出两个指令，分别是比较指令（==）和读取指令（读flag）；
程序会先执行读取指令 load ，只有把 flag 这个变量在内存中的值，读取到寄存器中，才会执行比较指令 cmp；
而因为 load，cmp 两步指令是在循环中完成的，while 循环如果没有休眠限制，会在短时间内循环多次，从而重复执行多次 load -> cmp 这样的指令。
但是，load （读内存操作）和 cmp （纯CPU寄存器操作）两步指令的开销是非常大的；
load 的时间开销是 cmp 的几千倍，因为虽然读内存数据比读硬盘数据要快很多，但是如果是拿CPU寄存器和内存比，那就是寄存器快很多；
因此，在 t1 创建好后，run() 方法执行的时间，几乎都在load，cmp 的时间开销是可以忽略不计的；
所以在执行的过程中，JVM就能感知到，load 反复执行的结果是一样的；哪怕我们通过 t2 的 scanner 输入 flag 的时间只有不到 1s，但是站在计算机的角度，这 1s 可以说是沧海桑田；
因此，程序在执行的过程中，JVM 会感受到程序一直在反复读内存的值；
为了减小时间开销， t1 线程的读操作，会被编译器优化成：从读内存的值，到读CPU寄存器（t1 线程的工作内存）的值；
后续再执行 load 指令，就不会再重新读内存，而是直接从寄存器（工作内存）中读取，从而大大减小开销，并且提高了效率；
于是，等到很多秒后，用户真正输入新的值，真正修改 flag 的值，此时 t1 线程就感知不到了
(编译器优化，使得 t1 线程的读操作，不是读取内存)
2. JMM模型文档
3. volatile
volatile 能保证内存可见性
内存可见性就是保证， 每次去读取的时候, 读取到的值都是最新的值（内存中的值），而不是之前缓存在寄存器中的值；volatile 修饰的变量，能够保证"内存可见性"；
代码在写入 volatile 修饰的变量的时候：
- 改变线程工作内存中volatile变量副本的值
- 将改变后的副本的值从工作内存刷新到主内存
代码在读取 volatile 修饰的变量的时候,
- 从主内存中读取 volatile 变量的最新值到线程的工作内存中
- 从工作内存中读取 volatile 变量的副本
前面我们讨论内存可见性时说了,直接访问工作内存(实际是CPU 的寄存器或者 CPU 的缓存),速度
非常快,但是可能出现数据不一致的情况；
加上 volatile，强制读写内存，速度是慢了，但是数据变的更准确了：
原文地址：https://blog.csdn.net/2402_84916296/article/details/143596444
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！