1 JMM内存模型

由于存在编译器优化、Processor流水线优化、缓存优化等，我们编写的代码不一定是实际运行的代码，我们编写的代码顺序不一定是实际执行的顺序，会出现可见性、原子性、有序性问题。所以我们需要学习JMM内存模型来解决上面的问题。

1.1 什么是JMM

内存模型就是多线程下对共享变量的一组读写规则。

• 共享变量值是否在线程间同步
• 代码可能的执行顺序
• 需要关注的操作就有两种 Load、Store
• Load 就是从缓存读取到寄存器中，如果一级缓存中没有，就会层层读取二级、三级缓存，最后才是Memory
• Store 就是从寄存器运算结果写入缓存，不会直接写入 Memory，当 Cache line 将被 eject 时，会
  writeback 到 Memory

1.2 JMM规范

1.2.1 规则1 - Race Condition

在多线程下，没有依赖关系的代码，在执行共享变量读写操作（至少有一个线程写）时，并不能保证以编写顺序（Program Order）执行，这称为发生了竞态条件（Race Condition）。
例如：
有共享变量x、y，线程1执行

r.r1 = y;
r.r2 = x;

线程2执行

x = 1;
y = 1;

最终的结果可能是 r1==1 而 r2==0

y = 1;
r.r1 = y;
r.r2 = x;
x = 1;

1.2.2 规则2 - Synchronization Order

若要保证多线程下，每个线程的执行顺序（Synchronization Order）按编写顺序（Program Order）执行，那么必须使用 Synchronization Actions(同步动作) 来保证，这些 SA 有

• lock，unlock - synchronized， ReentrantLock
• volatile 方式读写变量 - 保证可见性，防止重排序
• VarHandle 方式读写变量
  例如：
  用 volatile 修饰共享变量 y，线程 1 执行

r.r1 = y;
r.r2 = x;

线程 2 执行

x = 1;
y = 1;

最终的结果就不可能是 r1==1 而 r2==0

1.2.3 规则3 - Happens-Before

线程切换时代码的顺序和可见性
若是变量读写时发生线程切换（例如，线程 1 写入 x，切换至线程 2，线程 2 读取 x）在这些边界的处理上如果有action1 先于 action 2 发生，那么代码可以按确定的顺序执行，这称之为 Happens-Before Order 规则。
用公式表达为

含义为：如果 action1 先于 action2 发生，那么 action1 之前的共享变量的修改对于 action2 可见，且代码按顺序执行。
具体规则
其中 代表线程，而 x 未加说明，是普通共享变量，使用 volatile 会单独说明
1）线程的启动和运行边界

2）线程的结束和 join 边界

3）线程的打断和得知打断边界

4）unlock 与 lock 边界

5）volatile write 与 volatile read 边界

6）传递性

1.2.4 规则4 - Causality

Causality 即因果律：代码之间如存在依赖关系，即使没有加 SA 操作，代码的执行顺序也是可以预见的。

1.2.5 规则5 - 安全发布

若要安全构造对象，并将其共享使用，需要用 final 或 volatile 修饰其成员变量，并避免 this 溢出情况。
静态成员变量可以安全地发布。
例如：

    class Holder {int x1;volatile int x2;public Holder(int v) {x1 = v;x2 = v;}}

需要将它作为全局使用，两个线程，一个创建，一个使用

    Holder f;@Actorpublic void a1() {f = new Holder(1);}@Actorvoid a2(I_Result r) {Holder o = this.f;if (o != null) {r.r1 = o.x2 + o.x1; // 0} else {r.r1 = ‐1; // ‐1}} 

可能会看到未构造完整的对象

2 同步动作

2.1 内存屏障

内存屏障是防止指令重排的一种手段，具体实现与 CPU 架构相关。

2.1.1 LoadLoad

2.1.2 LoadStore

2.1.3 StoreStore

2.1.4 StoreLoad

2.1.5 组合情况

LoadStore + StoreStore = Release

LoadLoad + LoadStore = Acquire

2.2 volatile

2.2.1 本质

volatile增加了内存屏障，可以保证：
💎单一变量的赋值原子性
💎控制了可能的执行路径：线程内按屏障有序，线程切换时按 HB 有序
💎可见性：线程切换时若发生了 写 ->读 则变量可见，顺带影响普通变量可见

2.2.2 visibility

即使是多次读取同一变量，所得结果不合理
初始：

异常情况：

使用 volatile 修饰 x 即可，会阻止编译器对代码的优化，加入的 StoreLoad 屏障会保证红色线程的写入，对后续蓝色线程的读取可见。

2.2.3 partial ordering

意外情况：

volatile 修饰 y

volatile 修饰 x - 行不行？

重要结论：
💎 volatile 写要用来收官，volatile 读要用来开篇

2.2.4 total ordering

初始：

意外情况：

volatile 仅修饰 y或仅修饰x - 不符合最后写最先读

都用volatile修饰意味着它们线程内的次序固定

2.2.5 源码体现

凡是需要 cas （Compare and Swap）操作的地方。
代码片段 1 - AtomicInteger

代码片段 2 - AbstractQueuedSynchronizer

代码片段 3 - ConcurrentHashMap

2.3 synchronized

2.3.1 本质

monitorenter 与 monitorexit 工作原理

相关内存屏障：

2.3.2 Atomicity

2.3.3 优化

• 重量级
  当有竞争时，仍会向系统申请 Monitor 互斥锁。
• 轻量级锁
  如果线程加锁、解锁时间上刚好是错开的，这时候就可以使用轻量级锁，只是使用 cas（Compare and Swap） 尝试将对象头替换为该线程的锁记录地址，如果 cas 失败，会锁重入或触发重量级锁升级。
• 偏向锁
  打个比方，我要进到教室的一个座位上，重量级锁是把整间教室锁上了，这个教室只能容纳获得钥匙的那一个人，其让人进不来。轻量级锁就好比用课本占座，线程每次占座前还得比较一下，课本是不是自己的（cas），频繁 cas 性能也会受到影响。
  而偏向锁就好比座位上已经刻好了线程的名字，线程【专用】这个座位，比 cas 更为轻量。
  但是一旦其他线程访问偏向对象，那么比较麻烦，需要把座位上的名字擦去，这称之为偏向锁撤销，锁也升级为轻量级锁。
  偏向锁撤销也属于昂贵的操作，怎么减少呢，JVM 会记录这一类对象被撤销的次数，如果超过了 20 这个阈值，下次新线程访问偏向对象时，就不用撤销了，而是刻上新线程的名字，这称为重偏向。
  如果撤销次数进一步增加，超过 40 这个阈值，JVM 会认为这一类对象不适合采用偏向锁，会对它们禁用偏向锁，下次新建对象会直接加轻量级锁。

2.3.4 无锁 vs 有锁

• synchronized 更为重量，申请锁、锁重入都要发起系统调用，频繁调用性能会受影响
• synchronized 如果无法获取锁时，线程会陷入阻塞，引起的线程上下文切换成本高
• 虽然做了一系列优化，但轻量级锁、偏向锁都是针对无数据竞争场景的
• 如果数据的原子操作时间较长，仍应该让线程阻塞，无锁适合的是短频快的共享数据修改操作主要用于计数器、停止标记、或是阻塞前的有限尝试

3 更多安全问题

3.1 安全发布

构造也不安全：

public class TestUnsafeConstruct {static Student student;public static void main(String[] args) {student = new Student("zhangsan",10);new Thread(()->{if (student != null) {System.out.println(student.name + " " + student.age);} else {System.out.println("还未初始化！");}}).start();}static class Student {private String name;private int age;public Student(String name, int age) {this.name = name;this.age = age;}}
}

原因分析：
初始：

发生指令重排：对象已产生，对象中的属性还未全部初始化完成
造成红色线程读取到的age==0

用final修饰任意成员变量即可保证不会出现构造不完全的现象

用volatile修饰age，注意赋值操作必须在最后

DCL 安全单例

public class Singleton {private static Singleton instance = null;int x1,x2;private Singleton(int v){x1 = v;x2 = v;}public static Singleton getInstance() {if (instance == null) {synchronized(Singleton.class) {if (instance == null) {instance = new Singleton();}}}return instance;}
}

有问题的情况：

volatile修饰instance：