尝试提升并发处理性能。但，出现死锁问题了咋办。
一
向现实世界要答案，用两把细粒度锁解决转账操作串行的问题(见两个转账操作并行示意图)。
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;
}
}
}
}
}
经过优化后，账户 A 转账户 B 和账户 C 转账户 D 这两个转账操作就可以并行了。
二
作者认为，相对于用 Account.class 作为互斥锁，锁定的范围太大，而使用细粒度锁可以提高并行度，是性能优化的一个重要手段。
但是，使用细粒度锁是有代价的，这个代价就是可能会导致死锁。
作者用现实世界转账业务中的“死等”引出了死锁的定义：一组互相竞争资源的线程因互相等待，导致“永久”阻塞的现象。
同时还分析了转账的代码是怎么发生死锁的。
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 会无限地等待下去，也就是我们所说的死锁了。
作者还用转账发生死锁时的资源分配图来可视化了锁的占用情况。
三
作者引用 Coffman 的总结，称以下四个条件都发生时才会出现死锁：
- 互斥，共享资源 X 和 Y 只能被一个线程占用
- 占有且等待，线程 T1 已经取得共享资源 X，在等待共享资源 Y 的时候，不释放共享资源 X
- 不可抢占，其他线程不能强行抢占线程 T1 占有的资源
- 循环等待，线程 T1 等待线程 T2 占有的资源，线程 T2 等待线程 T1 占有的资源，就是循环等待。
作者认为，只要做到以下三点中任意一点，即可规避死锁问题：
- 对于“占用且等待”这个条件，我们可以一次性申请所有的资源，这样就不存在等待了。
- 对于“不可抢占”这个条件，占用部分资源的线程进一步申请其他资源时，如果申请不到，可以主动释放它占有的资源，这样不可抢占这个条件就破坏掉了。
- 对于“循环等待”这个条件，可以靠按序申请资源来预防。所谓按序申请，是指资源是有线性顺序的，申请的时候可以先申请资源序号小的，再申请资源序号大的，这样线性化后自然就不存在循环了。
四
同时申请资源和释放资源
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)
}
}
}
五
synchronized 申请资源的时候，如果申请不到，线程就会直接进入阻塞状态，啥都干不了，也释放不了线程已经占有的资源。
java.util.concurrent 这个包下面提供的 Lock 可以轻松解决这个问题。
六
破坏循环等待这个条件，需要对资源进行排序，然后按序申请资源。
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;
}
}
}
}
}
七
作者认为，用细粒度锁来锁定多个资源时，特别要注意死锁的问题；在选择预防死锁具体方案的时候，还需要评估一下操作成本，从中选择一个成本最低的方案(在转账这个例子中，破坏循环等待条件就是成本最低的一个方案)。
最后还留下了课后思考：破坏占用且等待条件，我们也是锁了所有的账户，而且还是用了死循环 while(!actr.apply(this, target)); 这个方法，那它比 synchronized(Account.class) 有没有性能优势呢？
