文章目录
一、管程
1.什么是管程
Java 采用的是管程技术,synchronized 关键字及 wait()、notify()、notifyAll() 这三个方法都是管程的组成部分。
管程,指的是管理共享变量以及对共享变量的操作过程,让他们支持并发。翻译为 Java 领域的语言,就是管理类的成员变量和成员方法,让这个类是线程安全的。
2.MESA 模型
在并发编程领域,有两大核心问题:一个是互斥,即同一时刻只允许一个线程访问共享资源;另一个是
同步,即线程之间如何通信、协作。
互斥
管程解决互斥问题的思路很简单,就是将共享变量及其对共享变量的操作统一封装起来。如果想访问共享变量,只能通过调用管程提供的互斥方法,即只允许一个线程进入管程。
同步
在管程模型里,共享变量和对共享变量的操作是被封装起来的,当多个线程同时试图进入管程内部时,只允许一个线程进入,其他线程则在入口等待队列中等待。管程里还引入了条件变量的概念,而且每个条件变量都对应有一个等待队列,如下图,条件变量 A 和条件变量 B 分别都有自己的等待队列。
假设有个线程 T1 执行出队操作,不过需要注意的是执行出队操作,有个前提条件,就是队列不能是空的,而队列不空这个前提条件就是管程里的条件变量。 如果线程 T1 进入管程后恰好发现队列是空的,那怎么办呢?等待啊,去哪里等呢?就去条件变量对应的等待队列里面等。此时线程 T1 就去“队列不空”这个条件变量的等待队列中等待。线程 T1 进入条件变量的等待队列后,是允许其他线程进入管程的。
再假设之后另外一个线程 T2 执行入队操作,入队操作执行成功之后,“队列不空”这个条件对于线程 T1 来说已经满足了,此时线程 T2 要通知 T1,告诉它需要的条件已经满足了。当线程 T1 得到通知后,会从等待队列里面出来,但是出来之后不是马上执行,而是重新进入到入口等待队列里面。
条件变量及其等待队列我们讲清楚了,下面再说说 wait()、notify()、notifyAll() 这三个操作。前面提到线程 T1 发现“队列不空”这个条件不满足,需要进到对应的等待队列里等待。这个过程就是通过调用 wait() 来实现的。如果我们用对象 A 代表“队列不空”这个条件,那么线程 T1 需要调用 A.wait()。同理当“队列不空”这个条件满足时,线程 T2 需要调用 A.notify() 来通知 A 等待队列中的一个线程,此时这个队列里面只有线程 T1。至于 notifyAll() 这个方法,它可以通知等待队列中的所有线程。
下面的代码实现的是一个阻塞队列,阻塞队列有两个操作分别是入队和出队,这两个方法都是先获取互斥锁,类比管程模型中的入口。
对于入队操作,如果队列已满,就需要等待直到队列不满,所以这里用了 notFull.await();
对于出队操作,如果队列为空,就需要等待直到队列不空,所以就用了 notEmpty.await();
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();
}
// 省略入队操作...
//入队后,通知可出队
notEmpty.signal();
}finally {
lock.unlock();
}
}
// 出队
void deq(){
lock.lock();
try {
while (队列已空){
// 等待队列不空
notEmpty.await();
}
// 省略出队操作...
//出队后,通知可入队
notFull.signal();
}finally {
lock.unlock();
}
}
}
3.锁的正确用法
锁应该是私有的、不可变的、不可重用的。
// 普通对象锁
private final Object
lock = new Object();
// 静态对象锁
private static final Object
lock = new Object();
4.wait() 的正确使用
while(条件不满足) {
wait();
}
MESA 管程里面,T2 通知完 T1 后,T2 还是会接着执行,T1 并不立即执行,仅仅是从条件变量的等待队列进到入口等待队列里面。这样做的好处是 notify() 不用放到代码的最后,T2 也没有多余的阻塞唤醒操作。但是也有个副作用,就是当 T1 再次执行的时候,可能曾经满足的条件,现在已经不满足了,所以需要以循环方式检验条件变量。
5.notify() 何时可以使用
除非经过深思熟虑,否则尽量使用 notifyAll() 。
使用 notify() 需要满足以下三个条件:
- 所有等待线程拥有相同的等待条件;
- 所有等待线程被唤醒后,执行相同的操作;
- 只需要唤醒一个线程。
比如上面阻塞队列的例子中,对于“队列不满”这个条件变量,其阻塞队列里的线程都是在等待“队列不满”这个条件,所有等待线程被唤醒后执行的操作也是相同的,同时也满足第 3 条,只需要唤醒一个线程。所以上面阻塞队列的代码,使用 signal() 是可以的。
二、Lock和Condition
1.Lock
Java SDK 并发包通过 Lock 和 Condition 两个接口来实现管程,其中 Lock 用于解决互斥问题,Condition 用于解决同步问题。
Lock 和 synchronized 区别:
- synchronized 不能破坏不可抢占条件,原因是 synchronized 申请资源的时候,如果申请不到,线程直接进入阻塞状态了。
- Lock 提供三种方法解决这个问题。
- 能够响应中断,从而唤醒它,那它就有机会释放曾经持有的锁 A。
- 支持超时。
- 非阻塞地获取锁。如果尝试获取锁失败,并不进入阻塞状态,而是直接返回。
// 支持中断的API
void lockInterruptibly()
throws InterruptedException;
// 支持超时的API
boolean tryLock(long time, TimeUnit unit)
throws InterruptedException;
// 支持非阻塞获取锁的API
boolean tryLock();
class X {
private final Lock rtl =
new ReentrantLock();
int value;
public void addOne() {
// 获取锁
rtl.lock();
try {
value+=1;
} finally {
// 保证锁能释放
rtl.unlock();
}
}
}
Lock 使用范式:
try {
lock();
} finally {
unlock();
}
如何保证可见性
利用了 volatile 相关的 Happens-Before 规则。Java SDK 里面的 ReentrantLock,内部持有一个 volatile 的成员变量 state,获取锁的时候,会读写 state 的值;解锁的时候,也会读写 state 的值。
- 顺序性规则:对于线程 T1,
value+=1
Happens-Before 释放锁的操作unlock()
- volatile 变量规则:T1 的
unlock()
操作 Happens-Before 线程 T2 的lock()
操作 - 传递性规则:线程 T1 的
value+=1
Happens-Before 线程 T2 的lock()
操作。
2.可重入锁
可重入锁,指的是线程可以重复获取同一把锁。
例如下面代码中,当线程 T1 执行到 ① 处时,已经获取到了锁 rtl ,当在 ① 处调用 get() 方法时,会在 ② 再次对锁 rtl 执行加锁操作。此时,如果锁 rtl 是可重入的,那么线程 T1 可以再次加锁成功;如果锁 rtl 是不可重入的,那么线程 T1 此时会被阻塞。
class X {
private final Lock rtl =
new ReentrantLock();
int value;
public int get() {
// 获取锁
rtl.lock(); ②
try {
return value;
} finally {
// 保证锁能释放
rtl.unlock();
}
}
public void addOne() {
// 获取锁
rtl.lock();
try {
value = 1 + get(); ①
} finally {
// 保证锁能释放
rtl.unlock();
}
}
}
3.可重入函数
可重入函数,指的是多个线程可以同时调用该函数,每个线程都能得到正确结果;同时在一个线程内支持线程切换,无论被切换多少次,结果都是正确的。也就是线程安全的。
4.公平锁与非公平锁
ReentrantLock 这个类有两个构造函数,一个是无参构造函数,一个是传入 fair 参数的构造函数。fair 参数代表的是锁的公平策略,如果传入 true 就表示需要构造一个公平锁,反之则表示要构造一个非公平锁。
//无参构造函数:默认非公平锁
public ReentrantLock() {
sync = new NonfairSync();
}
//根据公平策略参数创建锁
public ReentrantLock(boolean fair){
sync = fair ? new FairSync()
: new NonfairSync();
}
- 公平锁,唤醒的策略就是谁等待的时间长,就唤醒谁。
- 非公平锁,则不提供这个公平保证,有可能等待时间短的线程反而先被唤醒。
5.加锁的最佳实践
- 永远只在更新对象的成员变量时加锁
- 永远只在访问可变的成员变量时加锁
- 永远不在调用其他对象的方法时加锁
调用其他对象的方法,实在是太不安全了,也许其他方法里面有线程 sleep() 的调用,也可能会有奇慢无比的 I/O 操作,这些都会严重影响性能。更可怕的是,其他类的方法可能也会加锁,然后双重加锁就可能导致死锁。
6.Condition
Condition 实现了管程模型里面的条件变量。
Lock&Condition 实现的管程是支持多个条件变量的,synchronized 只能有一个条件变量。
线程等待和通知需要调用 await()、signal()、signalAll()。
7.同步与异步
通俗点来讲就是调用方是否需要等待结果,如果需要等待结果,就是同步;如果不需要等待结果,就是异步。
如果你想让你的程序支持异步,可以通过下面两种方式来实现:
- 调用方创建一个子线程,在子线程中执行方法调用,这种调用我们称为异步调用;
- 方法实现的时候,创建一个新的线程执行主要逻辑,主线程直接 return,这种方法我们一般称为异步方法。
Dubbo 异步转同步:TCP 协议本身就是异步的,在 TCP 协议层面,发送完 RPC 请求后,线程是不会等待 RPC 的响应结果的。Dubbo 异步转同步的功能是通过 DefaultFuture 这个类实现的。
当 RPC 返回结果之前,阻塞调用线程,让调用线程等待;当 RPC 返回结果后,唤醒调用线程,让调用线程重新执行。
大致的原理代码如下:
// 创建锁与条件变量
private final Lock lock
= new ReentrantLock();
private final Condition done
= lock.newCondition();
// 调用方通过该方法等待结果
Object get(int timeout){
long start = System.nanoTime();
lock.lock();
try {
while (!isDone()) {
done.await(timeout);
long cur=System.nanoTime();
if (isDone() ||
cur-start > timeout){
break;
}
}
} finally {
lock.unlock();
}
if (!isDone()) {
throw new TimeoutException();
}
return returnFromResponse();
}
// RPC结果是否已经返回
boolean isDone() {
return response != null;
}
// RPC结果返回时调用该方法
private void doReceived(Response res) {
lock.lock();
try {
response = res;
if (done != null) {
done.signal();
}
} finally {
lock.unlock();
}
}
三、Semaphore
1.信号量模型
可以概括为:一个计数器,一个等待队列,三个方法。计数器和等待队列对外是透明的,所以只能通过信号量模型提供的三个方法来访问它们,这三个方法分别是:init()、down() 和 up()。
- init():设置计数器的初始值。
- down():计数器的值减 1;如果此时计数器的值小于 0,则当前线程将被阻塞,否则当前线程可以继续执行。
- up():计数器的值加 1;如果此时计数器的值小于等于 0,则唤醒等待队列中的一个线程,并将其从等待队列中移除。
Java 信号量模型是由 java.util.concurrent.Semaphore
实现的,这三个方法都是原子操作。
2.使用信号量实现累加器
在累加器的例子里面,count+=1 操作是个临界区,只允许一个线程执行,也就是说要保证互斥。
static int count;
//初始化信号量
static final Semaphore s
= new Semaphore(1);
//用信号量保证互斥
static void addOne() {
s.acquire();
try {
count+=1;
} finally {
s.release();
}
}
3.使用信号量实现一个限流器
Semaphore 有一个功能是 Lock 不容易实现的,那就是:允许多个线程访问一个临界区。常见的有:池化资源,同一时刻允许多个线程同时使用连接池。
只要把计数器的值设置成对象池里对象的个数 N,就能完美解决对象池的限流问题了。
public class PoolWithSemaphore {
class ObjPool<T, R> {
final List<T> pool;
final Semaphore sem;
// 构造函数
ObjPool(int size, T t) {
pool = new Vector<T>() {
};
for (int i = 0; i < size; i++) {
pool.add(t);
}
sem = new Semaphore(size);
}
// 利用对象池的对象,调用func
R exec(Function<T, R> func) throws InterruptedException {
T t = null;
sem.acquire();
try {
t = pool.remove(0);
return func.apply(t);
} finally {
pool.add(t);
sem.release();
}
}
}
public static void main(String[] args) throws InterruptedException {
// 创建对象池
PoolWithSemaphore x = new PoolWithSemaphore();
ObjPool<Integer, String> pool = x.new ObjPool<Integer, String>(10, 2);
// 通过对象池获取t,之后执行
pool.exec(t -> {
System.out.println(t);
return t.toString();
});
}
}
这个例子中,对象保存在了 Vector 中,这里不可以换成 ArrayList,因为ArrayList 非线程安全,因为可能存在多个线程同时执行 remove 和 add 方法,会导致不可预知的错误。
思考题
1、wait() 方法,在 MESA 模型里面,增加了超时参数,你觉得这个参数有必要吗?
答:有,避免没人唤醒一直阻塞。超时后会退出条件变量的等待队列,重新进入管程的等待队列。
2、你已经知道 tryLock() 支持非阻塞方式获取锁,下面这段关于转账的程序就使用到了 tryLock(),你来看看,它是否存在死锁问题呢?
class Account {
private int balance;
private final Lock lock
= new ReentrantLock();
// 转账
void transfer(Account tar, int amt){
while (true) {
if(this.lock.tryLock()) {
try {
if (tar.lock.tryLock()) {
try {
this.balance -= amt;
tar.balance += amt;
} finally {
tar.lock.unlock();
}
}//if
} finally {
this.lock.unlock();
}
}//if
}//while
}//transfer
}
答:不会死锁,但是可能活锁,两个线程同时对自己加锁,然后获取对方的锁失败,又释放自己的锁,反复循环。可以在外层 finally 处加一个随机时间的sleep。
3、DefaultFuture 里面唤醒等待的线程,用的是 signal(),而不是 signalAll(),你来分析一下,这样做是否合理呢?
答:合理。每个rpc请求都会占用一个线程并产生一个新的DefaultFuture实例,它们的lock&condition是不同的,并没有竞争关系
参考资料:王宝令----Java并发编程实战