并发编程——bug的源头：可见性，原子性和有序性问题

目录

并发问题产生的背景：

一、缓存会导致可见性问题：

二、编译优化带来的有序性：

三、线程切换带来的原子性问题：

并发问题产生的背景：

由于 CPU，内存 和 IO 三者的速度差异巨大，并且程序整体性能取决于最慢的操作—读写IO设备。所以需要通过某些方式来平衡这三者的速度差异，合理的利用CPU，从而提高程序性能；主要有以下三个方法：

• CPU增加了缓存，以均衡与内存的速度差异；
• 编译优化：优化程序指令执行次序，使得缓存能够得到更加合理的利用。
• 操作系统增加了进程，以分时复用CPU，进而均衡CPU与IO设备的速度差异；

以上方法在有效提高程序性能的同时，也会导致很多诡异bug

一、缓存会导致可见性问题：（解决问题的方法）

可见性：指的是一个线程对于共享变量的修改，对于另一个线程是可见的。
单核场景下，多线程操作的都是一块缓存，一个线程对于共享变量的修改，对于另一个线程是可见的。
多核场景下，多线程间操作的是不同CPU的缓存，线程A操作的缓存A，线程B操作的是缓存B，线程A在缓存A中对于共享变量的操作对于访问缓存B的线程B就是不可见的。如代码中两个线程对于count的修改就是不可可见的，并且都可以将自己缓存中的数据写入内存。起初 缓存中的count都等于0（线程A将count=0读入缓存，及时他进行了加1操作，然后缓存A中的count=1，但是线程B访问的缓存B的count只可以看到并读取内存中的count=0），然后各自线程对其进行+1操作，最后会分别将count 等于写入内存。

二、编译优化带来的有序性：（解决问题的方法）

编译优化是会为了优化性能而改变 高级语言的执行顺序（使其并不是按照你编写的顺序执行）。
例如经典的 利用双重检查创建单例对象 

假设有两个线程A和B同时调用getInstantce()方法。目前instantce是null，于是会给Singleton.class加锁，JVM会保证只有一个线程加锁成功。假设A成功加锁，那么线程B只能等待，当想成A创建了一个Singleton实例。释放锁，线程B进行加锁，这时候他发现instantce已经不为空了，则直接返回。 但是其中的new操作会出现由于编译优化而造成的bug。
我们认为的new操作是：
1、分配一块内存M
2、在内存M上初始化对象
3、返回内存的地址并赋值给变量instance
但是这三步是可以进行编译顺序优化后可能是 1,3,2的形式。如果在3执行完以后发生了线程切换，那么此时的instance所指向的地址的内容时空，从而导致其他线程访问该变量的时候会造成空指针。

三、线程切换带来的原子性问题：（解决问题的方法）

原子性：指的是一个或者多个操作在CPU执行过程中不被中断的的特性称为原子性。
由于IO太慢，操作系统发明了多线程（分时复用CPU），使得我们同事可以使用电脑进行多项任务。操作系统允许一个进行执行一小段时间，例如50毫秒，这个50毫秒叫做时间片。在一个时间片内，如果该进行进行一个IO操作，暂时不使用CPU，就会将自己标记为“休眠状态”并出让CPU使用权，待IO操作完成，在唤醒CPU。来增加CPU的使用率。
由于线程公用内存空间，所以线程切换的成本低于进程切换，java的并发程序都是基于多线程的。
多线程就需要线程切换，会带来原子性问题，是因为线程切换并不是发生在高级语言某一条执行完成后，而是会发生在任意一条CPU指令之后，而一条高级语言可能包括多条CPU指令。
例如：以上java 代码中的 count += 1，其实需要三条CPU指令才可以执行完成。
           1、将变量count从内存（或者缓存）中加载到CPU的寄存器
           2、在寄存器中执行+1操作
           3、将寄存器中的结果写入内存（缓存）
线程切换会发生在三条指令任意一条执行结束的时候。从而导致最终内存中结果是1 而不是期待的2。

 

参考文章