一不小心就死锁了——怎么办？

上一篇文章中，用Account.class做互斥锁来解决银行中的转账问题，虽然不存在并发问题但是所有操操作都是串行的，其实在现实世界里是可以并行的，使用串行操作导致性能太差。。

互联网支付盛行的现在，如果所有的交易操作都是串行的那么性能完全不能接受。。

下面尝试将性能进行优化。。

向现实世界要答案

现实世界里，账户转账操作是支持并发的而且绝对是真正的并行，银行所有窗口都可以做转账。只要能仿照现实世界做转账操作，串行的问题就可以解决。

试想古代，账户存在形式是每个账户有一个账本，统一存放在文件架上。转账时转出和转入账本都要拿到，拿账本可能遇到三种情况：

1. 文件架上恰好有转出转入账本，可以同时拿走。
2. 只有转出和转入的一本，先把有的拿走，同时等着将另外一个账本拿回来
3. 都没有，等着两个账本都送回来

上面的过程在编程中只需要两把锁就实现了，在transfer()方法内部，首先尝试锁定转出账户this（先把转出账本拿到手），然后尝试锁定转入账户target（再把转入账本拿到手），只有当两者都成功时，才执行转账操作。这个逻辑可以图形化为下图这个样子：

代码如下，经过优化后，转账操作就可以并行了。

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;
				}
			}
		}
	}
}

没有免费的午餐

上面的操作相对于用Account.class作为互斥锁，锁定的范围太大，而锁定两个账户范围就小多了，这样的锁上一篇文章介绍过，叫细粒度锁。使用细粒度锁可以提高并行度，是性能优化的一个重要手段。

使用细粒度锁是有代价的，这个代价就是可能会导致死锁。

现实世界里的死等，就是编程领域的死锁了。死锁的一个比较专业的定义是：一组互相竞争资源的线程因互相等待，导致“永久”阻塞的现象。

假设线程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会无期限地等待下去，也就是我们所说的死锁了。

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;
				}
			}
		}
	}
}

关于这种现象，还可以借助资源分配图来可视化锁的占用情况（资源分配图是个有向图，它可以描述资源和线程的状态）。其中资源用方形节点表示，线程用圆形节点表示；资源中的点指向线程的边表示线程已经获得该资源，线程指向资源的边则表示线程请求资源，但尚未得到。转账发生死锁时的资源分配图就如下图所示，一个“各据山头死等”的尴尬局面。。

如何预防死锁

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

那如何避免死锁呢？要避免死锁就需要分析死锁发生的条件，有个叫Coffman的牛人早就总结过了，只有以下这四个条件都发生时才会出现死锁：

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

反过来分析，就是说只要我们破坏其中一个，就可以成功避免死锁的发生。

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

1. 对于“占用且等待”这个条件，我们可以一次性申请所有的资源，这样就不存在等待了。
2. 对于“不可抢占”这个条件，占用部分资源的线程进一步申请其他资源时，如果申请不到，可以主动释放它占有的资源，这样不可抢占这个条件就破坏掉了
3. 对于“循环等待”这个条件，可以靠按序申请资源来预防。所谓按序申请，是指资源是有线性顺序的，申请的时候可以先申请资源序号小的，再申请资源序号大的，这样线性化后自然就不存在循环了。

1、破坏占用且等待条件

从理论上讲，要破坏这个条件，可以一次性申请所有资源。在现实世界里，当这两个账户同时被申请时，我们该怎么解决这个问题呢？

可以增加一个账本管理员，然后只允许账本管理员从文件架上拿账本，也就是说柜员不能直接在文件架上拿账本，必须通过账本管理员才能拿到想要的账本。例如，张三同时申请账本A和B，账本管理员如果发现文件架上只有账本A，这个时候账本管理员是不会把账本A拿下来给张三的，只有账本A和B都在的时候才会给张三。这样就保证了“一次性申请所有资源”。

编程中，同时申请”这个操作是一个临界区，我们也需要一个角色（Java里面的类）来管理这个临界区，我们就把这个角色定为Allocator。它有两个重要功能，分别是：同时申请资源apply()和同时释放资源free()。账户Account 类里面持有一个Allocator的单例（必须是单例，只能由一个人来分配资源）。当账户Account在执行转账操作的时候，首先向Allocator同时申请转出账户和转入账户这两个资源，成功后再锁定这两个资源；当转账操作执行完，释放锁之后，需要通知Allocator同时释放转出账户和转入账户这两个资源。具体的代码实现如下。

class Allocator {
	private List<Object> als =
		new ArrayList<>();
	// ⼀次性申请所有资源
	synchronized boolean apply(
		Object from, Object to){
		if(als.contains(from) ||
				als.contains(to)){
			return false;
		} else {
		als.add(from);
		als.add(to);
		} 
		return true;
	} 
	/ /归还资源
	synchronized void free(
		Object from, Object to){
		als.remove(from);
		als.remove(to);
		}
	}
	class Account {
		// actr应该为单例
		private Allocator actr;
		private int balance;
		// 转账
		void transfer(Account target, int amt){
			// ⼀次性申请转出账⼾和转⼊账⼾， 直到成功
			while(!actr.apply(this, target))
				；
			try{
				// 锁定转出账⼾
				synchronized(this){
					// 锁定转⼊账⼾
					synchronized(target){
						if (this.balance > amt){
							this.balance -= amt;
							target.balance += amt;
						}
					}
				}
			} finally {
			actr.free(this, target)
			}
		}
}

2、破坏不可抢占条件

核心是要能够主动释放它占有的资源，这一点synchronized是做不到的。
原因是synchronized申请资源的时候，如果申请不到，线程直接进入阻塞状态了，而线程入阻塞状态，什么都无法做也释放不了线程已经占有的资源。

Java在语言层次确实没有解决这个问题，不过在SDK层面还是解决了的java.util.concurrent这个包下面提供的Lock是可以轻松解决这个问题的。

3、破坏循环等待条件

破坏这个条件，需要对资源进行排序，然后按序申请资源。这个实现非常简单，我们假设每个账户都有不同的属性id，这个id可以作为排序字段，申请的时候可以按照从小到大的顺序来申请。比如下面代码中，①~⑥处的代码对转出账户（this）和转入账户（target）排序，然后按照序号从小到大的顺序锁定账户。这样就不存在“循环”等待了。

class Account {
	private int id;
	private int balance;
	// 转账
	void transfer(Account target, int amt){
		Account left = this ①
		Account right = target; ②
		if (this.id > target.id) { ③
			left = target; ④
			right = this; ⑤
		} ⑥
		// 锁定序号⼩的账⼾
		synchronized(left){
			// 锁定序号⼤的账⼾
			synchronized(right){
				if (this.balance > amt){
					this.balance -= amt;
					target.balance += amt;
				}
			}
		}
	}
}