并发场景下死锁

案例场景

例如账户A 转账户B、账户C 转账户D这两个转账操作。

class Account {
  private int balance;
  // 转账
  void transfer(Account target, int amt){
    // 锁定转出账户
    synchronized(this){     ①
      // 锁定转入账户
      synchronized(target){ ②
        if (this.balance > amt) {
          this.balance -= amt;
          target.balance += amt;
        }
      }
    }
  } 
}

这种方式采用了细粒度锁。使用细粒度锁可以提高并行度，是性能优化的一个重要手段。

但是会出现一个新的问题就是死锁。

上面转账的代码是怎么发生死锁的呢？我们假设线程T1执行账户A转账户B的操作，账户A.transfer(账户B)；同时线程T2执行账户B转账户A的操作，账户B.transfer(账户A)。当T1和T2同时执行完①处的代码时，T1获得了账户A的锁（对于T1，this是账户A），而T2获得了账户B的锁（对于T2，this是账户B）。之后T1和T2在执行②处的代码时，T1试图获取账户B的锁时，发现账户B已经被锁定（被T2锁定），所以T1开始等待；T2则试图获取账户A的锁时，发现账户A已经被锁定（被T1锁定），所以T2也开始等待。于是T1和T2会无期限地等待下去，也就是我们所说的死锁了。

如何预防死锁

产生死锁的四个必要条件：

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

其中，互斥这个条件我们没有办法破坏，因为我们用锁为的就是互斥。不过其他三个条件都是有办法破坏掉的，到底如何做呢？

• 破坏占用且等待条件

可以一次性申请所有资源，新增一个账本管理员的概念，两个资源只能同时给一个线程。这个管理员只能是一个单例，因为只有一个管理员。

class Allocator {
  private List