编程语言
首页 > 编程语言> > 并发编程Bug起源:可见性、有序性和原子性问题

并发编程Bug起源:可见性、有序性和原子性问题

作者：互联网

以前古老的DOS操作系统，是单进行的系统。系统每次只能做一件事情，完成了一个任务才能继续下一个任务。每次只能做一件事情，比如在听歌的时候不能打开网页。所有的任务操作都按照串行的方式依次执行。

这类服务器缺点也很明显，等待操作的过长，无法同时操作多个任务，执行效率很差。

现在的操作系统都是多任务的操作系统，比如听歌的时候可以做打开网页，还能打开微信和朋友聊天。这几个任务可以同时进行，大大增加执行效率。

并发提高效率

一个完整服务器，都有CPU、内存、IO,三者之间的运行速度存在明显的差异:

CPU -> 内存 -> SSD -> 磁盘 -> 网络
纳秒 -> 微秒 -> 毫秒 -> 毫秒 -> 秒

程序中大部分的语句都要访问内存，有些还要访问的IO读写。为了合理的利用CPU的高性能，高效的平衡三者的速度差异，操作系统、编译器主要做了以下改进：

做了以上操作之后，CPU读取或者修改数据之后，将数据缓存在CPU缓存中，CPU不需要每次都从内存中获取数据，极大的提高了CPU的运行速度。多线程是将时间段切成一个个小段，多个线程在上下文切换中，执行完任务，而不用等前面的线程都执行完毕之后再执行。比如做一个计算，CPU耗时1纳秒,而从内存读取数据要1微秒，没有多线程的话,N个线程要耗时N微秒，此时CPU高效性就无法体现出来。有了多线程之后，操作系统将CPU时间段切成一个一个小段，多线程上下文切换，线程执行计算操作，无需等待内存读取操作。

虽然并发可以提高程序的运行效率，但是凡事有利也有弊，并发程序也有很多诡异的bug,根源有以下几个原因。

缓存导致可见性问题

一个线程对共享变量的修改，另外线程能立刻看到，称为可见性。

在单核时代，所有的线程都是在同一个CPU上运行，所有的线程都是操作同一个线程的CPU缓存，一个线程修改缓存，对另外一个线程来说一定是可见的。比如在下图中，线程A和线程B都是操作同一个CPU缓存，所以线程A更新了变量V的值，线程B再访问变量V的值，获取的一定是V的最新值。所以变量V对线程都是可见的。

在多核CPU下，每个CPU都有自己的缓存。当多个线程执行在不同的CPU时，这些线程的操作也是在对应的CPU缓存上。这时候就会出现问题了，在下图中，线程A运行在CPU_1上，首先从CPU_1缓存获取变量V，获取不到就获取内存的值，然后操作变量V。线程B也是同样的方式在CPU_2缓存中获取变量V。

线程A操作的是CPU_1的缓存，线程B操作的是CPU_2的缓存，此时线程A对变量V的操作对于线程B是不可见的。多核CPU一方面提高了运行速度，但是另一方面也可能会造成线程不安全的问题。

下面使用一段代码来测试多核场景下的可见性。首先创建一个累加的方法add10k方法，循环10000次count+=1的操作。然后在test方法里面创建两个线程，每个线程都调用add10k方法，结果是多少呢？

public class VisibilityTest {

	private  static int count = 0;

	private void add10k() {
		int index = 0;
		while (index++ < 10000) {
			count += 1;
		}
	}

	@Test
	public void test() throws InterruptedException {
		VisibilityTest test = new VisibilityTest();
		Thread thread1 = new Thread(() -> test.add10k());
		Thread thread2 = new Thread(() -> test.add10k());
		// 启动两个线程
		thread1.start();
		thread2.start();
		// 等待两个线程执行结束
		thread1.join();
		thread2.join();
		System.out.println(count);
	}
}

按照直觉来说结果是20000,因为在每个线程累加10000,两个线程就是20000。但是实际结果是介于10000~20000的之间，每次执行结果都是这个范围内的随机数。

因为线程A和线程B同时开始执行，第一次都会将count=0缓存到自己的CPU缓存中，执行完count += 1之后，写入自己对应的CPU缓存中，同时写入内存中，此时内存中的数是1，而不是期望的2。之后CPU再取到自己的CPU缓存再进行计算，最后计算出来的count值都是小于20000,这就是缓存的可见性问题。

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

上面提到，由于CPU、内存、IO之间的速度存在很大的差异，在单进程系统中，需要等速度最慢的IO操作完成之后，才能接着完成下一个任务，CPU的高性能也无法体现出来。但操作系统有了多进程之后，操作系统将CPU切成一个一个小片段，在不同的时间片段内执行不同的进程的，而不需要等待速度慢的IO操作，在单核或者多核的CPU上可以一边的听歌，一边的聊天。

操作系统将时间切成很小片，比例20毫秒,开始的20毫秒执行一个进程，下一个20毫秒切换执行另外一个线程，20毫秒成为时间片,如下图所示：

线程A和线程B来回的切换任务。

如果一个进行IO操作，例如读取文件，这个时候该进程就把自己标记为休眠状态并让出CPU的使用权，等完成IO操作之后，又需要使用CPU时又会把休眠的进程唤醒，唤醒的进程就可以等待CPU的调用了。让出CPU的使用权之后，CPU就可以对其他进程进行操作，这样CPU的使用率就提高上了，系统整体的运行速度也快了很多。

并发程序大多数都是基于多线程的，也会涉及到线程上下文的切换，线程的切换都是在很短的时间片段内完成的。比如上面代码中count += 1虽然有一行语句，但这里面就有三条CPU指令。

任何一条CPU指令都可能发生线程切换。如果线程A在指令1执行完后做线程切换，线程A和线程B按照下图顺序执行，那么我们会发现两个线程都执行count += 1的操作，但是最后结果却是1，而不是2。

编译优化带来的有序性问题

有序性是指程序按照代码的先后顺序执行，编译器为了优化性能，在不影响程序的最终结果的情况下，编译器调整了语句的先后顺序，比如程序中：

a = 2;
b = 5;

编译器优化后可能变成:

b = 5;
a = 2;

虽然不影响程序的最后结果，但是也会引起一些意想不到的BUG。

在Java中一个常见的例子就是利用双重检验创建单例对象，例如下面的代码：


public class Singleton {
  static Singleton instance;
  static Singleton getInstance(){
    if (instance == null) {
      synchronized(Singleton.class) {
        if (instance == null)
          instance = new Singleton();
        }
    }
    return instance;
  }
}

在获取实例getInstance方法中，首先判断instance是否为空，如果为空，则锁定Singleton.class并再次检查instance是否为空，如果还为空就创建一个Singleton实例。

假设两个线程，线程A和线程B同时调用getInstance方法。此时instance == null，同时对Singleton.class加锁，JVM保证只有一个线程能加锁成功，假设是线程A加锁成功，另一个线程就会处于等待状态，线程A会创建一个实例，然后释放锁，线程B被唤醒，再次尝试加锁，此时成功加锁，而此时instance != null,已经创建过实例，所以线程B就不会创建实例了。

看起来没有什么问题，但实际上也有可能问题出现在new操作上，本来new操作应该是：

但实际优化后的执行顺序却是如下：

优化之后会发生什么问题呢？首先假设线程A先执行getInstance方法，也就是先执行new操作，当执行完指令2时发生了线程切换，切换到线程B上，此时线程B执行getInstance方法，执行判断时会发现instance != null,所以就返回instance，而此时的instance是没有初始化的，如果这时访问instance就可能会触发空指针异常。

总结

操作系统进入多核、多进程、多线程时代，这些升级会很大的提高程序的执行效率，但同时也会引发可见性、原子性、有序性问题。

开始学习并发，经常会看到volatile、synchronized等并发关键字，而了解并发编程的有序性、原子性、可见性等问题，就能更好的理解并发场景下的原理。

参考

可见性、原子性和有序性问题：并发编程Bug的源头

标签：缓存,编程,CPU,instance,线程,内存,有序性,执行,Bug
来源： https://www.cnblogs.com/jeremylai7/p/16644934.html