1.并发程序幕后的故事
这些年，我们的CPU、内存、I/O设备都在不断迭代发展，都在朝着更快的方向努力。但是在这个快速发展的过程中，有一个核心矛盾一直存在，那就是这三者之间的速度差异。CPU和内存的速度差异可以描述为:CPU是天上一天，而内存是地上一年（假设CPU执行普通指令是一天，那么内存读写数据就需要一年）；内存和I/O设备速度的差异就更大了，内存是天上一天，而I/O读写是地上十年。
程序里大多数都要访问内存，有些甚至要访问I/O，根据木桶理论我们知道，一只木桶能装多少水取决于最短的那一块木板，而程序整体运行的效率取决于速度最慢的I/O设备。
为了合理利用CPU的高性能，合理的平衡这三者之间的之间的差异，计算机体系结构，操作系统和编译指令都做出了贡献，主要体现为:
- 1.CPU于内存之间加了高速缓存区，以平衡CPU与内存之间的速度差异。
- 2.操作系统增加了进程和线程，分时复用CPU，进而均衡CPU与I/O设备的速度差异
- 3.编译程序优化指令执行次序，使得缓存能够得到更加合理地利用
天下没有免费的午餐，我们的程序在默默享受着这些成果的同时，一些问题也随之而来。
2.安全性
什么是线程安全?
Java并发包创始人对线程安全是这样定义的:在多线程环境中，一个类（对象或者方法）能够始终保持正确的行为，那么这个类（对象或者方法）就是线程安全的。
那么怎样才能保证线程安全性呢？
- 1.栈封闭
所有的都在方法的内部申明，这些变量都属于栈封闭状态
- 2.无状态
没有任何成员变量的类，就叫做无状态的类
- 3.让类不可变
3.可见性问题
在单核时代，多有的线程都在一颗CPU上运行，那么保证内存和缓存之间的数据一致性容易得到解决。因为所有的线程都是在操作一个CPU的缓存，一个线程对缓存的读写，对另一个线程而言一定是可见的。例如下图所示，线程A和线程B同时操作缓存中变量V的值，线程A更新了变量V的值，那么当线程B读取线程V时，读到的数据一定是线程A更新过后的值。
然而，随着CPU的发展，如今已经是多核时代，每颗CPU都有自己的缓存，这时候CPU缓存和内存里的数据一致性没那么好解决了。当多个线程在不同的CPU缓存里操作数据时，如下图，线程A操作的是CPU-1里的缓存，而线程B操作得1是CPU-2里的缓存，如果线程A对CPU-1里的缓存数据V进行了更新操作，CPU-2缓存读取的数据V的值依旧是内存的，那么问题就来了，读写不同CPU的缓存数据的不同线程数据是不可见！
public class Test {
private long count = 0;
private void add10K() {
int idx = 0;
while(idx++ < 10000) {
count += 1;
}
}
public static long calc() {
final Test test = new Test();
// 创建两个线程，执行add()操作
Thread th1 = new Thread(()->{
test.add10K();
});
Thread th2 = new Thread(()->{
test.add10K();
});
// 启动两个线程
th1.start();
th2.start();
// 等待两个线程执行结束
th1.join();
th2.join();
return count;
}
}
直觉告诉我们应该是20000，因为在单线程里调用两次add10K()方法，count的值就是20000，但实际上calc()的执行结果是个10000到20000之间的随机数。为什么呢？
我们假设线程A和线程B同时开始执行，那么第一次都会将 count=0 读到各自的CPU缓存里，执行完 count+=1 之后，各自CPU缓存里的值都是1，同时写入内存后，我们会发现内存中是1，而不是我们期望的2。之后由于各自的CPU缓存里都有了count的值，两个线程都是基于CPU缓存里的 count 值来计算，所以导致最终count的值都是小于20000的。这就是缓存的可见性问题。
循环10000次count+=1操作如果改为循环1亿次，你会发现效果更明显，最终count的值接近1亿，而不是2亿。如果循环10000次，count的值接近20000，原因是两个线程不是同时启动的，有一个时差。
3.原子性问题
由于I/o太慢，早期的系统就发明了多进程，即使在单核CPU上我们依然可以一边听听音乐，一边撸代码，这就是多进程的功劳。
操作系统允许某个线程执行一段时间，例如50ms，过了50ms操作系统会切换到另一个线程（这个过程叫上下文切换），50ms叫做时间片。
在一个时间片内，如果一个进程进行一个IO操作，例如读个文件，这个时候该进程可以把自己标记为“休眠状态”并出让CPU的使用权，待文件读进内存，操作系统会把这个休眠的进程唤醒，唤醒后的进程就有机会重新获得CPU的使用权了。
这里的进程在等待IO时之所以会释放CPU使用权，是为了让CPU在这段等待时间里可以做别的事情，这样一来CPU的使用率就上来了；此外，如果这时有另外一个进程也读文件，读文件的操作就会排队，磁盘驱动在完成一个进程的读操作后，发现有排队的任务，就会立即启动下一个读操作，这样IO的使用率也上来了。
是不是很简单的逻辑？但是，虽然看似简单，支持多进程分时复用在操作系统的发展史上却具有里程碑意义，Unix就是因为解决了这个问题而名噪天下的。
早期的操作系统基于进程来调度CPU，不同进程间是不共享内存空间的，所以进程要做任务切换就要切换内存映射地址，而一个进程创建的所有线程，都是共享一个内存空间的，所以线程做任务切换成本就很低了。现代的操作系统都基于更轻量的线程来调度，现在我们提到的“任务切换”都是指“线程切换”。
Java并发程序都是基于多线程的，自然也会涉及到任务切换，也许你想不到，任务切换竟然也是并发编程里诡异Bug的源头之一。任务切换的时机大多数是在时间片结束的时候，我们现在基本都使用高级语言编程，高级语言里一条语句往往需要多条CPU指令完成，例如上面代码中的count += 1，至少需要三条CPU指令。
- 指令1：首先，需要把变量count从内存加载到CPU的寄存器；
- 指令2：之后，在寄存器中执行+1操作；
- 指令3：最后，将结果写入内存（缓存机制导致可能写入的是CPU缓存而不是内存）。
操作系统做任务切换，可以发生在任何一条CPU指令执行完，是的，是CPU指令，而不是高级语言里的一条语句。对于上面的三条指令来说，我们假设count=0，如果线程A在指令1执行完后做线程切换，线程A和线程B按照下图的序列执行，那么我们会发现两个线程都执行了count+=1的操作，但是得到的结果不是我们期望的2，而是1。
我们潜意识里面觉得count+=1这个操作是一个不可分割的整体，就像一个原子一样，线程的切换可以发生在count+=1之前，也可以发生在count+=1之后，但就是不会发生在中间。我们把一个或者多个操作在CPU执行的过程中不被中断的特性称为原子性。CPU能保证的原子操作是CPU指令级别的，而不是高级语言的操作符，这是违背我们直觉的地方。因此，很多时候我们需要在高级语言层面保证操作的原子性。
4.有序性问题
那并发编程里还有没有其他有违直觉容易导致诡异Bug的技术呢？有的，就是有序性。顾名思义，有序性指的是程序按照代码的先后顺序执行。编译器为了优化性能，有时候会改变程序中语句的先后顺序，例如程序中：“a=6；b=7；”编译器优化后可能变成“b=7；a=6；”，在这个例子中，编译器调整了语句的顺序，但是不影响程序的最终结果。不过有时候编译器及解释器的优化可能导致意想不到的Bug。
在Java领域一个经典的案例就是利用双重检查创建单例对象，例如下面的代码：在获取实例getInstance()的方法中，我们首先判断instance是否为空，如果为空，则锁定Singleton.class并再次检查instance是否为空，如果还为空则创建Singleton的一个实例。
public class Singleton {
static Singleton instance;
static Singleton getInstance(){
if (instance == null) {
synchronized(Singleton.class) {
if (instance == null)
instance = new Singleton();
}
}
return instance;
}
假设有两个线程A、B同时调用getInstance()方法，他们会同时发现 instance == null ，于是同时对Singleton.class加锁，此时JVM保证只有一个线程能够加锁成功（假设是线程A），另外一个线程则会处于等待状态（假设是线程B）；线程A会创建一个Singleton实例，之后释放锁，锁释放后，线程B被唤醒，线程B再次尝试加锁，此时是可以加锁成功的，加锁成功后，线程B检查 instance == null 时会发现，已经创建过Singleton实例了，所以线程B不会再创建一个Singleton实例。
这看上去一切都很完美，无懈可击，但实际上这个getInstance()方法并不完美。问题出在哪里呢？出在new操作上，我们以为的new操作应该是：
分配一块内存M； 在内存M上初始化Singleton对象； 然后M的地址赋值给instance变量。 但是实际上优化后的执行路径却是这样的：
分配一块内存M； 将M的地址赋值给instance变量； 最后在内存M上初始化Singleton对象。 优化后会导致什么问题呢？我们假设线程A先执行getInstance()方法，当执行完指令2时恰好发生了线程切换，切换到了线程B上；如果此时线程B也执行getInstance()方法，那么线程B在执行第一个判断时会发现 instance != null ，所以直接返回instance，而此时的instance是没有初始化过的，如果我们这个时候访问 instance 的成员变量就可能触发空指针异常。
总结
要写好并发程序，首先要知道并发程序的问题在哪里，只有确定了“靶子”，才有可能把问题解决，毕竟所有的解决方案都是针对问题的。并发程序经常出现的诡异问题看上去非常无厘头，但是深究的话，无外乎就是直觉欺骗了我们，只要我们能够深刻理解可见性、原子性、有序性在并发场景下的原理，很多并发Bug都是可以理解、可以诊断的。
在介绍可见性、原子性、有序性的时候，特意提到缓存导致的可见性问题，线程切换带来的原子性问题，编译优化带来的有序性问题，其实缓存、线程、编译优化的目的和我们写并发程序的目的是相同的，都是提高程序性能。但是技术在解决一个问题的同时，必然会带来另外一个问题，所以在采用一项技术的同时，一定要清楚它带来的问题是什么，以及如何规避。
