本文从计算机系统层面来讲述在提升性能的过程中,引发的一系列问题。读完本文你将get到并发编程过程中的原子性,可见性,有序性三大问题的来源。
随着硬件发展速度的放缓,摩尔定律已经不在生效,各个硬件似乎已经到了瓶颈;然而随着互联网的普及,网民数量不断增加,对系统的性能带来了巨大的挑战。因此我们要通过各种方式来压榨硬件的性能,从而提高系统的性能进而提升用户体验,提升企业的竞争力。
由于CPU,内存,IO三者之间速度差异,为了提高系统性能,计算机系统对这三者速度进行平衡。
- CPU 增加了缓存,以均衡与内存的速度差异;
- 操作系统增加了进程、线程,以分时复用 CPU,进而均衡 CPU 与 I/O 设备的速度差异;
- 编译程序优化指令执行次序,使得缓存能够得到更加合理地利用。
缓存导致得可见性的问题
一个线程对共享变量的修改,另外一个线程能够立刻看到,我们称为可见性。
多核时代,每颗 CPU 都有自己的缓存,这时 CPU 缓存与内存的数据一致性就没那么容易解决了,当多个线程在不同的 CPU 上执行时,这些线程操作的是不同的 CPU 缓存。
线程切换带来的原子性问题
由于IO和cpu执行速度的差别巨大,所以在早期操作系统中就发明的多线程,即使在单核的cpu上我们也可以一遍听着歌,一边写着bug,这就是多线程。
早期操作系统基于进程来调度cpu, 不同进程间是不共享内存空间的,所以进程要做任务切换要切换内存映射地址,而一个进程创建的所有线程都是共享一个内存空间,所以线程做任务切换成本很低。现代操作系统都基于更轻量级的线程来调度,现在我们提到的“任务切换”都是指“线程切换”。
因为式单核cpu,所以同一时刻只能执行一个任务,所以多线程通常使用抢占的方式来获取操作系统的时间片。
Java的并发编程中都是基于多线程,线程的切换时机通常在一条cpu指令执行完毕之后,而Java作为一门高级编程语言,通常一条语句可能由多个cpu指令来完成。例如:count += 1, 至少需要三条指令。
- 指令1:首先,需要把变量count从该内存加载到cpu的寄存器
- 指令2:之后,在寄存器中执行+1操作
指令3: 最后,将结果写入内存(忽略缓存机制)
假设count = 0, 有2个线程同时执行count+=1这段代码。线程A执行完指令1将count = 0加载到cpu寄存器,进行了任务切换到了线程B执行,线程B执行完之后将count = 1写入到内存,然后再切换到线程A执行,此时线程A获取寄存器中的count=0进行+1操作得到结果也是1,所以最终内存中的count = 1,而我们所期望的是2.CPU层面的原子操作仅仅是在指令级别的,既一条cpu指令不可中断。在高级语言中,我们为了避免以上情况发生,我们把一个或多个操作在cpu执行过程中不被中断的特性称为原子性。
编译优化带来的有序性问题
为了提高程序的执行效率,编译器有时会在编译过程中对程序的进行优化,从而改变程序的执行顺序。如程序“a = 4; b = 5”,在优化后执行顺序可能变成“b = 5; a = 4”。通常进行一项优化过程中可能会带来另一项问题,改变程序的执行顺序通常也会导致让人意想不到的bug。
Java领域中一个经典的案例就是利用双重检查创建单例对象,代码如下:在获取实例getInstance()方法中,我们首先判断instance是否为空,如果为空则锁住Singleton.class对象并再次检查instance是否为空,如果仍然为空则创建Singleton的一个实例。
public class Singleton {
static Singleton instance;
/**
* 获取Singleton对象
*/
public 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 实例。
以上过程仅仅是我们的理想情况下,但是实际过程中往往会创建多次Singleton实例。原因是创建一个对象需要多条cpu指令,且编译器可能对这几条指令进行了排序。在执行new语句创建一个对象时,通常会包含一下三个步骤(此处进行了简化,实际实现过程会比此过程复杂):
- 在堆内存为对象分配一块内存M
- 在内存M区域进行Singleton对象的初始化
- 将内存M地址赋值给instance变量。
但是实际优化后的执行顺序可能时以下这种情况: - 在堆内存为对象分配一块内存M
- 将内存M地址赋值给instance变量。
- 在内存M区域进行Singleton对象的初始化
假设A,B线程同时执行到了getInstance()方法,线程A执行完instance = $M(将内存M地址赋值给instance变量,但是未将对象进行初始化)后切换到B线程,当B线程执行到instance == null时,由于instance已经指向了内存M的地址,所以会返回false,直接返回instance,如果我们这是访问instance中的成员变量或者方法时就可能会出现NullPointException。
总结
在操作系统平衡CPU,内存,IO三者速度差异过程中进行了一系列的优化。
- CPU 增加了缓存,以均衡与内存的速度差异;
- 操作系统增加了进程、线程,以分时复用 CPU,进而均衡 CPU 与 I/O 设备的速度差异;
- 编译程序优化指令执行次序,使得缓存能够得到更加合理地利用。
这三个不同方面的优化也带来了可见性,原子性,有序性等问题,他们通常是并发程序的bug的源头。
笔者的个人博客网站