【Java并发编程】深入理解并发可见性、有序性、原子性与JMM内存模型
6 线程安全要素与JMM内存模型
6.1 线程安全三要素
原子性
原子，即一个不可再分割的颗粒；
原子性指的是一个操作，要么完全执行成功或完全执行失败；
不采取任何的原子性保障措施的自增操作并不是原子性的，比如i++操作；
线程上下文切换可能会带来原子性问题，解决方案：Atomic原子类（CAS）、sychronized、Lock；
案例分析:
public class AtomicTest {
private static int counter = 0;
private static AtomicInteger casCounter = new AtomicInteger();
private static Object lock = new Object();
private static ReentrantLock reentrantLock = new ReentrantLock();
public static void main(String[] args) {
for (int i = 0; i < 10; i++) {
Thread thread = new Thread(() -> {
for (int j = 0; j < 10000; j++) {
counter++;
// 第一种：synchronized保证原子性
// synchronized (lock) {
// counter++;
// }
// 第二种：CAS原子类保证原子性
// casCounter.addAndGet(1);
// 第三中：Lock锁保证原子性
// reentrantLock.lock();
// counter++;
// reentrantLock.unlock();
}
});
thread.start();
}
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(counter);
}
}
结果：
37286
执行结果与预期不符，预期应该是10*10000=100000，存在线程安全问题；
通过代码中注释的三种方法，可以解决线程安全问题；
可见性
一个线程对共享变量的更改，另一个线程能立即看到；
volatile可以保证线程每次读取的值为主存最新值；
jmm模型，cpu缓存和主存数据交互带来可见性问题，解决方案：sychronized、Lock、volatile；
案例分析：
public class VisibilityTest {
private volatile boolean flag = true;
// 第一种方案
// private boolean flag = true;
// 第二种方案
// private Object objLock = new Object();
// 第三种方案
private ReentrantLock reentrantLock = new ReentrantLock();
public void refresh() {
// 希望结束数据加载工作
flag = false;
System.out.println(Thread.currentThread().getName() + "修改flag:"+flag);
}
public void load() {
System.out.println(Thread.currentThread().getName() + "开始执行.....");
// synchronized (objLock){
// while (flag) {
// //TODO 业务逻辑：加载数据
// }
// }
// reentrantLock.lock();
// while (flag) {
// //TODO 业务逻辑：加载数据
// }
// reentrantLock.unlock();
while (flag) {
//TODO 业务逻辑：加载数据
}
System.out.println(Thread.currentThread().getName() + "数据加载完成，跳出循环");
}
public static void main(String[] args) throws InterruptedException {
VisibilityTest test = new VisibilityTest();
// 线程threadA模拟数据加载场景
Thread threadA = new Thread(() -> test.load(), "threadA");
threadA.start();
// 让threadA先执行一会儿后再启动线程B
Thread.sleep(1000);
// 线程threadB通过修改flag控制threadA的执行时间，数据加载可以结束了
Thread threadB = new Thread(() -> test.refresh(), "threadB");
threadB.start();
}
}
结果：
threadA开始执行.....
threadB修改flag:false
threadA没有跳出循环，也就是说threadB对共享变量flag的更新操作对threadA不可见，存在可见性问题。
顺序性
程序执行的顺序按照代码的先后顺序执行；
处理器为了优化会对指令进行重排，带来顺序性问题，解决方案：volatile的happens-before规则可防止指令重；
synchronized不能保证顺序性；
案例分析：
public class ReOrderTest {
private static int x = 0, y = 0;
private static int a = 0, b = 0;
public static void main(String[] args) throws InterruptedException {
int i=0;
while (true) {
i++;
x = 0;
y = 0;
a = 0;
b = 0;
/**
* x,y的值是多少:
*/
Thread thread1 = new Thread(new Runnable() {
@Override
public void run() {
//用于调整两个线程的执行顺序
shortWait(20000);
a = 1;
x = b;
}
});
Thread thread2 = new Thread(new Runnable() {
@Override
public void run() {
b = 1;
y = a;
}
});
thread1.start();
thread2.start();
thread1.join();
thread2.join();
System.out.println("第" + i + "次（" + x + "," + y + ")");
if (x==0&&y==0){
break;
}
}
}
public static void shortWait(long interval){
long start = System.nanoTime();
long end;
do{
end = System.nanoTime();
}while(start + interval >= end);
}
}
结果：
...
第477518次（0,1)
第477519次（0,1)
第477520次（0,0)
6.2 java内存模型JMM
（1）概念
从抽象的角度来看，JMM定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存中，每个线程都有一个私有的本地内存，本地内存中存储了共享变量的副本。本地内存是JMM的一个抽象概念，并不真实存在，它涵盖了缓存，写缓冲区，寄存器以及其他的硬件和编译器优化。
根据JMM的规定，线程对共享变量的所有操作都必须在自己的本地内存中进行，不能直接从主内存中读取。
轻量级锁机制，保证可见性、有序性，不保证原子性；
线程从主存读取数据：主内存》总线bus访问主存》工作空间》执行引擎
（2）应用
volatile，保证变量值从主存中读取，实现了可见性，happens-before机制实现了禁止指令重排；
synchronized，锁住当前变量，实现了原子性；
（3）Java内存模型内存交互操作
- lock（锁定）
作用于主内存的变量，把一个变量标记为一条线程独占状态
- unlock（解锁）
作用于主内存的变量，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定
- read（读取）
作用于主内存的变量，把一个变量值从主内存传输到线程的工作内存中，以便随后的load动作使用
- load（载入）
作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中
- use（使用）
作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎
- assign（赋值）
作用于工作内存的变量，它把一个从执行引擎接收到的值赋给工作内存的变量
- store（存储）
作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中，以便随后的write的操作
- write（写入）
作用于工作内存的变量，它把store操作从工作内存中的一个变量的值传送到主内存的变量中
Java内存模型还规定了在执行上述八种基本操作时，必须满足如下规则：
- 如果要把一个变量从主内存中复制到工作内存，就需要按顺序地执行read和load操作， 如果把变量从工作内存中同步回主内存中，就要按顺序地执行store和write操作。但Java内存模型只要求上述操作必须按顺序执行，而没有保证必须是连续执行。
- 不允许read和load、store和write操作之一单独出现
- 不允许一个线程丢弃它的最近assign的操作，即变量在工作内存中改变了之后必须同步到主内存中。
- 不允许一个线程无原因地（没有发生过任何assign操作）把数据从工作内存同步回主内存中。
- 一个新的变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量。即就是对一个变量实施use和store操作之前，必须先执行过了assign和load操作。
- 一个变量在同一时刻只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。lock和unlock必须成对出现
- 如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量前需要重新执行load或assign操作初始化变量的值
- 如果一个变量事先没有被lock操作锁定，则不允许对它执行unlock操作；也不允许去unlock一个被其他线程锁定的变量。
- 对一个变量执行unlock操作之前，必须先把此变量同步到主内存中（执行store和write操作）。
（4）Java中可见性底层有两种实现：
- 内存屏障
synchronized
Threed.sleep(10)
volatile
- cup上下文切换
Threed.yield()
Threed.sleep(0)
synchronized/Lock锁的内存语义
锁获取和释放的内存语义：
- 当线程获取锁时，JMM会把该线程对应的本地内存置为无效。
- 当线程释放锁时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存中。
synchronized关键字的作用是确保多个线程访问共享资源时的互斥性和可见性。在获取锁之前，线程会将共享变量的最新值从主内存中读取到线程本地的缓存中，释放锁时会将修改后的共享变量的值刷新到主内存中，以保证可见性。
volatile的内存语义
volatile读写的内存语义：
- volatile写的内存语义：当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量值刷新到主内存。
- volatile读的内存语义：当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效，线程接下来将从主内存中读取共享变量。
volatile内存语义的实现原理：
JMM属于语言级的内存模型，它确保在不同的编译器和不同的处理器平台之上，通过禁止特定类型的编译器重排序和处理器重排序，为程序员提供一致的内存可见性保证。
volatile禁止重排序场景：
- 当第二个操作是volatile写时，不管第一个操作是什么，都不能重排序。
- 当第一个操作是volatile读时，不管第二个操作是什么，都不能重排序。
- 当第一个操作是volatile写，第二个操作是volatile读时，不能重排序。
volatile的作用：
- 保证缓存一致性
保证线程间变量的可见性，被volatile修饰的变量，在取或设置变量时，保证变量的改变被及时同步到主内存和工作空间内存。通过mesi协议lock锁住缓存行，能够保证可见性、有序性，不能保证原子性；
- 防止指令重排
多线程使保证结果正确；
注意：
volatile修饰数组变量，修饰的是数组的引用，而不是整个数组。多线程改变数组的元素不能受volatile的保护；
volatile不能保证数据在多个线程下同时写时的线程安全，volatile最适用的场景：一个线程写，多个线程读；
有序性案例分析：
单例模式的双重判空方案需要通过volatile修饰Singleton对象；
public class Singleton {
private static Singleton singleton;
private Singleton() {
}
/**
* 双重检查锁定（Double-checked Locking）实现单例对象的延迟初始化
*
* @return
*/
public static Singleton getSingleton() {
if (singleton == null) {
synchronized (Singleton.class) {
if (singleton == null) {
singleton = new Singleton();
}
}
}
return singleton;
}
}
正确的用法是通过volatile修饰Singleton对象：
private volatile static Singleton singleton;
原因就在于singleton = new Singleton()这行代码，创建了一个对象。这行代码可以分解为三行伪代码：
memory = allocate(); //1. 分配对象内存空间
ctorInstance(memory); //2.初始化对象
instance = memory; //3.设置instance指向刚刚分配的内存地址
上面2和3之间可能会被重排序，重排序之后的执行时序如下：
memory = allocate(); //1. 分配对象内存空间
instance = memory; //3.设置instance指向刚刚分配的内存地址
//注意，此时对象还没有被初始化
ctorInstance(memory); //2.初始化对象
happens-before
happens-before的定义：
JSR-133使用happens-before的概念来指定两个操作之间的执行顺序。由于这两个操作可以在一个线程之内，也可以在不同的线程之内。因此，JMM可以通过happens-before关系向程序员提供跨线程的内存可见性保证。
JSR-133规范对happens-before关系的定义如下：
1）如果一个操作happens-before 另一个操作，那么第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前。 这是JMM对程序员的承诺， 注意，这只是JMM向程序员做出的保证。
2）两个操作之间存在happens-before关系，并不意味着Java平台的具体实现必须要按照happens-before关系指定的顺序来执行。如果重排序之后的执行结果，与按happens-before关系来执行的结果一致，那么这种排序并不非法，也就是说，JMM允许这种排序。这是JMM对编译器和处理器重排序的约束原则
JMM遵循一个基本原则：只要不改变程序的执行结果，编译器和处理器怎么优化都行。
- as-if-serial语义保证单线程内程序的执行结果不被改变
- happens-before关系保证正确同步的多线程程序的执行结果不被改变。
这么做的目的是为了在不改变程序执行结果的前提下，尽可能地提高程序执行的并行度。
JSR-133规范定义了如下happens-before规则：
1）程序顺序规则：一个线程中的每个操作，happens-before于该线程中的任意后续操作；
2）锁定规则：对一个锁的解锁，happens-before于随后对这个锁的加锁；
3）volatile变量规则：对一个volatile变量的写操作，happens-before于任意后续对这个volatile变量的读操作；
4）传递规则：如果A happens-before B，并且B happens-before C，则A happens-before C；
5）线程启动规则：如果线程A调用线程B的start()方法来启动线程B，则start()操作happens-before于线程B中的任意操作；
6）线程中断规则：对线程interrupt()方法的调用happens-before于被中断线程的代码检测到中断事件的发生；
7）线程终结规则：如果线程A执行操作ThreadB.join()并成功返回，那么线程B中的任意操作happens-before于线程A从ThreadB.join()操作成功返回；
8）对象终结规则：一个对象的初始化完成happens-before于它的finalize()方法的开始。
缓存一致性协议mesi
（1）为什么需要缓存一致性协议？
cpu有自己的缓存，多个cpu共用同一个主存，当多个cpu对同一个主存数据操作后回写到主存时，以哪一个cpu结果为准呢，所以在cpu缓存与主存之间需要一个协议，即缓存一致性协议，mesi是其中的一种协议。
图示：
（2）缓存一致性协议
作用是保证内存一致性，缓存行状态的转换，嗅探其他cpu操作状态；
cpu缓存（L123）最小单元为缓存行，cpu相关内存快慢：寄存器>L1>L2>L3>内存条；
cpu取内存数据（内存条）过程：通知内存控制器占用总线带宽》通知内存加锁》发起内存读取请求》等待回应》回应保存到L3（通过多级缓存传递机制）》传递到cpu》解除总线锁定；
（3）缓存一致性协议状态
| 状态 | 描述 | 监听任务 |
|---|---|---|
| M 修改（Modified） | 该 cache line 有效，数据被修改了，和内存中的数据不一致，数据只存在于本 cache 中 | 缓存行必须时刻监听所有试图读该缓存行相对于主存的操作，这种操作必须在缓存将该缓存行写回主存并将状态编程S（共享）状态之前被延迟执行 |
| E 独享/互斥（Exclusive） | 该 cache line 有效，数据和内存中的数据一致，数据只存在于本 cache 中 | 缓存行也必须监听其它缓存读主存中该缓存行的操作，一但有这种操作，该缓存行需要变成S（共享）状态 |
| S 共享（Shared） | 该 cache line 有效，数据和内存中的数据一致，数据存在于多 cache 中 | 缓存行也必须监听其它缓存使该缓存行无效或者独享该缓存的请求，并将该缓存行变为I（无效） |
| I 无效（Invalid） | 该 cache line 无效 | 无 |
指令重排
（1）为什么要进行指令重排
cpu为了充分利用运算单元，会将代码进行重新排序，保证执行结果与顺序执行结果一致，但并不保证计算顺序与原来代码顺序一致；
在单线程环境下不影响执行结果，多线程环境下可能会影响执行结果；
单例，双重非空判断，如果不使用valitle修饰变量，会导致指令重排，导致返回的实例没有被实例化（没有组装数据）；
（2）指令重排的时机
- 字节码编译成机器码时；
- cpu运行时；
（3）如何解决
通过volatile修饰的变量不会进行指令重排；
总线风暴：使用volatile会导致大量的总线交互、嗅探，导致总线压力过大，可以通过sychronized关键字降低bus压力；
一般可以通过缓存行+mesi协议，如果跨缓存行只能加总线锁；
总结
Java中的volatile关键字可以保证多线程操作共享变量的可见性以及禁止指令重排序，synchronized关键字不仅保证可见性，同时也保证了原子性（互斥性）。在更底层，JMM通过内存屏障来实现内存的可见性以及禁止重排序。为了程序员的方便理解，提出了happens-before，它更加的简单易懂，从而避免了程序员为了理解内存可见性而去学习复杂的重排序规则以及这些规则的具体实现方法。