如何避免死锁？咱们有套路可循

写在前面

上一篇文章共享资源那么多，如何用一把锁保护多个资源？ 文章咱们谈到了银行转帐经典案例，其中有两个问题:

1. 单纯的用 synchronized 方法起不到保护做用(不能保护 target)
2. 用 Account.class 锁方案，锁的粒度又过大，致使涉及到帐户的全部操做(取款，转帐，修改密码等)都会变成串行操做

如何解决这两个问题呢？我们先换好衣服穿越回到过去寻找一下钱庄，一块儿透过现象看本质，dengdeng deng.......

来到钱庄，告诉柜员你要给铁蛋儿转 100 铜钱，这时柜员转身在墙上寻找你和铁蛋儿的帐本，此时柜员可能面临三种状况:

1. 理想状态: 你和铁蛋儿的帐本都是空闲状态，一块儿拿回来，在你的帐本上减 100 铜钱，在铁蛋儿帐本上加 100 铜钱，柜员转身将帐本挂回到墙上，完成你的业务
2. 尴尬状态: 你的帐本在，铁蛋儿的帐本被其余柜员拿出去给别人转帐，你要等待其余柜员把铁蛋儿的帐本归还
3. 抓狂状态: 你的帐本不在，铁蛋儿的帐本也不在，你只能等待两个帐本都归还

放慢柜员的取帐本操做，他必定是先拿到你的帐本，而后再去拿铁蛋儿的帐本，两个帐本都拿到(理想状态)以后才能完成转帐，用程序模型来描述一下这个拿取帐本的过程:

咱们继续用程序代码描述一下上面这个模型:

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

这个解决方案看起来很完美，解决了文章开头说的两个问题，但真是这样吗？

---

咱们刚刚说过的理想状态是钱庄只有一个柜员(既单线程)。随着钱庄规模变大，墙上早已挂了很是多个帐本，钱庄为了应对繁忙的业务，开通了多个窗口，此时有多个柜员(多线程)处理钱庄业务。

柜员 1 正在办理给铁蛋儿转帐的业务，但只拿到了你的帐本；柜员 2 正在办理铁蛋儿给你转帐的业务，但只拿到了铁蛋儿的帐本，此时双方出现了尴尬状态，两位柜员都在等待对方归还帐本为当前客户办理转帐业务。

现实中柜员会沟通，喊出一嗓子 老铁，铁蛋儿的帐本先给我用一下，用完还给你，但程序却没这么智能，synchronized 内置锁很是执着，它会告诉你「死等」的道理，最终出现死锁

Java 有了 synchronized 内置锁，还发明了显示锁 Lock，是否是就为了治一治 synchronized 「死等」的执着呢？😏

解决方案

如何解决上面的问题呢？正所谓知己知彼方能百战不殆，咱们要先了解什么状况会发生死锁，才能知道如何避免死锁，很幸运咱们能够站在巨人的肩膀上看待问题

Coffman 总结出了四个条件说明能够发生死锁的情形:

Coffman 条件

互斥条件：指进程对所分配到的资源进行排它性使用，即在一段时间内某资源只由一个进程占用。若是此时还有其它进程请求资源，则请求者只能等待，直至占有资源的进程用毕释放。

请求和保持条件：指进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对本身已得到的其它资源保持不放。

不可剥夺条件：指进程已得到的资源，在未使用完以前，不能被剥夺，只能在使用完时由本身释放。

环路等待条件：指在发生死锁时，必然存在一个进程——资源的环形链，即进程集合{P1，P2，···，Pn}中的 P1 正在等待一个 P2 占用的资源；P2 正在等待 P3 占用的资源，……，Pn 正在等待已被 P0 占用的资源。

这几个条件很好理解，其中「互斥条件」是并发编程的根基，这个条件没办法改变。但其余三个条件都有改变的可能，也就是说破坏另外三个条件就不会出现上面说到的死锁问题

破坏请求和保持条件

每一个柜员均可以取放帐本，很容易出现互相等待的状况。要想破坏请求和保持条件，就要一次性拿到全部资源。

做为程序猿你必定听过这句话:

任何软件工程遇到的问题均可以经过增长一个中间层来解决

咱们不容许柜员均可以取放帐本，帐本要由单独的帐本管理员来管理

也就是说帐本管理员拿取帐本是临界区，若是只拿到其中之一的帐本，那么不会给柜员，而是等待柜员下一次询问是否两个帐本都在

//帐本管理员
public class AccountBookManager {
    synchronized boolean getAllRequiredAccountBook( Object from, Object to){
        if(拿到全部帐本){
            return true;
        } else{
            return false;
        }
    }
    // 归还资源
    synchronized void releaseObtainedAccountBook(Object from, Object to){
        归还获取到的帐本
    }
}


public class Account {
    //单例的帐本管理员
    private AccountBookManager accountBookManager;

    public void transfer(Account target, int amt){
        // 一次性申请转出帐户和转入帐户，直到成功
        while(!accountBookManager.getAllRequiredAccountBook(this, target)){
            return;
        }

        try{
            // 锁定转出帐户
            synchronized(this){
                // 锁定转入帐户
                synchronized(target){
                    if (this.balance > amt){
                        this.balance -= amt;
                        target.balance += amt;
                    }
                }
            }
        } finally {
            accountBookManager.releaseObtainedAccountBook(this, target);
        }
    }
}

破坏不可剥夺条件

上面已经给了你小小的提示，为了解决内置锁的执着，Java 显示锁支持通知(notify/notifyall)和等待(wait)，也就是说该功能能够实现喊一嗓子 老铁，铁蛋儿的帐本先给我用一下，用完还给你 的功能，这个后续将到 Java SDK 相关内容时会作说明

破坏环路等待条件

破坏环路等待条件也很简单，咱们只须要将资源序号大小排序获取就会解决这个问题，将环路拆除

继续用代码来讲明:

class Account {
  private int id;
  private int balance;
  // 转帐
  void transfer(Account target, int amt){
    Account smaller = this        
    Account larger = target;    
    // 排序
    if (this.id > target.id) { 
      smaller = target;           
      larger = this;            
    }                          
    // 锁定序号小的帐户
    synchronized(smaller){
      // 锁定序号大的帐户
      synchronized(larger){ 
        if (this.balance > amt){
          this.balance -= amt;
          target.balance += amt;
        }
      }
    }
  } 
}

当 smaller 被占用时，其余线程就会被阻塞，也就不会存在死锁了.

附加说明

在实际业务中，关于 Account 都会是数据库对象，咱们能够经过事务或数据库的乐观锁来解决的。另外分布式系统中，帐本管理员这个角色的处理也可能会用 redis 分布式锁来解决.

在处理破坏请求和保持条件时，咱们使用的是 while 循环方式来不断请求锁的时候，在实际业务中，咱们会有 timeout 的设置，防止无休止的浪费 CPU 使用率

另外你们能够尝试使用阿里开源工具 Arthas 来查看 CPU 使用率，线程等相关问题，github 上有明确的说明

总结

计算机的计算能力远远超过人类，可是他的智慧还须要有带提升，当看待并发问题时，咱们每每认为人类的最基本沟通计算机也能够作到，其实否则，仍是那句话，编写并发程序，要站在计算机的角度来看待问题

粗粒度锁咱们不提倡，因此会使用细粒度锁，但使用细粒度锁的时候，咱们要严格按照 Coffman 的四大条件来逐条判断，这样再应用咱们这几个解决方案来解决就行了

灵魂追问

1. 破坏请求和保持条件时，处理能力的瓶颈在帐本管理员那里，那你以为这种处理方式会提升并发量吗？
2. 破坏请求保持条件的方法和破坏环路等待的方法，你以为那种方式更好
3. 破坏请求和保持条件时，若是代码换成下面的样子会发生什么？

public void transfer(Account target, int amt){
    // 一次性申请转出帐户和转入帐户，直到成功
    while(accountBookManager.getAllRequiredAccountBook(this, target)){}
        try{
            // 锁定转出帐户
            synchronized(this){
                // 锁定转入帐户
                synchronized(target){
                    if (this.balance > amt){
                        this.balance -= amt;
                        target.balance += amt;
                    }
                }
            }
        } finally {
            accountBookManager.releaseObtainedAccountBook(this, target);
        }
    }
}

提升效率工具

---

1. 此次走进并发的世界，请不要错过
2. 学并发编程，透彻理解这三个核心是关键
3. 并发Bug之源有三，请睁大眼睛看清它们
4. 可见性有序性，Happens-before来搞定
5. 解决原子性问题？你首先须要的是宏观理解
6. 面试并发volatile关键字时，咱们应该具有哪些谈资？

---

欢迎关注个人公众号 「日拱一兵」，趣味原创解析Java技术栈问题，将复杂问题简单化，将抽象问题图形化落地
若是对个人专题内容感兴趣，或抢先看更多内容，欢迎访问个人博客 dayarch.top