Java并发编程实战（4）- 死锁

在这篇文章中，我们主要讨论一下死锁及其解决办法。

概述

在上一篇文章中，我们讨论了如何使用一个互斥锁去保护多个资源，以银行账户转账为例，当时给出的解决方法是基于Class对象创建互斥锁。

这样虽然解决了同步的问题，但是能在现实中使用吗？答案是不可以，尤其是在高并发的情况下，原因是我们使用的互斥锁的范围太大，以转账为例，我们的做法会锁定整个账户Class对象，这样会导致转账操作只能串行进行，但是在实际场景中，大量的转账操作业务中的双方是不相同的，直接在Class对象级别上加锁是不能接受的。

那如果在对象实例级别上加锁，使用细粒度锁，会有什么问题？可能会发生死锁。

我们接下来看一下造成死锁的原因和可能的解决方案。

死锁案例

什么是死锁？

死锁是指一组互相竞争资源的线程因互相等待，导致“永久”阻塞的现象。

一般来说，当我们使用细粒度锁时，它在提升性能的同时，也可能会导致死锁。

我们还是以银行转账为例，来看一下死锁是如何发生的。

首先，我们先定义个BankAccount对象，来存储基本信息，代码如下。

public class BankAccount {
    private int id;
    private double balance;
    private String password;
    public int getId() {
        return id;
    }
    public void setId(int id) {
        this.id = id;
    }
    public double getBalance() {
        return balance;
    }
    public void setBalance(double balance) {
        this.balance = balance;
    }
}

接下来，我们使用细粒度锁来尝试完成转账操作，代码如下。

public class BankTransferDemo {
    
    public void transfer(BankAccount sourceAccount, BankAccount targetAccount, double amount) {
        synchronized(sourceAccount) {
            synchronized(targetAccount) {
                if (sourceAccount.getBalance() > amount) {
                    System.out.println("Start transfer.");
                    System.out.println(String.format("Before transfer, source balance:%s, target balance:%s", sourceAccount.getBalance(), targetAccount.getBalance()));
                    sourceAccount.setBalance(sourceAccount.getBalance() - amount);
                    targetAccount.setBalance(targetAccount.getBalance() + amount);
                    System.out.println(String.format("After transfer, source balance:%s, target balance:%s", sourceAccount.getBalance(), targetAccount.getBalance()));
                }
            }
        }
    }
}

我们用下面的代码来做简单测试。

    public static void main(String[] args) throws InterruptedException {
        BankAccount sourceAccount = new BankAccount();
        sourceAccount.setId(1);
        sourceAccount.setBalance(50000);
        
        BankAccount targetAccount = new BankAccount();
        targetAccount.setId(2);
        targetAccount.setBalance(20000);
        
        BankTransferDemo obj = new BankTransferDemo();
        
        Thread t1 = new Thread(() ->{
            for (int i = 0; i < 10000; i++) {
                obj.transfer(sourceAccount, targetAccount, 1);
            }
        });
        
        Thread t2 = new Thread(() ->{
            for (int i = 0; i < 10000; i++) {
                obj.transfer(targetAccount, sourceAccount, 1);
            }
        });
        
        t1.start();
        t2.start();
        
        t1.join();
        t2.join();
        
        System.out.println("Finished.");
    }

测试代码中包含了2个线程，其中t1线程循环从sourceAccount向targetAccount转账，而t2线程会循环从targetAccount向sourceAccount转账。

从运行结果来看，t1线程中的循环在运行600次左右时，t2线程也创建好，开始循环转账了，这时就会发生死锁，导致t1线程和t2线程都无法继续执行。

我们可以用下面的资源分配图来更直观的描述死锁。

死锁的原因和预防

并发程序一旦死锁，一般没有特别好的办法，很多时候我们只能重启应用，因此，解决死锁问题的最好办法是规避死锁。

我们先来看一下死锁发生的条件，一个叫Coffman的牛人，于1971年在ACM Computing Surveys发表了一篇名为System Deadlocks的文章，他总结了只有以下四个条件全部满足的情况下，才会发生死锁：

• 互斥，共享资源X和Y只能被一个线程占用。
• 占有且等待，线程t1已经取得共享资源X，在等待共享资源Y的时候，不释放共享资源X。
• 不可抢占，其他线程不能强行抢占线程t1占有的资源。
• 循环等待，线程t1等待线程t2占有的资源，线程t2等待线程t1占有的资源，就是循环等待。

通过上述描述，我们能够推导出，只要破坏上面其中一个条件，就可以避免死锁的发生。

但是第一个条件互斥，是不可以被破坏的，否则我们就没有用锁的必要了，那么我们来看如何破坏其他三个条件。

破坏占用且等待条件

如果要破坏占用且等待条件，我们可以尝试一次性申请全部资源，这样就不需要等待了。

在实现过程中，我们需要创建一个新的角色，负责同时申请和同时释放全部资源，我们可以将其称为Allocator。

我们来看一下具体的代码实现。

public class Allocator {
    
    private volatile static Allocator instance;
    
    private Allocator() {}
    
    public static Allocator getInstance() {
        if (instance == null) {
            synchronized(Allocator.class) {
                if (instance == null) {
                    instance = new Allocator();
                }
            }
        }
        
        return instance;
    }
    
    private Set