并发编程理论_风舞红叶的博客-爱代码爱编程
CPU、内存、I/O 设备,有一个核心矛盾就是这三者的速度差异。
为了合理利用 CPU 的高性能,平衡这三者的速度差异:
1、CPU 增加了缓存,以均衡与内存的速度差异;
2、操作系统增加了进程、线程,以分时复用 CPU,进而均衡 CPU 与 I/O 设备的速度差异;
3、编译程序优化指令执行次序,使得缓存能够得到更加合理地利用。
缓存导致的可见性问题
多核时代,线程 A 操作的是 CPU-1 上的缓存,而线程 B 操作的是 CPU-2 上的缓存,这个时候线程 A 对变量 V 的操作对于线程 B 而言就不具备可见性了。
线程切换带来的原子性问题
任务切换的时机大多数是在时间片结束的时候,我们现在基本都使用高级语言编程,高级语言里一条语句往往需要多条 CPU 指令完成。count += 1,至少需要三条 CPU 指令:
指令 1:首先,需要把变量 count 从内存加载到 CPU 的寄存器;
指令 2:之后,在寄存器中执行 +1 操作;
指令 3:最后,将结果写入内存(缓存机制导致可能写入的是 CPU 缓存而不是内存)。
操作系统做任务切换,可以发生在任何一条CPU 指令执行完。
假设 count=0,如果线程 A 在指令 1 执行完后做线程切换,线程 A 和线程 B 按照下图的序列执行,那么我们会发现两个线程都执行了 count+=1 的操作,但是得到的结果不是我们期望的 2,而是 1。
把一个或者多个操作在 CPU 执行的过程中不被中断的特性称为原子性。CPU 能保证的原子操作是 CPU 指令级别的,而不是高级语言的操作符。因此,很多时候需要在高级语言层面保证操作的原子性。
编译优化带来的有序性问题
编译器为了优化性能,有时候会改变程序中语句的先后顺序
Java 领域一个经典的案例就是利用双重检查创建单例对象,代码:在获取实例 getInstance() 的方法中,我们首先判断 instance 是否为空,如果为空,则锁定 Singleton.class 并再次检查 instance
是否为空,如果还为空则创建 Singleton 的一个实例。
public class Singleton {
public static Singleton instance;
private Singleton() {
}
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null)
instance = new Singleton();
}
}
return instance;
}
}
这个 getInstance() 方法并不完美。问题出在 new 操作上,我们以为的 new 操作应该是:
1、分配一块内存 M;
2、在内存 M 上初始化 Singleton 对象;
3、然后 M 的地址赋值给 instance 变量。
实际上优化后的执行路径却是这样的:
1、分配一块内存 M;
2、将 M 的地址赋值给 instance 变量;
3、最后在内存 M 上初始化 Singleton 对象。
假设线程 A 先执行 getInstance() 方法,当执行完指令 2 时恰好发生了线程切换,切换到了线程 B 上;如果此时线程 B 也执行 getInstance() 方法,那么线程 B 在执行第一个判断时会发现 instance !=
null ,所以直接返回 instance,而此时的 instance 是没有初始化过的,如果我们这个时候访问 instance 的成员变量就可能触发空指针异常。
Java解决可见性和有序性问题
导致可见性的原因是缓存,导致有序性的原因是编译优化,那解决可见性、有序性合理的方案应该是按需禁用缓存以及编译优化,指按照程序员的要求来禁用。
Java 内存模型规范了 JVM 如何提供按需禁用缓存和编译优化的方法。这些方法包括 volatile、synchronized 和 final 三个关键字,以及六项 Happens-Before 规则。
volatile
volatile 关键字并不是 Java 语言(禁用缓存以及编译优化)的特产,古老的 C 语言里也有,它最原始的意义就是禁用 CPU 缓存。
声明一个 volatile 变量 volatile int x = 0,它表达的是:告诉编译器,对这个变量的读写,不能使用 CPU 缓存,必须从内存中读取或者写入。
Happens-Before 规则
在 Java 语言里面,Happens-Before 的语义本质上是一种可见性,A Happens-Before B 意味着 A 事件对 B 事件来说是可见的,无论 A 事件和 B 事件是否发生在同一个线程里。
Happens-Before 要表达的是:前面一个操作的结果对后续操作是可见的。Happens-Before 约束了编译器的优化行为,虽允许编译器优化,但是要求编译器优化后一定遵守 Happens-Before 规则。
class VolatileExample {
int x = 0;
volatile boolean v = false;
public void writer() {
x = 42;
v = true;
}
public void reader() {
if (v == true) {
// 这里 x 会是多少呢?
// 这个要看 Java 的版本,如果在低于 1.5 版本上运行,x 可能是 42,也有可能是 0;如果在 1.5 以上的版本上运行,x 就是等于 42。Java 内存模型在 1.5 版本对 volatile 语义进行了增强(Happens-Before 传递性)
}
}
}
-
1、程序的顺序性规则
在一个线程中,按照程序顺序,前面的操作 Happens-Before 于后续的任意操作
-
2、volatile 变量规则
对一个 volatile 变量的写操作, Happens-Before 于后续对这个 volatile 变量的读操作。
-
3、传递性
如果 A Happens-Before B,且 B Happens-Before C,那么 A Happens-Before C
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zfAddSPJ-1664763368864)(pic/传递性规则.png)]1、“x=42” Happens-Before 写变量 “v=true” ,这是 程序的顺序性规则;
2、写变量“v=true” Happens-Before 读变量 “v=true”,这是volatile 变量规则;
3、再根据传递性规则,得到结果:“x=42” Happens-Before 读变量“v=true”。如果线程 B 读到了“v=true”,那么线程 A 设置的“x=42”对线程 B 是可见的。(这就是 1.5 版本对 volatile 语义的增强)
-
4、管程中锁的规则
一个锁的解锁 Happens-Before 于后续对这个锁的加锁
管程是一种通用的同步原语,在 Java 中指的就是 synchronized,synchronized 是 Java 里对管程的实现。
管程中的锁在 Java 里是隐式实现的,例如下面的代码,在进入同步块之前,会自动加锁,而在代码块执行完会自动释放锁,加锁以及释放锁都是编译器帮我们实现的。synchronized (this) { // 此处自动加锁 // x 是共享变量, 初始值 =10 if (this.x < 12) { this.x = 12; } } // 此处自动解锁
假设 x 的初始值是 10,线程 A 执行完代码块后 x 的值会变成 12(执行完自动释放锁),线程 B 进入代码块时,能够看到线程 A 对 x 的写操作,也就是线程 B 能够看到 x==12。
-
5、线程 start() 规则
主线程 A 启动子线程 B 后,子线程 B 能够看到主线程在启动子线程 B 前的操作。所谓的“看到”,指的是对共享变量的操作。
// 在线程 A 中启动线程 B,那么该 start() 操作 Happens-Before 于线程 B 中的任意操作。 Thread B = new Thread(()->{ // 主线程调用 B.start() 之前 // 所有对共享变量的修改,此处皆可见 // 此例中,var==77 }); // 此处对共享变量 var 修改 var = 77; // 主线程启动子线程 B.start();
-
6、线程 join() 规则
主线程 A 等待子线程 B 完成(主线程 A 通过调用子线程 B 的 join() 方法实现),当子线程 B 完成后(主线程 A 中 join() 方法返回),主线程能够看到子线程的操作。所谓的“看到”,指的是对共享变量的操作。
//在线程 A 中,调用线程 B 的 join() 并成功返回,那么线程 B 中的任意操作 Happens-Before 于该 join() 操作的返回 Thread B = new Thread(()->{ // 此处对共享变量 var 修改 var = 66; }); // 例如此处对共享变量修改, // 则这个修改结果对线程 B 可见 // 主线程启动子线程 B.start(); B.join() // 子线程所有对共享变量的修改 // 在主线程调用 B.join() 之后皆可见 // 此例中,var==66
-
7、线程中断规则
对线程interrupt()方法的调用 Happens-Before 于被中断线程的代码检测到中断事件的发生
对线程中断操作 Happens-Before 于该线程中断之前
可以通过Thread.interrupted()方法检测到是否有中断发生。 -
8、对象终结规则
一个对象的初始化完成(构造函数执行结束) Happens-Before 于它的finalize()方法的开始。
final
final 修饰变量时,初衷是告诉编译器:这个变量生而不变,可以可劲儿优化。在 1.5 以后 Java 内存模型对 final 类型变量的重排进行了约束。现在只要我们提供正确构造函数没有“逸出”,就不会出问题了。
//在构造函数里面将 this 赋值给了全局变量 global.obj,这就是“逸出”,线程通过 global.obj 读取 x 是有可能读到 0 的。
public class FinalFieldExample {
final int x;
// 错误的构造函数
public FinalFieldExample() {
x = 3;
y = 4;
// 此处就是 this 逸出,
global.obj = this;
}
}
解决原子性问题
互斥锁
“同一时刻只有一个线程执行”这个条件非常重要,我们称之为互斥。如果能够保证对共享变量的修改是互斥的,无论是单核 CPU 还是多核 CPU,就都能保证原子性了。
锁和锁要保护的资源是有关联关系的
Java 语言提供的锁技术:synchronized
管程中锁的规则:对一个锁的解锁 Happens-Before 于后续对这个锁的加锁。(前一个线程在临界区修改的共享变量(该操作在解锁之前),对后续进入临界区(该操作在加锁之后)的线程是可见的。)
Java 编译器会在 synchronized 修饰的方法或代码块前后自动加上加锁 lock() 和解锁 unlock(),这样做的好处就是加锁 lock() 和解锁 unlock() 一定是成对出现的。
锁,一定有一个要锁定的对象,至于这个锁定的对象要保护的资源以及在哪里加锁 / 解锁,就属于设计层面的事情了。
class X {
// 修饰非静态方法
//当修饰非静态方法的时候,锁定的是当前实例对象 this
synchronized void foo() {
// 临界区
}
// 修饰静态方法
//当修饰静态方法的时候,锁定的是当前类的 Class 对象
synchronized static void bar() {
// 临界区
}
// 修饰代码块
Object obj = new Object();
void baz() {
synchronized (obj) {
// 临界区
}
}
}
受保护资源和锁之间的关联关系是 N:1 的关系,可以用同一把锁来保护多个资源
class SafeCalc {
//没有 volatile 修饰,有可见性问题
static long value = 0L;
// 锁 this
synchronized long get() {
return value;
}
// 锁 SafeCalc.class
synchronized static void addOne() {
value += 1;
}
}
由于临界区 get() 和 addOne() 是用两个锁保护的,因此这两个临界区没有互斥关系,临界区 addOne() 对 value 的修改对临界区 get() 也没有可见性保证,这就导致并发问题了。
用不同的锁对受保护资源进行精细化管理,能够提升性能。这种锁叫细粒度锁。使用细粒度锁可以提高并行度,是性能优化的一个重要手段。使用细粒度锁是有代价的,这个代价就是可能会导致死锁。
如何保护多个资源,关键是要分析多个资源之间的关系。如果资源之间没有关系,很好处理,每个资源一把锁就可以了。如果资源之间有关联关系,就要选择一个粒度更大的锁,这个锁应该能够覆盖所有相关的资源。除此之外,还要梳理出有哪些访问路径,所有的访问路径都要设置合适的锁
“原子性”的本质其实不是不可分割,不可分割只是外在表现,其本质是多个资源间有一致性的要求,操作的中间状态对外不可见。例如,在 32 位的机器上写 long 型变量有中间状态(只写了 64 位中的 32
位),在银行转账的操作中也有中间状态(账户 A 减少了 100,账户 B 还没来得及发生变化)。所以解决原子性问题,是要保证中间状态对外不可见。
- 避免死锁
-
只有以下这四个条件都发生时才会出现死锁:
1、互斥,共享资源 X 和 Y 只能被一个线程占用;
2、占有且等待,线程 T1 已经取得共享资源 X,在等待共享资源 Y 的时候,不释放共享资源 X;
3、不可抢占,其他线程不能强行抢占线程 T1 占有的资源;
4、循环等待,线程 T1 等待线程 T2 占有的资源,线程 T2 等待线程 T1 占有的资源,就是循环等待。 -
互斥这个条件没有办法破坏,因为用锁为的就是互斥
1、破坏占用且等待条件----->一次性申请所有资源
2、破坏不可抢占条件-------->能够主动释放它占有的资源这一点 synchronized 是做不到的。原因是 synchronized 申请资源的时候,如果申请不到,线程直接进入阻塞状态了,而线程进入阻塞状态,啥都干不了,也释放不了线程已经占有的资源。java.util.concurrent 这个包下面提供的 Lock 是可以轻松解决这个问题的
3、破坏循环等待条件---------> 需要对资源进行排序,然后按序申请资源。
按一定顺序加锁
-
用“等待-通知”机制优化循环等待
一个完整的等待 - 通知机制:线程首先获取互斥锁,当线程要求的条件不满足时,释放互斥锁,进入等待状态;当要求的条件满足时,通知等待的线程,重新获取互斥锁。
用 synchronized 实现等待 - 通知机制
wait()、notify()、notifyAll()
在下面这个图里,左边有一个等待队列,同一时刻,只允许一个线程进入 synchronized 保护的临界区(这个临界区可以看作大夫的诊室),当有一个线程进入临界区后,其他线程就只能进入图中左边的等待队列里等待(相当于患者分诊等待)。这个等待队列和互斥锁是一对一的关系,每个互斥锁都有自己独立的等待队列。
在并发程序中,当一个线程进入临界区后,由于某些条件不满足,需要进入等待状态,Java 对象的 wait() 方法就能够满足这种需求。如上图所示,当调用 wait() 方法后,当前线程就会被阻塞,并且进入到右边的等待队列中,这个等待队列也是互斥锁的等待队列。 线程在进入等待队列的同时,会释放持有的互斥锁,线程释放锁后,其他线程就有机会获得锁,并进入临界区了。
当条件满足时调用 notify(),会通知等待队列(互斥锁的等待队列)中的线程,告诉它条件曾经满足过。,被通知的线程要想重新执行,仍然需要获取到互斥锁
wait()、notify()、notifyAll() 方法操作的等待队列是互斥锁的等待队列
如果 synchronized 锁定的是 this,那么对应的一定是 this.wait()、this.notify()、this.notifyAll();如果 synchronized 锁定的是 target,那么对应的一定是 target.wait()、target.notify()、target.notifyAll() 。而且wait()、notify()、notifyAll() 这三个方法能够被调用的前提是已经获取了相应的互斥锁, wait()、notify()、notifyAll() 都是在 synchronized{}内部被调用的。
如果 synchronized 锁定的是 this,那么对应的一定是 this.wait()、this.notify()、this.notifyAll();如果 synchronized 锁定的是 target,那么对应的一定是 target.wait()、target.notify()、target.notifyAll() 。而且wait()、notify()、notifyAll() 这三个方法能够被调用的前提是已经获取了相应的互斥锁, wait()、notify()、notifyAll() 都是在 synchronized{}内部被调用的。
尽量使用 notifyAll(),notify() 是会随机地通知等待队列中的一个线程,而 notifyAll() 会通知等待队列中的所有线程。实际上使用 notify() 也很有风险,它的风险在于可能导致某些线程永远不会被通知到。