面试必问系列，源码解析多线程绝对不容忽视得问题：线程活性故障

小Q

关注

发布于: 2020 年 12 月 19 日

看多了各种多线程得内容，我们是不是忘记了某一个很重要得知识点——线程活性故障

线程活性故障是由于资源稀缺性或者程序自身的问题导致线程一直处于非 Runnable 状态，或者线程虽然处于 Runnable 状态但是其要执行的任务一直无法取得进展的一种故障现象

关注公众号：Java 架构师联盟，每日更新技术好文

下面就来介绍几种常见类型的线程活性故障：

死锁
锁死
线程饥饿
活锁

死锁

对于死锁得问题，我们有一个非常非常好玩的问题---哲学家吃饭，干饭人干饭魂，我们就通过这个讲解引入一下啊

假设有 5 个哲学家，他们的生活只是思考和吃饭。这些哲学家共用一个圆桌，每位都有一把椅子。在桌子中央有一碗米饭，在桌子上放着 5 根筷子（图 1 )。

当一位哲学家思考时，他与其他同事不交流。时而，他会感到饥饿，并试图拿起与他相近的两根筷子（筷子在他和他的左或右邻居之间）。一个哲学家一次只能拿起一根筷子。显然，他不能从其他哲学家手里拿走筷子。当一个饥饿的哲学家同时拥有两根筷子时，他就能吃。在吃完后，他会放下两根筷子，并开始思考。哲学家就餐问题是一个经典的同步问题，这不是因为其本身的实际重要性，也不是因为计算机科学家不喜欢哲学家，而是因为它是大量并发控制问题的一个例子。这个代表性的例子满足：在多个进程之间分配多个资源，而且不会出现死锁和饥饿。

我们可以用一段程序来模拟并验证上述的情况

先对筷子 Chopstick 进行定义，其能被操作的行为只有两种，即：拿起和放下

package com.test.lock;

复制代码

/**

复制代码

 * @author ：biws

复制代码

 * @date ：Created in 2020/12/18 22:29

复制代码

 * @description：

复制代码

*/

复制代码

public class Semaphore extends Object {

复制代码

    private int count;

复制代码

    public Semaphore(int startingCount){

复制代码

        count = startingCount;

复制代码

  //放下

复制代码

    public void down(){

复制代码

        synchronized (this) {

复制代码

            while (count <= 0) {

复制代码

                // We must wait

复制代码

                try {

复制代码

                    wait();

复制代码

                } catch (InterruptedException ex) {

复制代码

                    // I was interupted, continue onwards

复制代码

            // We can decrement the count

复制代码

            count--;

复制代码

  //拿起

复制代码

    public void up(){

复制代码

        synchronized (this) {

复制代码

            count++;

复制代码

            //notify a waiting thread to wakeup

复制代码

            if (count == 1 ) {

复制代码

                notify();

复制代码

最后，运行程序后，只要我们为哲学家设定每次思考和吃饭的耗时时间不要太长，那么应该就能很快看到程序没有继续输出日志了，似乎被卡住了，此时即发生了死锁

package com.test.lock;

复制代码

/**

复制代码

 * @author ：biws

复制代码

 * @date ：Created in 2020/12/18 22:30

复制代码

 * @description：

复制代码

*/

复制代码

public class Philosopher extends Thread {

复制代码

    // Shared by all Philosophers

复制代码

    public final static int N = 5;              // Number of philosophers

复制代码

    public final static int THINKING = 0;       // Philosopher is thinking

复制代码

    public final static int HUNGRY = 1;         // Philosopher is hungry

复制代码

    public final static int EATING = 2;         // Philosopher is eating

复制代码

    private static int state[] = new int[N];    // Array to keep track of

复制代码

    // everyones state

复制代码

    private static Semaphore mutex = new Semaphore(1);  // Mutual exclusion for

复制代码

    // critical regions

复制代码

    private static Semaphore s[] = new Semaphore[N];    // One for each

复制代码

    // Philosopher

复制代码

    // Instance variable

复制代码

    public int myNumber;                    // Which philosopher am I

复制代码

    public int myLeft;                      // Number of my left neighbor

复制代码

    public int myRight;                     // Number of my right neighbor

复制代码

    public Philosopher(int i) {             // Make a philosopher

复制代码

        myNumber = i;

复制代码

        myLeft = (i + N - 1) % N;               // Compute the left neighbor

复制代码

        myRight = (i + 1) % N;                // Compute the right neighbor

复制代码

    public void run() {                     // And away we go

复制代码

        while (true) {

复制代码

            think();                        // Philosopher is thinking

复制代码

            take_forks();                   // Acquire two forks or block

复制代码

            eat();                          // Yum-yum, spahgetti

复制代码

            put_forks();                    // Put both forks back on the table

复制代码

    public void take_forks() {               // Take the forks I need

复制代码

        mutex.down();                       // Enter critical region

复制代码

        state[myNumber] = HUNGRY;           // Record the fact that I am hungry

复制代码

        test(myNumber);                     // Try to acquire two forks

复制代码

        mutex.up();                         // Leave critical region

复制代码

        s[myNumber].down();                 // Block if forks were not acquired

复制代码

    public void put_forks() {

复制代码

        mutex.down();                       // Enter critical region

复制代码

        state[myNumber] = THINKING;         // Philosopher has finished eating

复制代码

        test(myLeft);                       // See if left neighbor can now eat

复制代码

        test(myRight);                      // See if right neighbor can now

复制代码

        // eat

复制代码

        mutex.up();                         // Leave critical region

复制代码

    public void test(int k) {                // Test philosopher k,

复制代码

        // from 0 to N-1

复制代码

        int onLeft = (k + N - 1) % N;           // K's left neighbor

复制代码

        int onRight = (k + 1) % N;            // K's right neighbor

复制代码

        if (state[k] == HUNGRY

复制代码

                && state[onLeft] != EATING

复制代码

                && state[onRight] != EATING) {

复制代码

            // Grab those forks

复制代码

            state[k] = EATING;

复制代码

            s[k].up();

复制代码

    public void think() {

复制代码

        System.out.println("Philosopher " + myNumber + " is thinking");

复制代码

        try {

复制代码

            sleep(1000);

复制代码

        } catch (InterruptedException ex) {

复制代码

    public void eat() {

复制代码

        System.out.println("Philosopher " + myNumber + " is eating");

复制代码

        try {

复制代码

            sleep(5000);

复制代码

        } catch (InterruptedException ex) {

复制代码

    public static void main(String args[]) {

复制代码

        Philosopher p[] = new Philosopher[N];

复制代码

        for (int i = 0; i < N; i++) {

复制代码

            // Create each philosopher and their semaphore

复制代码

            p[i] = new Philosopher(i);

复制代码

            s[i] = new Semaphore(0);

复制代码

            // Start the threads running

复制代码

            p[i].start();

复制代码

根据输出日志可以分析出，最后每位哲学家均拿到了其左手边的筷子，且均在等待右手边的筷子被放下，但此时由于筷子是独占资源，所以每位哲学家都只能干瞪着眼无法吃饭，最终导致了死锁

但是我的结果，没怎么等得时间特别长

大家可以多等一会，然后自己跟我一样执行一下，如果有时间的话，我写着写着就实在写不下去了，嘿嘿嘿

二、死锁的产生条件

哲学家就餐问题反映了发生死锁的必要条件，线程一旦发生死锁，那么这些线程及相关的共享资源就一定同时满足以下条件：

资源互斥。涉及的资源必须是排他性资源，即每个资源每次只能由一个线程持有
资源不可抢夺。涉及的资源只能由其持有线程主动释放，其它线程无法从持有线程中主动夺得
占用并等待其它资源。涉及的线程当前至少已经持有了一个排他性资源，并在申请其它资源，而这些资源同时又被其它线程所持有。在这个资源等待过程中，线程不会主动释放持有的现有资源
循环等待资源。在涉及到的所有线程列表内部，每个线程均在互相等待其它线程释放持有的资源，形成了互相等待的圆形依赖关系。即存在一个处于等待状态的线程集合 {T1, T2, ..., Tn}，其中 Ti 等待的资源被 T(i+1) 占有（i 大于等于 1 小于 n），Tn 等待的资源被 T1 占有

当产生死锁得时候，以上条件就一定同时成立

但是需要注意一点：

当上述条件即使同时成立也未必就一定能产生死锁。所以这也是为什么在测试的时候不出问题，但是一上线就出各种问题得原因

三、规避死锁

从上诉的四个发生死锁的必要条件来反推，我们只要消除死锁产生的任意一个必要条件就可以规避死锁了。由于锁具有排他性且只能由其持有线程来主动释放，因此由锁导致的死锁只能从消除“占用并等待资源”和消除“循环等待资源”这两个方向入手。

今天有点累了，所以从网上找到一些相应得解决方案，附伪代码，给大家提供一个思路，后面我会将代码进行提交

方法一

至多只允许四位哲学家同时去拿左筷子，最终能保证至少有一位哲学家能进餐，并在用完后释放两只筷子供他人使用。

设置一个初值为 4 的信号量 r，只允许 4 个哲学家同时去拿左筷子，这样就能保证至少有一个哲学家可以就餐，不会出现饿死和死锁的现象。

原理：至多只允许四个哲学家同时进餐，以保证至少有一个哲学家能够进餐，最终总会释放出他所使用过的两支筷子，从而可使更多的哲学家进餐。

方法二

仅当哲学家的左右手筷子都拿起时才允许进餐。

解法 1：利用 AND 型信号量机制实现。

原理：多个临界资源，要么全部分配，要么一个都不分配，因此不会出现死锁的情形。

解法 2：利用信号量的保护机制实现。

原理：通过互斥信号量 mutex 对 eat() 之前取左侧和右侧筷子的操作进行保护，可以防止死锁的出现。

方法三

规定奇数号哲学家先拿左筷子再拿右筷子，而偶数号哲学家相反。

原理：按照下图，将是 2,3 号哲学家竞争 3 号筷子，4,5 号哲学家竞争 5 号筷子。1 号哲学家不需要竞争。最后总会有一个哲学家能获得两支筷子而进餐。

四、锁死

等待线程由于唤醒其所需的条件永远无法成立，或者是其它线程无法唤醒这个线程导致其一直处于非运行状态（线程并未终止）从而任务一直取得进展，那么我们称这个线程被锁死

锁死和死锁之间有着共同的外在表现：故障线程一直处于非运行状态而使得其任务无法进展。死锁针对的是多个线程，而锁死可能只是作用在一个线程上。例如，一个调用了 Object.wait() 处于等待状态的线程，由于发生异常或者是代码缺陷，导致一直没有外部线程调用 Object.notify() 方法来唤醒等待线程，使得线程一直处于等待状态无法运行，此时就可以说该线程被锁死

锁死和死锁的产生条件是不同的，即便是在产生死锁的所有必要条件都不成立的情况下（此时死锁不可能发生），锁死仍可能出现。因此应对死锁的办法未必能够用来避免锁死现象的发生。按照锁死产生的条件来分，锁死包括信号丢失锁死和嵌套监视器锁死

1、信号丢失锁死

信号丢失锁死是由于没有相应的通知线程来唤醒等待线程而使等待线程一直处于等待状态的一种活性故障

例如，某个等待线程在执行 Object.wait() 前没有对保护条件进行判断，而此时保护条件实际上已经成立了，然而此后可能并无其他线程会来唤醒等待线程，因为在等待线程获得 Object 内部锁之前保护条件已经是处于成立状态了，这就使得等待线程一直处于等待状态，其任务一直无法取得进展

信号丢失锁死的另外一个常见例子是由于 CountDownLatch.countDown() 没有放在 finally 块中，而如果 CountDownLatch.countDown() 的执行线程运行时抛出未捕获的异常时， CountDownLatch.await() 的执行线程就会一直处于等待状态从而任务一直无法取得进展

例如，对于以下代码，当 ServiceB 抛出异常时，main 线程就会由于一直无法收到唤醒通知从而一直处于等待状态

fun main() {

复制代码

    val serviceManager = ServicesManager()

复制代码

    serviceManager.startServices()

复制代码

    println("等待所有 Services 执行完毕")

复制代码

    val allSuccess = serviceManager.checkState()

复制代码

    println("执行结果： $allSuccess")

复制代码

class ServicesManager {

复制代码

    private val countDownLatch = CountDownLatch(2)

复制代码

    private val serviceList = mutableListOf<AbstractService>()

复制代码

    init {

复制代码

        serviceList.add(ServiceA("ServiceA", countDownLatch))

复制代码

        serviceList.add(ServiceB("ServiceB", countDownLatch))

复制代码

    fun startServices() {

复制代码

        serviceList.forEach {

复制代码

            it.start()

复制代码

    fun checkState(): Boolean {

复制代码

        countDownLatch.await()

复制代码

        return serviceList.find { !it.checkState() } == null

复制代码

abstract class AbstractService(private val countDownLatch: CountDownLatch) {

复制代码

    private var success = false

复制代码

    abstract fun doTask(): Boolean

复制代码

    fun start() {

复制代码

        thread {

复制代码

//            try {

复制代码

//                success = doTask()

复制代码

//            } finally {

复制代码

//                countDownLatch.countDown()

复制代码

//            }

复制代码

            success = doTask()

复制代码

            countDownLatch.countDown()

复制代码

    fun checkState(): Boolean {

复制代码

        return success

复制代码

class ServiceA(private val serviceName: String, countDownLatch: CountDownLatch) : AbstractService(countDownLatch) {

复制代码

    override fun doTask(): Boolean {

复制代码

        Thread.sleep(2000)

复制代码

        println("${serviceName}执行完毕")

复制代码

        return true

复制代码

class ServiceB(private val serviceName: String, countDownLatch: CountDownLatch) : AbstractService(countDownLatch) {

复制代码

    override fun doTask(): Boolean {

复制代码

        Thread.sleep(3000)

复制代码

        if (Random.nextBoolean()) {

复制代码

            throw  RuntimeException("$serviceName failed")

复制代码

        } else {

复制代码

            println("${serviceName}执行完毕")

复制代码

        return true

复制代码

2、嵌套监视器锁死

嵌套监视器锁死是嵌套锁导致等待线程永远无法被唤醒的一种活性故障

来看以下伪代码。假设存在一个等待线程，其先后持有了 monitorX 和 monitorY 两个不同的锁，当等待线程监测到当前执行条件不成立时，调用了 monitorY.wait() 等待通知线程来唤醒自身，并同时释放了锁 monitorY

    synchronized(monitorX) {

复制代码

        //...

复制代码

        synchronized(monitorY) {

复制代码

            while (!somethingOk) {

复制代码

                monitorY.wait()

复制代码

            //执行目标行为

复制代码

相应的通知线程其伪代码如下所示。通知线程需要持有了 monitorX 和 monitorY 两个锁才能执行到 monitorY.notifyAll() 这行代码来唤醒等待线程。而等待线程执行 monitorY.wait() 时仅会释放 monitorY，而不会释放 monitorX。这使得通知线程由于一直获得 monitorX，从而导致等待线程一直无法被唤醒而一直处于 BLOCKED 状态

    synchronized(monitorX) {

复制代码

        //...

复制代码

        synchronized(monitorY) {

复制代码

            //...

复制代码

            somethingOk = true

复制代码

            monitorY.notifyAll()

复制代码

            //...

复制代码

这种由于嵌套锁导致通知线程始终无法唤醒等待线程的活性故障就被称为嵌套监视器锁死

五、线程饥饿

线程饥饿是指线程一直无法获得所需资源从而导致任务无法取得进展的一种活性故障现象

产生线程饥饿的一种情况是：线程一直没有被分配到处理器时间片。这种情况一般是由于处理器时间片一直被高优先级的线程抢占，低优先级的线程一直无法获得运行机会，此时即发生了线程饥饿现象。Thread 类提供了修改线程优先级的成员方法 setPriority(Int)，定义了整数一到十之间的十个优先级级别。不同的操作系统会有不同的线程优先级等级，JVM 会把这 Thread 类的十个优先级级别映射到具体的操作系统所定义的线程优先级关系上。但是我们所设置的线程优先级对线程调度器来说只是一个建议，当我们将一个线程设置为高优先级时，极可能会被线程调度器忽略，也可能会使该线程过度优先执行而别的线程一直得不到处理器时间片，从而导致线程饥饿。因此我们应该尽量避免修改线程的优先级

把锁看做一种资源，那么死锁也是一种线程饥饿。死锁的结果是所有故障线程都无法获得其所需的全部锁，从而使得其任务一直无法取得进展，这就相当于线程无法获得所需的全部资源从而导致任务无法取得进展，即产生了线程饥饿

发生线程饥饿并不一定同时存在死锁。因为线程饥饿可能只发生在一个线程上（例如上述的低优先级线程无法获得时间片），且即使是同时发生在多个线程上，也可能并不满足死锁发生的必要条件之一：循环等待资源，因为此时涉及到的多个线程所等待的资源可能并没有相互依赖关系

六、活锁

活锁指的是任务和任务的执行线程均没有被阻塞，但由于某些条件没有满足，导致线程一直在重复尝试—失败—尝试的过程，任务一直无法取得进展。也就是说，产生活锁的线程虽然处于 Runnable 状态，但是一直在做无用功

例如，对于上述的哲学家问题，假设某位哲学家“比较有礼貌”，当其拿起了左手边的筷子时，如果恰好有其他哲学家需要这根筷子，有礼貌的哲学家就主动放下筷子，让给其他哲学家使用。在最极端的情况下，每当有礼貌的哲学家一想要吃饭并拿起左手边的筷子时，就有其他哲学家需要这根筷子，此时有礼貌的哲学就会一直处于拿起筷子-放下筷子-拿起筷子这样一个循环过程中，导致一直无法吃饭。此时并没有发生死锁，但对于有礼貌的哲学家所代表的线程来说就是发生了活锁

到这里，基本几个概念都涵盖了，但是这套代码实现说时候，有点头疼，容我慢慢来更新吧，嘿嘿嘿，定时了，晚安

发布于: 2020 年 12 月 19 日阅读数: 47

原文链接:【http://xie.infoq.cn/article/556605b67f9a7d0049b30ab35】。

小Q

关注

还未添加个人签名 2020.06.30 加入

小Q 公众号：Java架构师联盟作者多年从事一线互联网Java开发的学习历程技术汇总，旨在为大家提供一个清晰详细的学习教程，侧重点更倾向编写Java核心内容。如果能为您提供帮助，请给予支持(关注、点赞、分享)！

发布

暂无评论

创作场景

面试必问系列，源码解析多线程绝对不容忽视得问题：线程活性故障

死锁

二、死锁的产生条件

三、规避死锁

四、锁死

1、信号丢失锁死

2、嵌套监视器锁死

五、线程饥饿

六、活锁

小Q

评论