说到并发编程可能是很多开发者的梦魇，那么今天我们就揭开并发编程神秘的面纱
为什么出现并发编程？
可能我们研究并发编程出现的原因，需要我们对计算机原理有一定的了解，比如操作系统的cpu，内存等等都是什么东西。
看下图，我们的存储设备按照运行速度从快到慢排序方式依次是cpu，内存，磁盘。他们之间运行速度相差都是在100倍。所以对于一次计算机任务的运算，瓶颈自然在最慢的磁盘操作上，cpu永远会有空闲。
所以，为了提供高速cpu和内存的利用率，平衡三者的运算速度差异，计算机体系机构，操作系统，编译程序都为之做出了改变：
- cpu芯片上增加缓存（L1,L2,L3）,保存取于内存的数据块，来均衡与内存的运算速度
- 操作系统增加了进程，线程的分时复用cpu，最大程度的提高cpu的利用率，进而均衡cpu和磁盘设备速度差异
- 编译程序优化指令执行次序，使得缓存能够得到更加合理地利用
也正是这些优化，导致了并发场景下的一些诡异问题。
线程切换导致的原子性问题
对于操作系统来说，早期就能支持多进程的方式来解决磁盘io慢的问题，在单核的cpu上我们也能一边听歌一边写bug。
在多进程运行的场景下，每个进程运行都需要申请到cpu分配的时间片，这个时间片就是操作系统允许进程运行的一小段时间，比如50毫秒，50毫秒之后操作系统将会选取另外一个进程来运行（任务切换）
当进程在等待io时将cpu让出来，cpu将会去做别的事情，这样cpu的使用率将会大大提高了。
操作系统中，不同进程的内存空间是不同的，对于进程的切换，将会设计到进程的内存映射的切换。而进程创建的所有线程，都是共享进程的内存空间的，所以通过线程来进行任务切换的代价就会很低。
Java并发程序就是通过线程切换实现的。Java是一门高级编程语言，高级语言中一条语句一般需要多条cpu指令才能完成，比如count+=1，至少需要三条CPU指令。
那么，这种非原子性操作，在执行过程中可能会遇到线程切换，那么就会导致非原子性操作执行到一半，切换到另外一个线程执行，从而导致脏数据的产生。
如果count+=1是一个原子性的操作，线程的切换要么是在count+=1之前，要么是在count+=1之后，就不会产生并发问题了。
从单核时代到多核时代带来的可见性问题
早期的计算机只有一个CPU，如果是多个线程都在这一个CPU上运行，CPU缓存和内存数据的一致性在每次线程切换时都会被同步，所以一个线程对于缓存的写对于另外一个线程的读一定是可见的。
但是随着计算机不断的发展，硬件层面，多核时代下，一个计算机拥有多个CPU，并且每个CPU都会有自己的缓存。此时，多个线程同时运行，处于不同CPU上的操作，可能修改是CPU的缓存，而没有真正同步到内存中。
如上图，线程A和线程B想要同时操作同一块内存。但是线程A在CPU-1上修改的是CPU-1的缓存，对于CPU-2是不可见的。与此同时，CPU-2也在操作这块内存，但是他修改的是CPU-2的缓存。此次如果CPU同步缓存至内存中，必然会内存值不准确的情况。这种就是因为多核情况下，CPU缓存的不可见性导致的并发问题。
编译优化同样会有并发问题
Java语言中比较出名的DCL，就是为编译优化的指令重排序导致的并发问题：
例如下面的代码：
public class Singleton {
static Singleton instance;
static Singleton getInstance(){
if (instance == null) {
synchronized(Singleton.class) {
if (instance == null)
instance = new Singleton();
}
}
return instance;
}
}
new Singleton()操作对于CPU指令会有三个操作：
- 分配一块内存
- 在内存上初始化Singleton对象
- 将内存地址赋值给instance变量
但是如果经过指令重排序的优化：
- 分配一块内存
- 将内存地址赋值给instance变量
- 在内存上初始化Singleton对象
线程A执行时，先给instance变量分配了内存地址，后初始化的对象，那么就很雪崩；线程B执行instance == null判断时，将会返回一个未初始化的instance，我们再调用insatance的成员变量时将会触发空指针异常。
总结
综观上述的三个问题，只要我们能够深刻理解可见性、原子性、有序性在并发场景下的原理，并发bug还是能够避免的。其实缓存、线程、编译优化的目的和我们写并发程序的目的是相同的，都是为了提供程序的性能
