锁原理 - 信号量 vs 管程:JDK 为什么选择管程
锁原理 - 信号量 vs 管程:JDK 为什么选择管程
并发编程之美系列目录:https://www.cnblogs.com/binarylei/p/9569428.html
管程和信号量都能解决并发问题,它们是等价的。所谓等价指的是用管程能够实现信号量,也能用信号量实现管程。但是管程在信号量的基础上提供条件同步,使用更容易,所以 Java 采用的是管程技术。synchronized 关键字及 wait()、notify()、notifyAll() 这三个方法都是管程的组成部分。
1. 并发编程解决方案 - 信号量 vs 管程
1.1 相关概念
- 临界资源:虽然多个进程可以共享系统中的各种资源,但其中许多资源一次只能为一个进程所使用,我们把一次仅允许一个进程使用的资源称为临界资源。许多物理设备都属于临界资源,如打印机等。此外,还有许多变量、数据等都可以被若干进程共享,也属于临界资源。
- 临界区:对临界资源的访问,必须互斥地进行,在每个进程中,访问临界资源的那段代码称为临界区。
- 互斥:只有一个线程能访问临界区。
1.2 信号量 vs 管程
并发编程这个技术领域已经发展了半个世纪了,相关的理论和技术纷繁复杂。那有没有一种核心技术可以很方便地解决我们的并发问题呢?事实上,锁机制的实现方案有两种:
- 信号量(Semaphere):操作系统提供的一种协调共享资源访问的方法。和用软件实现的同步比较,软件同步是平等线程间的的一种同步协商机制,不能保证原子性。而信号量则由操作系统进行管理,地位高于进程,操作系统保证信号量的原子性。
- 管程(Monitor):解决信号量在临界区的 PV 操作上的配对的麻烦,把配对的 PV 操作集中在一起,生成的一种并发编程方法。其中使用了条件变量这种同步机制。
说明: 信号量将共享变量 S 封装起来,对共享变量 S 的所有操作都只能通过 PV 进行,这是不是和面向对象的思想是不是很像呢?事实上,封装共享变量是并发编程的常用手段。
在信号量中,当 P 操作无法获取到锁时,将当前线程添加到同步队列(syncQueue)中。当其余线程 V 释放锁时,从同步队列中唤醒等待线程。但当有多个线程通过信号量 PV 配对时会异常复杂,所以管程中引入了等待队列(waitQueue)的概念,进一步封装这些复杂的操作。
2. 信号量(Semaphere)
2.1 原理
信号中包括一个整形变量,和两个原子操作 P 和 V。其原子性由操作系统保证,这个整形变量只能通过 P 操作和 V 操作改变。
- 信号量由一个整形变量 S 和两个原子操作 PV 组成。
- P(Prolaag,荷兰语尝试减少):信号量值减 1,如果信号量值小于 0,则说明资源不够用的,把进程加入等待队列。
- V (Verhoog,荷兰语增加):信号量值加 1,如果信号量值小于等于 0,则说明等待队列里有进程,那么唤醒一个等待进程。
说明: 共享变量 S 只能由 PV 操作,PV 的原子性由操作系统保证。P 相当获取锁,可能会阻塞线程,而 V 相当于释放锁,不会阻塞线程。根据同步队列中唤醒线程的先后顺序,可以分为公平和非公平两种。
信号量分类:
- 二进制信号量:资源数目为 0 或 1。
- 资源信号量:资源数目为任何非负值。
2.2 代码实现
private class Semaphore {
private int sem;
private WaitQueue q;
void P() {
sem--;
if (sem < 0) {
// add this thread t to q;
block(t);
}
}
void V() {
sem++;
if (sem <= 0) {
// remove a thread t from q;
wakeup(t);
}
}
}
说明: Semaphere 的思路很简单,就是将共享变量 S 及其所有操作 PV 统一封装起来。事实上,封装共享变量是并发编程的常用手段。
2.3 使用场景
2.3.1 互斥访问
Semaphore mutex = new Semaphore(1);
mutex.P();
// do something
mutex.V();
实现临界区的互斥访问注意事项: 一是信号量的初始值必须为 1;二是 PV 必须配对使用。
2.3.2 条件访问
Semaphore condition = new Semaphore(0);
// ThreadA,进行等待队列中
condition.P();
// ThreadB,唤醒等待线程 ThreadA
condition.V();
实现临界区的条件访问注意事项: 初始信号量必须为 0,这样所有的线程调用 P 操作时都无法获取到锁,只能进行等待队列(相当于管程中的等待队列),当其余线程 B 调用 V 操作时会唤醒等待线程。
2.3.3 阻塞队列
阻塞队列是典型的生产者-消费者模式,任何时刻只能有一个生产者线程或消费都线程访问缓冲区。并且当缓冲区满时,生产者线程必须等待,反之消费者线程必须等待。
- 任何时刻只能有一个线程操作缓存区:互斥访问,使用二进制信号量 mutex,其信号初始值为 1。
- 缓存区空时,消费者必须等待生产者:条件同步,使用资源信号量 notEmpty,其信号初始值为 0。
- 缓存区满时,生产者必须等待消费者:条件同步,使用资源信号量 notFull,其信号初始值为 n。
private class BoundedBuffer {
private int n = 100;
private Semaphore mutex = new Semaphore(1);
private Semaphore notFull = new Semaphore(n);
private Semaphore notEmpty = new Semaphore(0);
public void product() throws InterruptedException {
notFull.P(); // 缓冲区满时,生产者线程必须等待
mutex.P();
// ...
mutex.V();
notEmpty.V(); // 唤醒等待的消费者线程
}
public void consume() throws InterruptedException {
notEmpty.P(); // 缓冲区空时,消费都线程等待
mutex.P();
// ...
mutex.V();
notFull.V(); // 唤醒等待的生产者线程
}
}
总结: 直接使用信号量,当多个 Semaphore 条件同步时,PV 配对比较困难而且容易写错。为了解决 PV 配对困难的问题,管程登场了。管程实际上是对条件同步的进一步封装。
2. 管程(Monitor)
Monitor 直译过来就是 "监视器",操作系统领域一般都翻译成 "管程"。所谓管程,指的是管理共享变量以及对共享变量的操作过程,让他们支持并发。翻译为 Java 领域的语言,就是管理类的成员变量和成员方法,让这个类是线程安全的。那管程是怎么管的呢?
2.1 MESA 模型
在管程的发展史上,先后出现过三种不同的管程模型,分别是:Hasen 模型、Hoare 模型和 MESA 模型。其中,现在广泛应用的是 MESA 模型,并且 Java 管程的实现参考的也是 MESA 模型。所以今天我们重点介绍一下 MESA 模型。
在并发编程领域,有两大核心问题:一个是互斥,即同一时刻只允许一个线程访问共享资源;另一个是同步,即线程之间如何通信、协作。这两大问题,管程都是能够解决的。
2.2 互斥
管程和信号量关于互斥的实现完全一样,都是将共享变量及其操作统一封装起来。
2.3 同步
在上述用信号量实现生产者-消费者模式的代码中,为了实现阻塞队列的功能,即等待-通知(wait-notify),除了使用互斥锁 mutex 外,还需要两个判断队满和队空的资源信号量 fullBuffers 和 emptyBuffers,使用起来不仅复杂,还容易出错。
管程在信号量的基础上,更进一步,增加了条件同步,将上述复杂的操作封起来。
JUC AQS 也是基于管程实现的,我们基于 ReentrantLock 实现一个阻塞队列,重点比较和信号量的区别。阻塞队列有两个操作分别是入队和出队,这两个方法都是先获取互斥锁,类比管程模型中的入口。
- 对于入队操作,如果队列已满,就需要等待直到队列不满,即 notFull.await();。
- 对于出队操作,如果队列为空,就需要等待直到队列不空,即 notEmpty.await();。
- 如果入队成功,那么队列就不空了,就需要通知条件变量:队列不空 notEmpty 对应的等待队列。
- 如果出队成功,那就队列就不满了,就需要通知条件变量:队列不满 notFull 对应的等待队列。
public class BlockedQueue<T> {
final Lock lock = new ReentrantLock();
// 条件变量:队列不满
final Condition notFull = lock.newCondition();
// 条件变量:队列不空
final Condition notEmpty = lock.newCondition();
// 入队
void enq(T x) {
lock.lock();
try {
while (队列已满) {
// 等待队列不满
notFull.await();
}
// add x to queue
// 入队后,通知可出队
notEmpty.signal();
} finally {
lock.unlock();
}
}
// 出队
void deq() {
lock.lock();
try {
while (队列已空) {
// 等待队列不空
notEmpty.await();
}
// remove the first element from queue
// 出队后,通知可入队
notFull.signal();
} finally {
lock.unlock();
}
}
}
总结: 对于用信号量实现阻塞队列,是不是感觉要简单些。这里的 notFull 相当于之前的 fullBuffers,notEmpty 相当于之前的 emptyBuffers。
2.4 wait() 的正确姿势
对于 MESA 管程来说,有一个编程范式,就是需要在一个 while 循环里面调用 wait()。这个是 MESA 管程特有的。所谓范式,就是前人总结的经验。
while (条件不满足) {
wait();
}
Hasen 模型、Hoare 模型和 MESA 模型的一个核心区别就是当条件满足后,如何通知相关线程。管程要求同一时刻只允许一个线程执行,那当线程 T2 的操作使线程 T1 等待的条件满足时,T1 和 T2 究竟谁可以执行呢?
- Hasen 模型里面,要求 notify() 放在代码的最后,这样 T2 通知完 T1 后,T2 就结束了,然后 T1 再执行,这样就能保证同一时刻只有一个线程执行。
- Hoare 模型里面,T2 通知完 T1 后,T2 阻塞,T1 马上执行;等 T1 执行完,再唤醒 T2,也能保证同一时刻只有一个线程执行。但是相比 Hasen 模型,T2 多了一次阻塞唤醒操作。
- MESA 管程里面,T2 通知完 T1 后,T2 还是会接着执行,T1 并不立即执行,仅仅是从条件变量的等待队列进到入口等待队列里面。这样做的好处是 notify() 不用放到代码的最后,T2 也没有多余的阻塞唤醒操作。但是也有个副作用,就是当 T1 再次执行的时候,可能曾经满足的条件现在已经不满足了,所以需要以循环方式检验条件变量。
思考1:wait() 方法,在 Hasen 模型和 Hoare 模型里面,都是没有参数的,而在 MESA 模型里面,增加了超时参数,你觉得这个参数有必要吗?
有必要。Hasen 是执行完再去唤醒另外一个线程,能够保证线程的执行。Hoare 是中断当前线程,唤醒另外一个线程,执行玩再去唤醒,也能够保证完成。而 MESA 是进入等待队列,不一定有机会能够执行,产生饥饿现象。
2.5 notify() 何时可以使用
除非经过深思熟虑,否则尽量使用 notifyAll(),不要使用 notify()。
那什么时候可以使用 notify() 呢?需要满足以下三个条件:
- 所有等待线程拥有相同的等待条件;
- 所有等待线程被唤醒后,执行相同的操作;
- 只需要唤醒一个线程。
比如上面阻塞队列的例子中,对于“队列不满”这个条件变量,其阻塞队列里的线程都是在等待“队列不满”这个条件,反映在代码里就是下面这 3 行代码。对所有等待线程来说,都是执行这 3 行代码,重点是 while 里面的等待条件是完全相同的。
2.6 AQS 和 synchronized 原理
JUC AQS 就是基于管程实现的,内部包含两个队列,一个是同步队列,一个是等待队列:
- 同步队列:锁被占用时,会将该线程添加到同步队列中。当锁释放后,会从队列中唤醒一个线程,又分为公平和非公平两种。
- 等待队列:当调用 await 是,会将该线程添加到等待队列中。当其它线程调用 notify 时,会将该线程从等待队列移动到同步队列中,重新竞争锁。
synchronized 也是基于管程实现的,核心的数据结构见 ObjectMonitor。AQS 和 synchronized 都是管程 MESA 模型在 Java 中的应用。一切都套路,有章可循。
参考:
每天用心记录一点点。内容也许不重要,但习惯很重要!
posted on 2020-03-22 08:29 binarylei 阅读(7634) 评论(4) 编辑 收藏 举报