一般在解决多线程编程题时,我们都离不开JUC并发包下的各种工具类,特别是ReentrantLock锁,它能提供互斥与线程同步的能力,那它是如何获得这个能力的呢?今天指北君就来详细说说给它提供强大能力的两大接口。(PS:文末有当年指北君面试阿里的多线程编程原题以及答案喔)
我们知道,并发领域中有两大核心问题:互斥与同步问题,Java在1.5版本之前,是提供了synchronized来实现的。synchronized是内置锁,虽然在大部分情况下它都能很好的工作,但是依然还是会存在一些局限性,除了当时1.5版本的性能问题外(1.6版本后,synchronized的性能已经得到了很大的优化),还有如下两个问题:
- 无法解决死锁问题
- 最多使用一个条件变量
所以针对这些问题,Doug Lea在并发包中增加了两个接口Lock和Condition来解决这两个问题,所以指北君今天就说说这两个接口是如何解决synchronized中的这两个问题的。
一. Lock接口
1.1 介绍
在我们分析Lock接口是如何解决死锁问题之前,我们先看看死锁是如何产生的。死锁的产生需要满足下面四个条件:
- 互斥:共享资源同一时间只能被一个线程占用
- 不可抢占:其他线程不能强行占有另一个线程的资源
- 占有且等待:线程在等待其他资源时,不释放自己已占有的资源
- 循环等待:线程1和线程2互相占有对方的资源并相互等待
所以,我们只需要破坏上面条件中的任意一个,即可打破死锁。但需要注意的是,互斥条件是不能破坏的,因为使用锁的目的就是为了互斥。所以Lock接口通过破坏掉 "不可抢占"这个条件来解决死锁,具体如下:
- 非阻塞获取锁:尝试获取锁,如果失败了就立刻返回失败,这样就可以释放已经持有的其他锁
- 响应中断:如果发生死锁后,此线程被其他线程中断,则会释放锁,解除死锁
- 支持超时:一段时间内获取不到锁,就返回失败,这样就可以释放之前已经持有的锁
接下来我们具体看看接口代码吧。
1.2 源码解读
还需要额外注意的一点,使用synchronized作为锁时,我们是不需要考虑释放锁的,但Lock是属于显示锁,是需要我们手动释放锁的。我们一般在finally块中调用lock.unlock()手动释放锁,具体形式如下:
我们最后通过一张图来总结下Lock接口:
二. Condition接口
2.1 介绍
针对synchronized最多只能使用一个条件变量的问题,Condition接口提供了解决方案。但是为什么多个条件变量就比一个条件变量好呢?我们先来看看synchronized使用一个条件变量时会有什么弊端。
一个synchronized内置锁只对应一个等待容器(wait set),当线程调用wait方法时,会把当前线程放入到同一个等待容器中,当我们需要根据某些特定的条件来唤醒符合条件的线程时,我们只能先从等待容器里唤醒一个线程后,再看是否符合条件。如果不符合条件,则需要将此线程继续wait,然后再去等待容器中获取下一个线程再判断是否满足条件。这样会导致许多无意义的cpu开销。
我们可以看到Lock接口中有个newCondition()的方法:
通过这个方法,一个锁可以建立多个Conditiion,每个Condtition都有一个容器来保存相应的等待线程,拿到锁的线程根据特定的条件唤醒对应的线程时,只需要去唤醒对应的Contition内置容器中的线程即可,这样就可以减少无意义的CPU开销。然后我们具体看看Condition接口的源码。
2.2 源码解读
需要注意的是,Object类的等待方法是没有返回值的,但Condtition类中的部分等待方法是有返回值的。awaitNanos(long nanosTimeout)返回了剩余等待的时间;await(long time, TimeUnit unit)返回boolean值,如果返回false,则说明是因为超时返回的,否则返回true。为什么增加返回值?为了就是帮助我们弄清楚方法返回的原因。
四. 阿里多线程考题
最后我们通过实现了Lock和Condition接口能力的ReentrantLock类来解决阿里多线程面试题。
题目是使用三个线程循环打印ABC,一共打印50次。我们直接上答案:
五. 总结
Lock与Condition接口就说完了,最后指北君再总结一下:
针对synchronized内置锁无法解决死锁、只有一个条件变量等问题,Doug Lea在Java并发包中增加了Lock和Condition接口来解决。对于死锁问题,Lock接口增加了超时、响应中断、非阻塞三种方式来获取锁,从而避免了死锁。针对一个条件变量问题,Condtition接口通过一把锁可以创建多个条件变量的方式来解决。最后我们通过一个阿里面试题来说明了Lock和Condition接口所提供的能力。
今天就到这了,我是指北君,我们下篇文章见~