Java并发5:死锁
上篇文章中转账加锁使用了Account.class，实际开发中肯定不可行。性能上无法接受，需采用更细粒度的锁。
采用细粒度锁带来问题
采用细粒度锁优化性能
即在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;
}
}
}
}
}产生死锁
死锁：一组互相竞争资源的线程因互相等待，导致“永久”阻塞的现象。
上面代码会产生死锁，A向B转账，B向A转账时。
- A进入第6行锁定了对象A，B进入第6行锁定了对象B。
- A进入第8行尝试获取对象B，B进入第8行尝试获取对象A。
- 此时A和B都占有了对方想要获取的资源，产生了阻塞。
死锁
死锁：一组互相竞争资源的线程因互相等待，导致“永久”阻塞的现象。
死锁产生的条件
- 互斥，共享资源X和Y只能被一个线程占用。
- 占有且等待，线程 T1 已经取得共享资源 X，在等待共享资源 Y 的时候，不释放共享资源 X；
- 不可抢占，其他线程不能强行抢占线程 T1 占有的资源；
- 循环等待，线程 T1 等待线程 T2 占有的资源，线程 T2 等待线程 T1 占有的资源，就是循环等待。
避免死锁
破坏上述任意条件。
互斥这个条件没有办法破坏，因为用锁为的就是互斥。
对于“占用且等待”，可以一次性申请所有的资源，这样就不存在等待了。
对于“不可抢占”，占用部分资源的线程进一步申请其他资源时，如果申请不到，可以主动释放它占有的资源。
note:可能出现活锁问题，要等待随机时间。
对于“循环等待”，可以按序申请资源。按序申请，是指资源是有线性顺序的，申请的时候可以先申请资源序号小的，再申请资源序号大的，这样线性化后自然就不存在循环了。
具体方法
破坏占有且等待条件
一次性申请所有资源，通过类
Allocator一次性申请，申请到了返回true。线程执行
transfer()方法时循环判断直到申请到了所有必须的资源，再进行转账。
class Allocator {
private List<Object> als = new ArrayList<>();
// 一次性申请所有资源，多个线程同时申请，加锁保证apply()方法对外部表现原子性
synchronized boolean apply(Object from, Object to){
//如果als集合中有任意一个资源，说明Allocator已经完成了所有资源的申请
if(als.contains(from) || als.contains(to)){
return false;
} else {
//als集合一个资源都没有，进行添加。
als.add(from);
als.add(to);
}
//申请资源完毕，返回true
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是做不到的。原因是synchronized申请资源的时候，如果申请不到，线程直接进入阻塞状态，而线程进入阻塞状态，啥都干不了，也释放不了线程已经占有的资源。java.util.concurrent这个包下面提供的Lock可以解决，见XXX。破坏循环等待条件
破坏这个条件，需要对资源进行排序，然后按序申请资源。
假设每个账户都有不同的属性
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;
}
}
}
}
}总结
用细粒度锁来锁定多个资源时，要注意死锁的问题。
需要能把它强化为一个思维定势，遇到这种场景，马上想到可能存在死锁问题。
当知道风险之后，才有机会谈如何预防和避免，因此，识别出风险很重要。
转账例子中，破坏占用且等待条件的成本就比破坏循环等待条件的成本高。
破坏占用且等待条件，也是锁了所有的账户，而且还是用了死循环while(!actr.apply(this, target));方法，不过好在 apply() 这个方法基本不耗时。
转账例子中，破坏循环等待条件就是成本最低的一个方案。
所以在选择具体方案的时候，还需要评估一下操作成本，从中选择一个成本最低的方案。
思考
while(!actr.apply(this, target));与synchronized(Account.class) 有无性能优势呢？
前者只锁了转账操作，后者锁了账户所有操作。
别人的总结
老师，请问一下，在实际的开发中，account对象应该是从数据库中查询出来的吧，假如A转B，C转B一起执行，那B的account对象如何保证是同一个对象，不太理解。。。
——几字凉了秋丶
实际开发中都是用数据库事务+乐观锁的方式解决的。这个就是个例子，为了说明死锁是怎么回事，以及死锁问题怎么解决。
——作者
老师，感觉下面的代码也能避免死锁，并且能实现功能：
>void transfer(Account target, int amt){ boolean isTransfer = false; >// 锁定转出账户 synchronized(this){ if (this.balance > amt) { this.balance -= amt; isTransfer = true; } if (!isTransfer) { return; } // 锁定转入账户 synchronized(target){ target.balance += amt; } }反映到现实中的场景：服务员A拿到账本1先判断余额够不够，够的话先扣款，再等待其他人操作完账本2，才增加它的额度。
但是这样转账和到账就存在一个时差，现实生活中也是这样，转账不会立马到账，短信提醒24小时内到账，所谓的最终一致性。
老师帮忙看看这样实现会不会有啥其他问题？
——Bright丶
实际中也有这么做的，只不过是把转入操作放到mq里，mq消费失败会重试，所以能保证最终一致性。
——作者
