【并发编程篇】并发编程之深入理解JMM&并发三大特性（上）
1、前言
1.1 并发和并行基础基础概念
- 并行：指在同一时刻，有多条指令在多个处理器上同时执行
- 并发：指在同一时刻只能有一条指令执行，但多个进程指令被快速的轮换执 行，使得在宏观上具有多个进程同时执行的效果，但在微观上并不是同时执行的，只是把时间 分成若干段，使多个进程快速交替的执行。
1.2 图解
并行：
并发：
1.3 为什么需要多线程
众所周知，CPU、内存、I/O 设备的速度是有极大差异的，为了合理利用 CPU 的高性能，平衡这三者的速度差异，计算机体系结构、操作系统、编译程序都做出了贡献，主要体现为:
- CPU 增加了缓存，以均衡与内存的速度差异；// 导致可见性问题
- 操作系统增加了进程、线程，以分时复用 CPU，进而均衡 CPU 与 I/O 设备的速度差异；// 导致原子性问题
- 编译程序优化指令执行次序，使得缓存能够得到更加合理地利用。// 导致有序性问题
1.4 线程不安全示例
如果多个线程对同一个共享数据进行访问而不采取同步操作的话，那么操作的结果是不一致的。
以下代码演示了 1000 个线程同时对 cnt 执行自增操作，操作结束之后它的值有可能小于 1000。
public class ThreadUnsafeExample {
private int cnt = 0;
public void add() {
cnt++;
}
public int get() {
return cnt;
}
}
public static void main(String[] args) throws InterruptedException {
final int threadSize = 1000;
ThreadUnsafeExample example = new ThreadUnsafeExample();
final CountDownLatch countDownLatch = new CountDownLatch(threadSize);
ExecutorService executorService = Executors.newCachedThreadPool();
for (int i = 0; i < threadSize; i++) {
executorService.execute(() -> {
example.add();
countDownLatch.countDown();
});
}
countDownLatch.await();
executorService.shutdown();
System.out.println(example.get());
}
997 // 结果总是小于1000
2、并发详解
2.1 并发三大特性
2.1.1 可见性
概念解释
当一个线程修改了共享变量的值，其他线程能够看到修改的值。Java 内存模型是通过在变量 修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介 的方法来实现可见性的。
导致可见性的原因
由于CPU 的缓存机制引起的
如何保证可见性
- 通过 volatile 关键字保证可见性。
- 通过 内存屏障保证可见性。
- 通过 synchronized 关键字保证可见性。
- 通过 Lock保证可见性。
- 通过 final 关键字保证可见性
可见性案例
package com.dreamer;
/**
*
* -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -Xcomp
* hsdis-amd64.dll
* 可见性案例
*/
public class VisibilityTest {
// storeLoad JVM内存屏障 ----> (汇编层面指令) lock; addl $0,0(%%rsp)
// lock前缀指令不是内存屏障的指令，但是有内存屏障的效果 缓存失效
private volatile boolean flag = true;
private Integer count = 0;
public void refresh() {
flag = false;
System.out.println(Thread.currentThread().getName() + "修改flag:"+flag);
}
public void load() {
System.out.println(Thread.currentThread().getName() + "开始执行.....");
while (flag) {
//TODO 业务逻辑
count++;
//JMM模型 内存模型： 线程间通信有关 共享内存模型
//没有跳出循环 可见性的问题
//能够跳出循环 内存屏障
//UnsafeFactory.getUnsafe().storeFence();
//能够跳出循环 ? 释放时间片，上下文切换 加载上下文：flag=true
//Thread.yield();
//能够跳出循环 内存屏障
//System.out.println(count);
//LockSupport.unpark(Thread.currentThread());
//shortWait(1000000); //1ms
//shortWait(1000);
// try {
// Thread.sleep(1); //内存屏障
// } catch (InterruptedException e) {
// e.printStackTrace();
// }
//总结： Java中可见性如何保证？ 方式归类有两种：
//1. jvm层面 storeLoad内存屏障 ===> x86 lock替代了mfence
// 2. 上下文切换 Thread.yield();
}
System.out.println(Thread.currentThread().getName() + "跳出循环: count=" + count);
}
public static void main(String[] args) throws InterruptedException {
VisibilityTest test = new VisibilityTest();
// 线程threadA模拟数据加载场景
Thread threadA = new Thread(() -> test.load(), "threadA");
threadA.start();
// 让threadA执行一会儿
Thread.sleep(1000);
// 线程threadB通过flag控制threadA的执行时间
Thread threadB = new Thread(() -> test.refresh(), "threadB");
threadB.start();
}
public static void shortWait(long interval) {
long start = System.nanoTime();
long end;
do {
end = System.nanoTime();
} while (start + interval >= end);
}
}
2.2.1 有序性
概念解释
即程序执行的顺序按照代码的先后顺序执行。JVM 存在指令重排，所以存在有序性问题。
如何保证有序性
- 通过 volatile 关键字保证可见性。
- 通过 内存屏障保证可见性。
- 通过 synchronized关键字保证有序性。
- 通过 Lock保证有序性。
2.3.1 原子性
概念解释：
一个或多个操作，要么全部执行且在执行过程中不被任何因素打断，要么全部不执行。在 Java 中，对基本数据类型的变量的读取和赋值操作是原子性操作（64位处理器）。不采取任 何的原子性保障措施的自增操作并不是原子性的。
如何保证原子性：
- 通过 synchronized 关键字保证原子性。
- 通过 Lock保证原子性。
- 通过 CAS保证原子性。
3、Java内存模型（JMM）
3.1 定义
Java虚拟机规范中定义了Java内存模型（Java Memory Model，JMM），用于屏蔽掉各 种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的并发效 果，JMM规范了Java虚拟机与计算机内存是如何协同工作的：规定了一个线程如何和何时可 以看到由其他线程修改过后的共享变量的值，以及在必须时如何同步的访问共享变量。JMM 描述的是一种抽象的概念，一组规则，通过这组规则控制程序中各个变量在共享数据区域和私 有数据区域的访问方式，JMM是围绕原子性、有序性、可见性展开的。
3.2 JMM与硬件内存架构的关系
3.2.1 解释
Java内存模型与硬件内存架构之间存在差异。硬件内存架构没有区分线程栈和堆。对于硬 件，所有的线程栈和堆都分布在主内存中。部分线程栈和堆可能有时候会出现在CPU缓存中和 CPU内部的寄存器中。如下图所示，Java内存模型和计算机硬件内存架构是一个交叉关系
3.2.2 内存交互操作
关于主内存与工作内存之间的具体交互协议，即一个变量如何从主内存拷贝到工作内存、 如何从工作内存同步到主内存之间的实现细节，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操作）。
3.3 JMM的内存可见性保证
按程序类型，Java程序的内存可见性保证可以分为下列3类：
- 单线程程序。单线程程序不会出现内存可见性问题。编译器、runtime和处理器会 共同确保单线程程序的执行结果与该程序在顺序一致性模型中的执行结果相同。
- 正确同步的多线程程序。正确同步的多线程程序的执行将具有顺序一致性（程序的 执行结果与该程序在顺序一致性内存模型中的执行结果相同）。这是JMM关注的重点， JMM通过限制编译器和处理器的重排序来为程序员提供内存可见性保证。
- 未同步/未正确同步的多线程程序。JMM为它们提供了最小安全性保障：线程执行 时读取到的值，要么是之前某个线程写入的值，要么是默认值未同步程序在JMM中的执 行时，整体上是无序的，其执行结果无法预知。 JMM不保证未同步程序的执行结果与 该程序在顺序一致性模型中的执行结果一致。
未同步程序在JMM中的执行时，整体上是无序的，其执行结果无法预知。未同步程序在 两个模型中的执行特性有如下几个差异。
- 顺序一致性模型保证单线程内的操作会按程序的顺序执行，而JMM不保证单线程内的 操作会按程序的顺序执行，比如正确同步的多线程程序在临界区内的重排序。
- 顺序一致性模型保证所有线程只能看到一致的操作执行顺序，而JMM不保证所有线程 能看到一致的操作执行顺序。
- 顺序一致性模型保证对所有的内存读/写操作都具有原子性，而JMM不保证对64位的 long型和double型变量的写操作具有原子性（32位处理器）。
JVM在32位处理器上运行时，可能会把一个64位long/double型变量的写操作拆分为两个32位的写操 作来执行。这两个32位的写操作可能会被分配到不同的总线事务中执行，此时对这个64位变量的写操 作将不具有原子性。从JSR-133内存模型开始（即从JDK5开始），仅仅只允许把一个64位 long/double型变量的写操作拆分为两个32位的写操作来执行，任意的读操作在JSR-133中都必须具 有原子性
3.4 volatile的内存语义
3.4.1 volatile的特性
- 可见性：对一个volatile变量的读，总是能看到（任意线程）对这个volatile变量最 后的写入。
- 原子性：对任意单个volatile变量的读/写具有原子性，但类似于volatile++这种复 合操作不具有原子性（基于这点，我们通过会认为volatile不具备原子性）。volatile仅 仅保证对单个volatile变量的读/写具有原子性，而锁的互斥执行的特性可以确保对整个 临界区代码的执行具有原子性。
- 64位的long型和double型变量，只要它是volatile变量，对该变量的读/写就具有原子性。 有序性：对volatile修饰的变量的读写操作前后加上各种特定的内存屏障来禁止指 令重排序来保障有序性。
- 在JSR-133之前的旧Java内存模型中，虽然不允许volatile变量之间重排序，但旧的Java内存模型允许 volatile变量与普通变量重排序。为了提供一种比锁更轻量级的线程之间通信的机制，JSR-133专家组 决定增强volatile的内存语义：严格限制编译器和处理器对volatile变量与普通变量的重排序，确保 volatile的写-读和锁的释放-获取具有相同的内存语义。
3.4.2 volatile写-读的内存语义
当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量值刷新到 主内存。
当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效，线程接下来 将从主内存中读取共享变量。
3.4.3 volatile可见性实现原理
JMM内存交互层面实现
volatile修饰的变量的read、load、use操作和assign、store、write必须是连续的，即修 改后必须立即同步回主内存，使用时必须从主内存刷新，由此保证volatile变量操作对多线程 的可见性。
硬件层面实现
通过lock前缀指令，会锁定变量缓存行区域并写回主内存，这个操作称为“缓存锁定”， 缓存一致性机制会阻止同时修改被两个以上处理器缓存的内存区域数据。一个处理器的缓存回 写到内存会导致其他处理器的缓存无效。
3.4.4 volatile在hotspot的实现
字节码解释器实现
JVM中的字节码解释器(bytecodeInterpreter)，用C++实现了JVM指令，其优点是实现相对 简单且容易理解，缺点是执行慢。 bytecodeInterpreter.cpp
模板解释器实现
模板解释器(templateInterpreter)，其对每个指令都写了一段对应的汇编代码，启动时将每个 指令与对应汇编代码入口绑定，可以说是效率做到了极致。 templateTable_x86_64.cpp
在linux系统x86中的实现
lock前缀指令的作用
- 确保后续指令执行的原子性。在Pentium及之前的处理器中，带有lock前缀的指令在执 行期间会锁住总线，使得其它处理器暂时无法通过总线访问内存，很显然，这个开销很 大。在新的处理器中，Intel使用缓存锁定来保证指令执行的原子性，缓存锁定将大大降低 lock前缀指令的执行开销。
- LOCK前缀指令具有类似于内存屏障的功能，禁止该指令与前面和后面的读写指令重排 序。
- LOCK前缀指令会等待它之前所有的指令完成、并且所有缓冲的写操作写回内存(也就是 将store buffer中的内容写入内存)之后才开始执行，并且根据缓存一致性协议，刷新 store buffer的操作会导致其他cache中的副本失效。
汇编层面volatile的实现
添加下面的jvm参数查看之前可见性Demo的汇编指令
‐XX:+UnlockDiagnosticVMOptions
‐XX:+PrintAssembly
‐Xcomp
3.5 有序性问题深入分析
3.5.1 指令重排序
含义
Java语言规范规定JVM线程内部维持顺序化语义。即只要程序的最终结果与它顺序化情况 的结果相等，那么指令的执行顺序可以与代码顺序不一致，此过程叫指令的重排序。 指令重排序的意义：JVM能根据处理器特性（CPU多级缓存系统、多核处理器等）适当的对机 器指令进行重排序，使机器指令能更符合CPU的执行特性，最大限度的发挥机器性能。 在编译器与CPU处理器中都能执行指令重排优化操作。
3.5.2 volatile重排序规则
图解规则：
volatile禁止重排序场景：
- 第二个操作是volatile写，不管第一个操作是什么都不会重排序
- 第一个操作是volatile读，不管第二个操作是什么都不会重排序
- 第一个操作是volatile写，第二个操作是volatile读，也不会发生重排序
3.6 JMM内存屏障插入策略
3.6.1 图解内存屏障
- 在每个volatile写操作的前面插入一个StoreStore屏障
- 在每个volatile写操作的后面插入一个StoreLoad屏障
- 在每个volatile读操作的后面插入一个LoadLoad屏障
- 在每个volatile读操作的后面插入一个LoadStore屏障
x86处理器不会对读-读、读-写和写-写操作做重排序, 会省略掉这3种操作类型对应的内存 屏障。仅会对写-读操作做重排序，所以volatile写-读操作只需要在volatile写后插入 StoreLoad屏障
3.6.2 在JSR规范中定义了4种内存屏障：
- LoadLoad屏障：（指令Load1; LoadLoad; Load2），在Load2及后续读取操作要读取的数 据被访问前，保证Load1要读取的数据被读取完毕。
- LoadStore屏障：（指令Load1; LoadStore; Store2），在Store2及后续写入操作被刷出前， 保证Load1要读取的数据被读取完毕。
- StoreStore屏障：（指令Store1; StoreStore; Store2），在Store2及后续写入操作执行前， 保证Store1的写入操作对其它处理器可见。
- StoreLoad屏障：（指令Store1; StoreLoad; Load2），在Load2及后续所有读取操作执行 前，保证Store1的写入对所有处理器可见。它的开销是四种屏障中最大的。在大多数处理器的 实现中，这个屏障是个万能屏障，兼具其它三种内存屏障的功能
由于x86只有store load可能会重排序，所以只有JSR的StoreLoad屏障对应它的mfence或 lock前缀指令，其他屏障对应空操作
3.6.3 硬件层内存屏障
硬件层提供了一系列的内存屏障 memory barrier / memory fence(Intel的提法)来提供 一致性的能力。拿X86平台来说，有几种主要的内存屏障：
- lfence，是一种Load Barrier 读屏障
- sfence, 是一种Store Barrier 写屏障
- mfence, 是一种全能型的屏障，具备lfence和sfence的能力 4. Lock前缀，Lock不是一种内存屏障，但是它能完成类似内存屏障的功能。Lock会对 CPU总线和高速缓存加锁，可以理解为CPU指令级的一种锁。它后面可以跟ADD, ADC, AND, BTC, BTR, BTS, CMPXCHG, CMPXCH8B, DEC, INC, NEG, NOT, OR, SBB, SUB, XOR, XADD, and XCHG等指令。
3.6.4 内存屏障有两个能力：
- 阻止屏障两边的指令重排序
- 刷新处理器缓存/冲刷处理器缓存
对Load Barrier来说，在读指令前插入读屏障，可以让高速缓存中的数据失效，重新从主 内存加载数据；对Store Barrier来说，在写指令之后插入写屏障，能让写入缓存的最新数据写 回到主内存。
Lock前缀实现了类似的能力，它先对总线和缓存加锁，然后执行后面的指令，最后释放锁 后会把高速缓存中的数据刷新回主内存。在Lock锁住总线的时候，其他CPU的读写请求都会被 阻塞，直到锁释放。
4 参考文献
- 感谢你赐予我前进的力量
-
微信 
支付宝
