Java并发编程（一） - 初识并发
本文主要内容出自周志明老师《深入理解Java虚拟机》一书，是笔者结合自己的理解，做了一些补充，重新组织排版后，总结的读书笔记。
并发编程知识树概览
计算机性能
摩尔定律
当价格不变时，集成电路上可容纳的元器件的数目，约每隔18-24个月便会增加一倍，性能也将提升一倍。换言之，每一美元所能买到的电脑性能，将每隔18-24个月翻一倍以上。
Amdahl定律
系统中对某一部件采用更快执行方式所能获得的系统性能改进程度，取决于这种执行方式被使用的频率，或所占总执行时间的比例。阿姆达尔定律实际上定义了采取增强（加速）某部分功能处理的措施后可获得的性能改进或执行时间的加速比。
摩尔定律，描述处理器晶体管数量与运行效率之间的发展关系。而Amdahl定律，则是通过系统中并行化与串行化的比重来描述多处理器系统能获得的运算加速能力。
并发处理的广泛应用，使得Amdahl代替摩尔定律成为计算机性能发展的源动力，而这种更替也代表了近年来硬件发展从追求处理器频率到追求多核心并行处理的发展过程。
物理计算机的并发问题
在讲解Java虚拟机的并发知识前，我们先来谈谈物理计算机发展过程中遇到的并发问题，因为它与虚拟机中的情况有不少相似之处，而物理机对并发的处理方案对于虚拟机的实现也有相当大的参考意义。
虽然说一个运算任务，主要是由处理器“计算”完成的，但绝大多数情况下，处理器还要与内存交互，如读取运算数据、储存运算结果等，这个I/O操作是很难消除的。而存储设备与处理器的运算速度又有几个数量级的差距，这就是物理机不同硬件的效率矛盾。为了“压榨”处理器的运算能力，现代计算机通常采取以下方案：
- 加入高速缓存：解决处理器与内存的运算效率矛盾
- 多处理器（或多核心）并发处理
- 对代码进行乱序执行（Out-Of-Order Execution）优化：充分利用处理器内部的运算单元
高速缓存（Cache）
直接问题：不同硬件的效率矛盾
CPU处理速度与内存读写速度相差几个数量级，导致CPU要等待缓慢的内存读写。
解决方案：高速缓存
加入一层读写速度尽可能接近处理器的高速缓存（Cache）来作为内存与处理器之间的缓冲：将运算需要的数据复制到缓存中，让运算能快速进行，当运算结束后再从缓存同步回内存之中。
引入的新问题：缓存一致性问题
在单处理器系统中，高速缓存并没有什么问题，然而在多处理器系统中，每个处理器都有独自的高速缓存，而它们又共享同一主内存。当多个处理器的运算任务都涉及同一块主内存区域时，将可能导致各自的缓存数据不一致，这正是物理计算机遇到的并发问题。
为了解决该问题，就需要各个处理器在访问缓存时遵循 缓存一致性协议。这类协议有MSI、MESI、MOSI、Dragon Protocol等。这里我们不再针对“缓存一致性协议”做展开，只要明白该协议是为了防止缓存数据不一致，而做的一些访问约定即可。
物理硬件和操作系统的内存模型
处理器的乱序执行（Out-Of-Order Execution）优化
为了使得处理器内部的运算单元能尽量被充分利用，处理器可能会对输入的代码进行乱序执行优化，处理器会在计算之后将乱序执行的结果重组，保证该结果与顺序执行的结果是一致的，但并不保证程序中各个语句计算的先后顺序与输入代码中的顺序一致。
CPU总是顺序的去内存中取指令，然后将其顺序的放入指令流水线。但是指令执行时的各种条件、指令与指令之间的相互影响，可能导致顺序放入流水线的指令，最终乱序执行完成。这就是所谓的顺序流入，乱序流出。
与处理器的乱序执行优化类似，Java虚拟机的即时编译器中也有类似的指令重排序优化。
编译器的“指令重排序”优化
既然提到了处理器的乱序执行优化，这里就再简单说一下编译器的指令重排序优化，因为这两个概念比较容易混淆。
从硬件结构上讲，指令重排序是指CPU采用了允许将多条指令不按程序规定的顺序分开发送给各相应电路单元处理。
并不是说指令任意重排，CPU需要能正确处理指令依赖情况以保证程序能得出正确的执行结果。譬如指令1把地址A中的值加10，指令2把地址A中的值乘以2，指令3把地址B中的值减去3，这时指令1和指令2是有依赖的，它们之间的顺序不能重排—— (A+10)*2 与 A*2+10 显然不相等，但指令3可以重排到指令1和2之前或者中间，只要保证CPU执行后面依赖到A、B值的操作时能获取到正确的A和B值即可。
“乱序执行”和“指令重排序”对比
| 概念 | 执行者 | 发生时期 | 内存中指令顺序是否真的变化 |
|---|---|---|---|
| 乱序执行 | 处理器(CPU) | 运行期 | 否 |
| 指令重排序 | 虚拟机编译器 | 编译期 | 是 |
Java内存模型
Java为什么要定义内存模型
这里提到的“内存模型”一词，可以理解为在特定的操作协议下，对特定的内存或高速缓存进行读写访问的过程抽象。不同架构的物理机器可以拥有不一样的内存模型。为了屏蔽各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的内存访问效果，Java虚拟机规范中试图定义一种Java内存模型。而在此之前，主流程序语言（如C/C++等）直接使用物理硬件和操作系统的内存模型，因此，会由于不同平台上内存模型的差异，有可能导致程序在一套平台上并发完全正常，而在另外一套平台上，并发访问却经常出错，因此在某些场景就必须针对不同的平台来编写程序。
Java内存模型
Java内存模型有以下规定：
- 所有的变量都存储在主内存（Main Memory）中
- 每条线程还有自己的工作内存（Working Memory），其中保存了被该线程使用到的变量的主内存副本拷贝
- 线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存中的变量
- 不同线程间无法直接访问对方工作内存中的变量， 线程间变量值的传递均需要通过主内存来完成
从更低层次上说，主内存就直接对应于物理硬件的内存，而为了获得更好的运行速度，虚拟机（甚至是操作系统本身的优化措施）会让工作内存优先存储于寄存器和高速缓存中，因为程序运行时主要访问读写的是工作内存。
所有变量都有副本拷贝吗？
假设访问一个10MB的对象，也要把它复制一份拷贝出来吗？显然不行，这个对象的引用、对象中某个在线程访问到的字段是有可能存在拷贝的，但不会有虚拟机实现成把整个对象拷贝一次。
volatile 变量也有工作内存的拷贝吗？
虽然volatile保证了多线程间变量的可见性，但它依然有工作内存的拷贝，只是由于它特殊的操作顺序性规定，所以看起来如同直接在主内存中读写访问一般。volatile 的特殊规则保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新。
内存间交互操作
关于主内存与工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存之类的实现细节，Java内存模型中定义了8种操作（lock、unlock、read、load、use、assign、store、wtite）及相关的规则限定，并要求这8种操作都具有原子性（但是对于64位的long和double型数据，特别定义了一条相对宽松的非原子性协定，后续再介绍）。
这8种内存访问操作及规则限定，再加上稍后要介绍的对volatile的一些特殊规定，就已经完全确定了Java程序中哪些内存访问操作在并发下是安全的。鉴于这些定义十分繁琐，这里不再做深入展开，下面介绍一个等效的判断原则——先行发生原则，用来确定一个访问在并发环境下是否安全。
先行发生原则
先行发生是Java内存模型中定义的两项操作之间偏序关系，如果说操作A先行发生于操作B，其实就是说在发生操作B之前，操作A产生的影响能被操作B观察到，“影响”包括修改了内存中共享变量的值、发送了消息、调用了方法等。这句话意味着什么呢？我们看如下伪代码：
// 以下操作在线程A中执行
i = 1;
// 以下操作在线程B中执行
j = i;
// 以下操作在线程C中执行
i = 2;
如果不通过某种手段明确3个操作之间的先行发生关系，那么最终 j 的值就很难确定，不具备多线程安全性。
“天然的”先行发生关系
以下是Java内存模型中“天然的”先行发生关系。如果两个操作之间的关系不在此列，并且无法从下列规则推导出来的话 ，它们就没有顺序性保障，虚拟机可以对它们随意地进行重排序。
- 程序次序规则：在一个线程内，按照程序代码顺序，写在前面的操作先行发生于写在后面的操作。准确地说，应该是控制流顺序，而非程序代码顺序，因为要考虑分支、循环等结构。
- 管程锁定规则：一个unlock操作先行发生于后面对同一个锁的lock操作。要注意是“同一个锁”，而“后面”是指时间上的先后顺序。
- volatile变量规则：对一个volatile变量的写操作先行发生于后面对这个变量的读操作，这里的“后面”同样指时间上的先后顺序。
- 线程启动规则：Thread对象的start()方法先行发生于此线程的每一个动作。
- 线程终止规则：线程中的所有操作都先行发生于对此线程的终止检测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值等手段检测到线程已经终止执行。
- 线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测到是否有中断发生。
- 对象终结规则：一个对象的初始化完成（构造函数的执行结束）先行发生于它的finalize()方法的开始。
- 传递性：如果操作A先行发生于操作B，操作B先行发生于操作C，那么操作A必定先行发生于操作C。
下面演示一下如何通过以上规则去判定操作间是否具备顺序性，对于读写共享变量的操作来说，就是线程是否安全，同时还可以感受一下“时间上的先后顺序”和“先行发生”之间有什么不同。
private int value = 0;
public void setValue(int value) {
this.value = value;
}
public int getValue() {
return value;
}
这是一组再普通不过的getter/setter方法，假设存在线程A和B，线程A先（时间上的先后）调用了“setValue(1)”，然后线程B调用了同一个对象的“getValue()”，那么线程B收到的返回值是什么？
我们依次分析一下先行发生原则中的各项规则：
- 两个方法的调用不在同一个线程 → 程序次序规则不适用；
- 没有同步块，自然就没有lock和unlock操作 → 管程锁定规则不适用；
- value变量没有被volatile修饰 → volatile变量规则不适用；
- 线程启动、终止、中断规则和对象终结规则也和这里完全没有关系；
- 没有任何一个适用的先行发生规则，所以传递性也无从谈起；
可见，尽管线程A在操作时间上先于线程B，但是无法确定线程B中“getValue()”方法的返回值，换句话说，这里的操作不是线程安全的。
那怎么修复这个问题呢？至少有两种比较简单的方案：
- 把getter/setter方法都定义为
synchronized方法，这样就可以套用管程锁定规则； - 把value定义为volatile变量，由于setter方法对value的修改不依赖value的原值，满足volatile关键字使用场景，因此可以套用volatile变量规则；
从上述例子，可以得出结论：一个操作“时间上的先发生”不代表这个操作会是“先行发生”，那如果一个操作“先行发生”是否就能推导出这个操作必定是“时间上的先发生”呢？很遗憾，也不成立，一个典型的例子就是“指令重排序”，请看下面的例子：
// 以下操作在同一个线程中执行
int i = 1;
int j = 2;
由于在同一个线程中，根据程序次序规则，“int i = 1”的操作先行发生于“int j = 2”，但是“int j = 2”的代码完全可能先被处理器执行，这并不影响先行发生原则的正确性，因为我们在这条线程之中没有办法感知到这点。
上面两个例子综合起来证明了一个结论：时间先后顺序与先行发生原则之间基本没有太大关系，所以我们衡量并发安全问题时不能受时间顺序干扰，一切必须以先行发生原则为准。
并发中的三大特性
其实Java内存模型就是围绕着在并发过程中如何处理原子性、可见性和有序性这3个特征来建立的，我们来看看哪些操作实现了这3个特性。
原子性
原子性是指一个操作或多个操作要么全部执行，且执行的过程不会被任何因素打断，要么就都不执行。线程切换会导致原子性问题。
基本数据类型的访问读写具备原子性
例外就是long和double的非原子性协定，不过目前各商用虚拟机几乎都选择把它们的读写作为原子操作来对待，开发者无须太在意
long和double的非原子性协定：
允许虚拟机将没有被volatile修饰的64位数据（long和double）的读写操作划分为两次32位的操作来进行，即允许虚拟机实现选择可以不保证64位数据类型的load、store、read和write这4个操作的原子性。
基于上述非原子性协定，如果有多个线程共享一个并未声明为volatile的long或double型变量，并且同时对其进行读取和修改操作，那么某些线程可能会读取到一个既非原值，也不是其他线程修改值的代表了“半个变量”的数值。但是这种现象非常罕见，Java内存模型虽然允许虚拟机不把64位数据类型的读写实现成原子操作，但还是“强烈建议”虚拟机这样实现。目前的商用java虚拟机也都选择将64位数据的读写操作实现为原子操作。所以在实际开发中，一般不需要把long和double型变量专门声明为volatile。
synchronized块之间的操作也具备原子性
可见性
可见性是指当一个线程修改了共享变量的值，其他线程能够立即得知这个修改。工作内存导致可见性问题。
以下关键字能实现可见性：
volatile关键字
volatile的特殊规则保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新。
synchronized关键字
同步块的可见性是由”对一个变量执行unlock操作之前，必须先把此变量同步回主内存中（执行store和write操作）“这条规则获得的（Java内存模型中定义的规则之一，本文没有展开）。
final关键字
被final修饰的字段在构造器中一旦初始化完成，并且构造器没有把”this“的引用传出去（this引用逃逸是一件很危险的事情，其他线程可能通过这个引用访问到”初始化了一半“的对象），那在其他线程中就能看见final字段的值。
如下面的代码所示，i 和 j 都具备可见性，他们无须同步就能被其他线程正确访问。
public static final int i;
public final int j;
static {
i = 0;
// do something
}
{
// 也可以选择在构造函数中初始化
j = 0;
// do something
}
有序性
Java中天然的有序性可以总结为一句话：如果在本线程内观察，所有的操作都是有序的；如果在一个线程中观察另一个线程，所有的操作都是无序的。前半句是指“线程内表现为串行的语义”（之所以用”表现为串行的语义“来描述，就是要告诉大家，它只是我们感知到的结果，但实际上cpu执行指令时很有可能是乱序的），后半句是指“指令重排序”（cpu只保证在一个线程内指令重排序不会影响最终结果，并不保证该线程内的指令重排序不会影响其他线程的运算结果）现象和“工作内存和主内存同步延迟”现象。编译器优化可能导致有序性问题。
Java提供了 volatile 和 synchronized 两个关键字来保证线程之间操作的有序性。
volatile
volatile本身就包含了禁止指令重排序的语义。
synchronized
它是由”一个变量在同一时刻只允许一条线程对其进行lock操作“这条规则获得的，这条规则决定了持有同一个锁的两个同步块只能串行地进入。
synchronized关键字在需要这3种特性时都可以作为一种解决方案，看起来很“万能”，但也间接的造就了它被滥用的局面，越“万能”的并发控制，通常会伴随着越大的性能影响。
volatile型变量的特殊规则
关键字volatile可以说是java提供的最轻量级的同步机制。当一个变量定义为volatile之后，它将具备以下两种特性：
- 保证此变量对所有线程的“可见性”，即一个线程修改了该变量的值，新值对于其他线程来说是可以立即得知的。
- 禁止指令重排序
关于volatile变量的可见性，经常会被误解，认为以下描述成立：volatile变量对所有线程是立即可见的，对volatile变量所有的写操作都能立刻反应到其他线程中，换句话说，volatile变量在各个线程中是一致的，所以基于volatile变量的运算在并发下是安全的。
这句话的论据部分并没有错，但是其论据并不能得出“基于volatile变量的运算在并发下是安全的”这个结论。volatile变量在各个线程的工作内存中不存在一致性问题（在各个线程的工作内存中，volatile变量也可以不一致，但由于每次使用之前都要先从主内存中刷新一次，执行引擎看不到不一致的情况，因此可以认为不存在一致性问题，你也可以理解为volatile会使得线程的工作内存“失效”），但是Java里的运算并非原子操作，导致volatile变量的运算在并发下一样是不安全的，我们可以通过下面的演示来说明：
/**
* Volatile变量自增运算测试
*/
public class VolatileTest {
private static volatile int race = 0;
private static final int THREADS_COUNT = 20;
public static void increase() {
race++;
}
public static void main(String[] args) {
Thread[] threads = new Thread[THREADS_COUNT];
for (int i = 0; i < THREADS_COUNT; i++) {
threads[i] = new Thread(new Runnable() {
@Override
public void run() {
for (int i = 0; i < 10000; i++) {
increase();
}
}
});
threads[i].start();
}
// 等待所有累加线程都结束
while (Thread.activeCount() > 1) {
Thread.yield();
}
System.out.println("race = " + race);
}
}
这段代码创建了20个线程，每个线程对 race 循环执行10000次自增操作，如果说”基于volatile变量的运算在并发下是安全的“，那么最终的结果 race 应该为200000。但实际运行后，每次得到的都会是一个小于200000的数字。
问题就出在 "race++ " 并非原子操作，我们用 javac 和 javap 反编译后可以得到其汇编指令，可以看到，race++ 实际上是由4条汇编指令构成的，事实上 volatile 只能保证 ”getstatic“执行时 race 的值是最新的，但执行后续的 ”加1“ 指令时，很可能其他线程已经修改了 race 的值，所以 ”putstatic“ 执行后就可能把一个较小的race值同步回主内存之中。
public static void increase();
Code:
Stack=2, Locals=0, Args_size=0
0: getstatic #13; //Field race:I
3: iconst_1
4: iadd
5: putstatic #13; //Field race:I
8: return
LineNumberTable:
line 14: 0
line 15: 8
这里使用汇编指令来解释指令重排序，仍然是不严谨的，因为指令重排序是机器级的优化操作，即使编译出来只有一条字汇编指令，也并不意味着执行这条指令就是一个原子操作。一条指令在解释执行时，解释器可能将要运行许多行代码才能实现它的语义，在编译执行时，一条汇编指令可能被转化成若干条本地机器码指令，此处使用 -XX:+PrintAssembly 参数输出反汇编来分析会更加严谨一些，只不过从汇编指令已经能看出问题了，考虑到阅读方便，直接用了汇编指令来分析。
由于 volatile 只能保证可见性，所以它只能在以下两种场景保证并发安全：
- 运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值。
- 变量不需要与其他的状态变量共同参与不变约束。
自增运算符的运算结果依赖变量的当前值，因此不能使用volatile确保并发安全。而类似 i < value 这样的表达式，即使 i 声明为 volatile ，也不能保证并发安全，因为 value 也可能在执行判断时发生变化。
而像下面这样的场景中，就很适合使用 volatile来控制并发：
volatile boolean shutdownRequested;
public void shutdown() {
shutdownRequested = true;
}
public void doWork() {
while(!shutdownRequested) {
// do stuff
}
}
当 shutdown() 方法被调用时，能保证所有线程中执行的 doWork() 方法都立即停下来。
使用 volatile 的第二个语义是禁止指令重排序优化。前面讲Java中天然的有序性可以总结为一句话：如果在本线程内观察，所有的操作都是有序的；如果在一个线程中观察另一个线程，所有的操作都是无序的。可能你还不是很理解，下面我们再通过一个例子来看看指令重排序如何干扰并发：
Map configOptions;
char[] configText;
// 此变量必须定义为 volatile
volatile boolean initialized = false;
// 假设以下代码在线程A中执行
// 模拟读取配置信息，当读取完成后将 initialized 设置为 true 以通知其他线程配置可用
configOptions = new HashMap();
configText = readConfigFile(fileName);
processConfigOptions(configText, configOptions);
initialized = true;
// 假设以下代码在线程B中执行
// 等待 initialized 为 true ，代表线程A已经把配置信息初始化完成
while(!initialized) {
sheep();
}
// 使用线程A中初始化好的配置信息
doSthWithConfig();
上述代码描述的场景很常见，只是我们在处理配置文件时一般不会出现并发而已。如果 initialized 没有使用 volatile 修饰，就可能会由于指令重排序优化，导致位于线程A最后的 ”initialized = true“ 被提前执行，这样在线程B中使用配置信息的代码就可能出现错误。
除了上述伪代码，我们再来看一个更加常见的实际场景。以下代码是一段标准的DCL（双锁检测）单例代码：
public class Singleton {
// 必须使用volatile修饰
private volatile static Singleton instance;
private Singleton() {}
public static Singleton getInstance() {
// 如果有任意一个线程执行到这里时发现instance已经指向了一个内存空间（此时可能由于指令重排序，导致Singleton对象还未初始化），
// 就会错误地拿到一个instance，它指向一个内存空间，但是该空间内还没有初始化完成的Singleton对象
if (instance == null) {
// 如果有其他线程正在这里等待锁，那么指令重排序也不会造成问题，因为在锁释放前这些线程只能等待，而synchronize块相当于一个原子操作
synchronized (Singleton.class) {
if (instance == null) {
// 关键就是这句赋值操作，它并非原子操作，可以拆分为：分配内存空间、初始化对象、将instance指向刚分配的内存空间
instance = new Singleton();
}
}
}
return instance;
}
}
有兴趣的话可以使用 javac 和 javap 命名查看这段代码的汇编指令，只要关注对 instance 赋值的这一行汇编指令即可，这里我们直接分析结果。
“instance = new Singleton();” 这一行代码，实际上可以拆分成以下指令：
memory = allocate(); // 1.分配对象的内存空间
ctorInstance(memory); // 2.初始化对象
instance = memory; // 3.令instance指向刚分配的内存空间
但由于指令重排序优化，cpu很可能是按照下面的顺序执行的：
memory = allocate(); // 1.分配对象的内存空间
instance = memory; // 3.令instance指向刚分配的内存空间（注意，此时对象还没有初始化）
ctorInstance(memory); // 2.初始化对象
在线程内观察，无论上述3条指令如何被重排序，最终 ”return instance“ 这条代码都会是最后执行的，此时1、2、3都执行结束了，在本线程内肯定能得到正确的 instance 对象。然而在其他线程中观察时，当赋值线程刚好执行了3，还没来得及执行2时（指令重排序后的case），其他线程就能得到一个还没初始化完成的instance（实际上就是一个空的内存地址）。
为什么使用volatile
解决了 volatile 的语义问题，再来思考一下在众多保障并发安全的工具中选用 volatile 的意义——它能让我们的代码比使用其他同步工具更快吗？在某些情况下，volatile 的同步机制的性能确实要优于锁（synchronized 关键字或 java.util.concurrent 包里的锁），但是由于虚拟机对锁实行的许多消除和优化，使得我们很难量化地认为 volatile 就会比 synchronized 快多少。如果让 volatile 与自己比较，那可以确定一个原则：volatile 变量读操作的性能消耗与普通变量几乎没有什么差别，但是写操作则可能会慢一些，因为它需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行。不过即便如此，大多数场景下 volatile 的总开销仍然要比锁低，我们在 volatile 与锁之间做选择的唯一依据仅仅是 volatile 的语义能否满足当前使用场景的需求。