04、共享模型之内存

本章内容

上一章讲解的 Monitor 主要关注的是访问共享变量时，保证临界区代码的原子性

这一章我们进一步深入学习共享变量在多线程间的【可见性】问题与多条指令执行时的【有序性】问题

Java 内存模型

JMM 即 Java Memory Model，它定义了主存、工作内存抽象概念，底层对应着 CPU 寄存器、缓存、硬件内存、
CPU 指令优化等。
JMM 体现在以下几个方面
原子性 - 保证指令不会受到线程上下文切换的影响可见性 - 保证指令不会受 cpu 缓存的影响
有序性 - 保证指令不会受 cpu 指令并行优化的影响

可见性

退不出的循环

先来看一个现象，main 线程对 run 变量的修改对于 t 线程不可见，导致了 t 线程无法停止：

static boolean run = true;

public static void main(String[] args) throws InterruptedException { Thread t = new Thread(()->{
while(run){
// ….
}
});
t.start();

sleep(1);
run = false; // 线程t不会如预想的停下来
}

为什么呢？分析一下：

  1. 初始状态， t 线程刚开始从主内存读取了 run 的值到工作内存。

  1. 因为 t 线程要频繁从主内存中读取 run 的值，JIT 编译器会将 run 的值缓存至自己工作内存中的高速缓存中， 减少对主存中 run 的访问，提高效率

  1. 1 秒之后，main 线程修改了 run 的值，并同步至主存，而 t 是从自己工作内存中的高速缓存中读取这个变量的值，结果永远是旧值

解决方法

volatile（易变关键字）
它可以用来修饰成员变量和静态成员变量，他可以避免线程从自己的工作缓存中查找变量的值，必须到主存中获取 它的值，线程操作 volatile 变量都是直接操作主存

可见性 vs 原子性

前面例子体现的实际就是可见性，它保证的是在多个线程之间，一个线程对 volatile 变量的修改对另一个线程可见， 不能保证原子性，仅用在一个写线程，多个读线程的情况： 上例从字节码理解是这样的：

getstatic
getstatic getstatic getstatic putstatic getstatic
run // 线 程 t 获 取 run true run // 线 程 t 获 取 run true run // 线 程 t 获 取 run true run // 线 程 t 获 取 run true
run // 线 程 main 修 改 run 为 false， 仅 此 一 次
run // 线 程 t 获 取 run false

比较一下之前我们将线程安全时举的例子：两个线程一个 i++ 一个 i— ，只能保证看到最新值，不能解决指令交错

// 假设i的初始值为0
getstatic
i // 线程2-获取静态变量i的值 线程内i=0
getstatic
iconst_1 iadd putstatic
i // 线程1-获取静态变量i的值 线程内i=0
// 线程1-准备常量1
// 线程1-自增 线程内i=1
i // 线程1-将修改后的值存入静态变量i 静态变量i=1
iconst_1
isub putstatic
// 线程2-准备常量1
// 线程2-自减 线程内i=-1
i // 线程2-将修改后的值存入静态变量i 静态变量i=-1

注意 synchronized 语句块既可以保证代码块的原子性，也同时保证代码块内变量的可见性。但缺点是
synchronized 是属于重量级操作，性能相对更低
如果在前面示例的死循环中加入 System.out.println() 会发现即使不加 volatile 修饰符，线程 t 也能正确看到对 run 变量的修改了，想一想为什么？

• 原理之 CPU 缓存结构

模式之两阶段终止

• 模式之 Balking

  有序性

  JVM 会在不影响正确性的前提下，可以调整语句的执行顺序，思考下面一段代码

static int i; static int j;

// 在某个线程内执行如下赋值操作
i = …;
j = …;

可以看到，至于是先执行 i 还是 先执行 j ，对最终的结果不会产生影响。所以，上面代码真正执行时，既可以是

i = …;
j = …;

也可以是

j = …;
i = …;

这种特性称之为『指令重排』，多线程下『指令重排』会影响正确性。为什么要有重排指令这项优化呢？从 CPU
执行指令的原理来理解一下吧

原理之指令级并行诡异的结果

int num = 0;

boolean ready = false;

// 线程1 执行此方法
public void actor1(I_Result r) { if(ready) {
r.r1 = num + num;
} else {
r.r1 = 1;
}
}

// 线程2 执行此方法
public void actor2(I_Result r) { num = 2;
ready = true;
}

I_Result 是一个对象，有一个属性 r1 用来保存结果，问，可能的结果有几种？ 有同学这么分析
情况1：线程1 先执行，这时 ready = false，所以进入 else 分支结果为 1
情况2：线程2 先执行 num = 2，但没来得及执行 ready = true，线程1 执行，还是进入 else 分支，结果为1 情况3：线程2 执行到 ready = true，线程1 执行，这回进入 if 分支，结果为 4（因为 num 已经执行过了）

但我告诉你，结果还有可能是 0 ，信不信吧！
这种情况下是：线程2 执行 ready = true，切换到线程1，进入 if 分支，相加为 0，再切回线程2 执行 num = 2
相信很多人已经晕了

这种现象叫做指令重排，是 JIT 编译器在运行时的一些优化，这个现象需要通过大量测试才能复现： 借助 java 并发压测工具 jcstress https://wiki.openjdk.java.net/display/CodeTools/jcstress
mvn archetype:generate -DinteractiveMode=false -DarchetypeGroupId=org.openjdk.jcstress - DarchetypeArtifactId=jcstress-java-test-archetype -DarchetypeVersion=0.5 -DgroupId=cn.itcast - DartifactId=ordering -Dversion=1.0

创建 maven 项目，提供如下测试类

@JCStressTest
@Outcome(id = {“1”, “4”}, expect = Expect.ACCEPTABLE, desc = “ok”) @Outcome(id = “0”, expect = Expect.ACCEPTABLE_INTERESTING, desc = “!!!!”) @State
public class ConcurrencyTest {

int num = 0;

boolean ready = false;

@Actor
public void actor1(I_Result r) { if(ready) {
r.r1 = num + num;
} else {
r.r1 = 1;
}
}

@Actor
public void actor2(I_Result r) { num = 2;
ready = true;
}
}

执行

mvn clean install
java -jar target/jcstress.jar

会输出我们感兴趣的结果，摘录其中一次结果：

可以看到，出现结果为 0 的情况有 638 次，虽然次数相对很少，但毕竟是出现了。
* INTERESTING tests
Some interesting behaviors observed. This is for the plain curiosity.

2 matching test results.
[OK] test.ConcurrencyTest
(JVM args: [-XX:-TieredCompilation])
[OK] test.ConcurrencyTest
(JVM args: [])

解决方法

volatile 修饰的变量，可以禁用指令重排

@JCStressTest

@Outcome(id = {“1”, “4”}, expect = Expect.ACCEPTABLE, desc = “ok”) @Outcome(id = “0”, expect = Expect.ACCEPTABLE_INTERESTING, desc = “!!!!”) @State
public class ConcurrencyTest {

int num = 0;
volatile boolean ready = false; @Actor
public void actor1(I_Result r) { if(ready) {
r.r1 = num + num;
} else {
r.r1 = 1;
}
}

@Actor
public void actor2(I_Result r) { num = 2;
ready = true;
}

}

结果为：

* INTERESTING tests
Some interesting behaviors observed. This is for the plain curiosity.

0 matching test results.

原理之 volatile

happens-before
happens-before 规定了对共享变量的写操作对其它线程的读操作可见，它是可见性与有序性的一套规则总结，抛开以下 happens-before 规则，JMM 并不能保证一个线程对共享变量的写，对于其它线程对该共享变量的读可见
线程解锁 m 之前对变量的写，对于接下来对 m 加锁的其它线程对该变量的读可见

static int x;
static Object m = new Object();

new Thread(()->{ synchronized(m) {
x = 10;

}
},”t1”).start();

new Thread(()->{ synchronized(m) {
System.out.println(x);
}
},”t2”).start();

线程对 volatile 变量的写，对接下来其它线程对该变量的读可见

volatile static int x;

new Thread(()->{ x = 10;
},”t1”).start();

new Thread(()->{ System.out.println(x);
},”t2”).start();

线程 start 前对变量的写，对该线程开始后对该变量的读可见

static int x; x = 10;
new Thread(()->{ System.out.println(x);
},”t2”).start();

线程结束前对变量的写，对其它线程得知它结束后的读可见（比如其它线程调用 t1.isAlive() 或 t1.join()等待它结束）

static int x;

Thread t1 = new Thread(()->{ x = 10;
},”t1”);
t1.start();

t1.join(); System.out.println(x);

线程 t1 打断 t2（interrupt）前对变量的写，对于其他线程得知 t2 被打断后对变量的读可见（通过
t2.interrupted 或 t2.isInterrupted）

static int x;

public static void main(String[] args) { Thread t2 = new Thread(()->{
while(true) {
if(Thread.currentThread().isInterrupted()) { System.out.println(x);
break;
}
}
},”t2”);
t2.start();

new Thread(()->{ sleep(1);
x = 10;
t2.interrupt();
},”t1”).start();

while(!t2.isInterrupted()) { Thread.yield();
}
System.out.println(x);
}

对变量默认值（0，false，null）的写，对其它线程对该变量的读可见
y hb-> z
x hb-> z

具有传递性，如果 并且
x hb-> y
那么有
，配合 volatile 的防指令重排，有下面的例子

volatile static int x; static int y;

new Thread(()->{ y = 10;
x = 20;
},”t1”).start();

new Thread(()->{
// x=20 对 t2 可见, 同时 y=10 也对 t2 可见
System.out.println(x);
},”t2”).start();

变量都是指成员变量或静态成员变量参考： 第17页

习题

balking 模式习题

希望 doInit() 方法仅被调用一次，下面的实现是否有问题，为什么？

public class TestVolatile {
volatile boolean initialized = false; void init() {
if (initialized) { return;
}
doInit(); initialized = true;
}

private void doInit() {

}
}

线程安全单例习题

单例模式有很多实现方法，饿汉、懒汉、静态内部类、枚举类，试分析每种实现下获取单例对象（即调用
getInstance）时的线程安全，并思考注释中的问题
饿汉式：类加载就会导致该单实例对象被创建
懒汉式：类加载不会导致该单实例对象被创建，而是首次使用该对象时才会创建 实现1：
// 问题1：为什么加 final
// 问题2：如果实现了序列化接口, 还要做什么来防止反序列化破坏单例
public final class Singleton implements Serializable {
// 问题3：为什么设置为私有? 是否能防止反射创建新的实例? private Singleton() {}
// 问题4：这样初始化是否能保证单例对象创建时的线程安全?
private static final Singleton INSTANCE = new Singleton();
// 问题5：为什么提供静态方法而不是直接将 INSTANCE 设置为 public, 说出你知道的理由
public static Singleton getInstance() { return INSTANCE;
}
public Object readResolve() { return INSTANCE;
}
}

实现2：

// 问题1：枚举单例是如何限制实例个数的
// 问题2：枚举单例在创建时是否有并发问题
// 问题3：枚举单例能否被反射破坏单例
// 问题4：枚举单例能否被反序列化破坏单例
// 问题5：枚举单例属于懒汉式还是饿汉式
// 问题6：枚举单例如果希望加入一些单例创建时的初始化逻辑该如何做
enum Singleton { INSTANCE;
}

实现3：

public final class Singleton { private Singleton() { }
private static Singleton INSTANCE = null;
// 分析这里的线程安全, 并说明有什么缺点
public static synchronized Singleton getInstance() { if( INSTANCE != null ){
return INSTANCE;
}
INSTANCE = new Singleton(); return INSTANCE;
}
}

实现4：DCL

public final class Singleton { private Singleton() { }
// 问题1：解释为什么要加 volatile ?
private static volatile Singleton INSTANCE = null;

// 问题2：对比实现3, 说出这样做的意义
public static Singleton getInstance() { if (INSTANCE != null) {
return INSTANCE;
}
synchronized (Singleton.class) {
// 问题3：为什么还要在这里加为空判断, 之前不是判断过了吗
if (INSTANCE != null) { // t2 return INSTANCE;
}
INSTANCE = new Singleton(); return INSTANCE;
}
}
}

实现5：

public final class Singleton { private Singleton() { }
// 问题1：属于懒汉式还是饿汉式
private static class LazyHolder {
static final Singleton INSTANCE = new Singleton();
}
// 问题2：在创建时是否有并发问题
public static Singleton getInstance() { return LazyHolder.INSTANCE;
}
}

本章小结

本章重点讲解了 JMM 中的
可见性 - 由 JVM 缓存优化引起
有序性 - 由 JVM 指令重排序优化引起
happens-before 规则原理方面
CPU 指令并行
volatile
模式方面
两阶段终止模式的 volatile 改进同步模式之 balking