因为现代计算机中CPU、内存、I/O操作存在性能差异问题,而一个程序的完整执行往往需要CPU、内存、I/O操作共同完成;例如进行I/O操作时,此时CPU就是空闲状态,浪费其性能,所以需要通过并发程序来提升硬件设备的使用率,提高程序性能。
bug源头一:缓存导致的可见性问题
现代计算机多核CPU都是标配,普通个人电脑4核、8核都很常见,更不用现代服务器的16核、32核等。因为每个CPU都有自己的高速缓存(1、2、3级缓存),这就会导致我们的线程在处理共享变量时,因为操作的数据在各自CPU的高速缓存中,导致可见性问题。
public class Test {
private long count = 0;
private void add10K() {
int idx = 0;
while (idx++ < 10000) {
count += 1;
}
}
public static void main(String[] args) throws InterruptedException {
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();
System.out.println(test.count);
}
}
如上代码所示:当我们有两个线程分别调用add10K()方法时,最后的count值总是小于20000;因为在多核CPU下,每个线程可能操作的都是自己CPU的高速缓存,导致最后的数据小于2000次。
Bug源头二——编译导致的指令重排序
有序性指的是程序按照代码的先后顺序执行,但是因为编译器的优化,代码的真实执行顺序,并不一定是我们写代码的顺序,而指令重排就会导致一定的问题,例如单例模式中的双重检查创建单例对象,就是因为指令重排优化导致问题。如下代码所示
public class Singleton {
static Singleton instance;
static Singleton getInstance(){
if (instance == null) {
synchronized(Singleton.class) {
if (instance == null)
instance = new Singleton();
}
}
return instance;
}
}
在j我们认为的new一个对象是如下步骤:
- 分配一块内存 M;
- 在内存 M 上初始化 Singleton 对象;
- 然后 M 的地址赋值给 instance 变量。
实际执行流程如下
- 分配一块内存 M;
- 将 M 的地址赋值给 instance 变量
- 最后在内存 M 上初始化 Singleton 对象
导致的问题就是:假设,现在有两个线程A,B线程执行到了new
Singleton()方法的第二部,将M的地址赋值给instance变量;此时发生了CPU切换B线程执行的是第一个null值判断,此时instance不为null,但此时内存上还未初始化对象,这时就可能发生空指针问题。
Java内存模型
java内存模式是java语言提出的规范,是用来描述多线程间的特性,描述了多线程程序的合法行为,即为多线程程序定义的一套规则;规范了 JVM 如何提供按需禁用缓存和编译优化的方法。也就是帮我们解决了缓存问题和指令优化导致的并发问题。
volatile关键字的作用
- 使用volatile修饰的变量,对这个变量的读写,不能使用 CPU 缓存,必须从内存中读取或者写入
- 对volatile变量相关的指令不做重排操作。
Happens-Before 规则:表示前面的操作一定是对后面的操作是可见的;Happens-Before 约束了编译器的优化行为,虽允许编译器优化,但是要求编译器优化后一定遵守 Happens-Before 规则。
- 程序顺序原则:一个线程内保证语义的串行化。
- volatile规则:volatile变量的写,先发生于读,这保证了volatile变量的可见性。
- 锁规则:解锁(unlock)必然发生在随后的加锁(lock)前。
- 传递性:A先于B,B先于C,那么A必然先于C
- 线程的start()方法先于它的每一个动作
- 线程的所有操作先于线程的终结(Thread.join())
- 线程的中断(interrupt())先于被中断线程的代码
- 对象的构造函数执行、结束先于finalize()方法。
Bug源头 —— 线程切换带来的原子性问题
现代CPU的设计,对于CPU的使用都是采用时间片的方式,假设这个时间为50毫秒,每个线程在使用50毫秒后,就会自动让出CPU使用,别的线程就可重新获取CPU使用权,而往往我们写的程序需要多个CPU指令在能完成,这个时候我们的操作就不是原子性的,在发生CPU切换时就会出现问题;例如在java中count++操作,在CPU层面就是非原子性的,在CPU中需要3步才能完成这个操作:
- 需要把变量 count 从内存加载到 CPU 的寄存器;
- 在寄存器中执行 +1 操作;
- 将结果写入内存(缓存机制导致可能写入的是 CPU 缓存而不是内存)
而CPU的切换可能发生在上述步骤中的任意一步中,这就会导致每个CPU读到的值就是所谓的“脏数据”
锁
原子性的源头就是线程切换,这个时候对于共享资源,我们就需要做到“同一时刻只有一个线程执行”,这个就称为互斥。我们把一段需要互斥执行的代码称为临界区。
在java中提供了很多关于锁实现的方式,例如synchronized关键字、ReenLock等实现,其根本目的就是为了保证,代码临界区的原子性。