JUC并发包源码实战

并发编程之Lock和Condition实现管程

2019-07-14  本文已影响0人  语落心生

Java SDK 并发包通过 Lock 和 Condition 两个接口来实现管程,其中 Lock 用于解决互斥
问题,Condition 用于解决同步问题。

在介绍 Lock 的使用之前,有个问题需要思考一下:
Java 语言本身提供的 synchronized 也是管程的一种实现,既然 Java 从语言层面已经实现了管
程了,那为什么还要在 SDK 里提供另外一种实现呢?

再造管程的理由

你也许曾经听到过很多这方面的传说,例如在 Java 的 1.5 版本中,synchronized 性能不如
SDK 里面的 Lock,但 1.6 版本之后,synchronized 做了很多优化,将性能追了上来,所以 1.6
之后的版本又有人推荐使用 synchronized 了。

在介绍死锁问题的时候,提出了一个破坏不可抢占条件方案,但是这个方案 synchronized 没有办法解决。原因是 synchronized 申请资源的时候,如果申请不到,线程直接进入阻塞状态了,而线程进入阻塞状态,啥都干不了,也释放不了线程已经占有的资源。

如果我们重新设计一把互斥锁去解决这个问题,那该怎么设计呢?有三种方案。

实现的就是 Lock 接口的三个方法。详情如下:

// 支持中断的 API
void lockInterruptibly()
 throws InterruptedException;
// 支持超时的 API
boolean tryLock(long time, TimeUnit unit)
 throws InterruptedException;
// 支持非阻塞获取锁的 API
boolean tryLock();

如何保证可见性

Java SDK 里面 Lock 的使用,有一个经典的范例,就是try{}finally{},需要重点关注的是在 finally 里面释放锁。Java 里多线程的可见性是通过 Happens-Before 规则保证的,而 synchronized 之所以能够保证可见性,也是因为有对于“不可抢占”这个条件,占用部分资源的线程进一步申请其他资源时,如果申请不到,可以主动释放它占有的资源,这样不可抢占这个条件就破坏掉了。

一条 synchronized 相关的规则:synchronized 的解锁 Happens-Before 于后续对这个锁的加锁。那 Java SDK 里面 Lock 靠什么保证可见性呢?例如在下面的代码中,线程 T1 对 value 进行了 +=1 操作,那后续的线程 T2 能够看到 value 的正确结果吗?

class X {
 private final Lock rtl =
、 new ReentrantLock();
 int value;
 public void addOne() {
 // 获取锁
 rtl.lock();
 try {
 value+=1;
 } finally {
 // 保证锁能释放
 rtl.unlock();
 }
 }
}

答案必须是肯定的。Java SDK 里面锁的实现非常复杂,这里我就不展开细说了,但是原理还是需要简单介绍一下:它是利用了 volatile 相关的 Happens-Before 规则。Java SDK 里面的ReentrantLock,内部持有一个 volatile 的成员变量 state,获取锁的时候,会读写 state 的值;解锁的时候,也会读写 state 的值(简化后的代码如下面所示)。也就是说,在执行 value+=1之前,程序先读写了一次 volatile 变量 state,在执行 value+=1 之后,又读写了一次 volatile变量 state。根据相关的 Happens-Before 规则:

class SampleLock {
 volatile int state;
 // 加锁
 lock() {
 // 省略代码无数
 state = 1;
 }
 // 解锁
 unlock() {
 // 省略代码无数
 state = 0;
 }
}

什么是可重入锁

如果观察过BlockingQueue,会发现我们创建的锁的具体类名是 ReentrantLock,这个翻译过来叫可重入锁,这个概念前面我们一直没有介绍过。所谓可重入锁,顾名思义,指的是线程可以重复获取同一把锁。例如下面代码中,当线程 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();
 }
 }
}

公平锁与非公平锁

在使用 ReentrantLock 的时候,这个类有两个构造函数,一个是无参构造函数,一个是传入 fair 参数的构造函数。fair 参数代表的是锁的公平策略,如果传入 true 就表示需要构造一个公平锁,反之则表示要构造一个非公平锁。

// 无参构造函数:默认非公平锁
public ReentrantLock() {
 sync = new NonfairSync();
}
// 根据公平策略参数创建锁
public ReentrantLock(boolean fair){
 sync = fair ? new FairSync()
 : new NonfairSync();
}

比如入口等待队列,锁都对应着一个等待队列,如果一个线程没有获得锁,就会进入等待队列,当有线程释放锁的时候,就需要从等待队列中唤醒一个等待的线程。如果是公平锁,唤醒的策略就是谁等待的时间长,就唤醒谁,很公平;如果是非公平锁,则不提供这个公平保证,有可能等待时间短的线程反而先被唤醒。

用锁的最佳实践

最值得推荐的是并发大师Doug Lea《Java 并发编程:设计原则与模式》一书中,推荐的三个用锁的最佳实践,它们分别是:

对于第三条规则,因为调用其他对象的方法,实在是太不安全了,也许“其他”方法里面有线程 sleep()的调用,也可能会有奇慢无比的 I/O 操作,这些都会严重影响性能。更可怕的是,“其他”类的方法可能也会加锁,然后双重加锁就可能导致死锁。

上一篇下一篇

猜你喜欢

热点阅读