Question

前些天周杰让我看了一段代码， 让我觉得学习一下基础的知识还是挺重要的， 对理解代码有很大帮助。

这是一个关于死锁的问题，代码如下：

很明显，这段代码在多线程情况下，会产生死锁：

假设线程 1 做的操作是账户 A 给账户 B 转账， 先锁住了 A 账户， 接下来试图申请 B 账户的锁，

与此同时线程 2 在从 账户 B 给账户 A 转账， 先锁住了 B 账户的锁， 接下来试图申请 A 账户的锁。

两个线程各自持有资源， 然后等待获取对方的资源， 都无法执行下去， 死锁就出现了。

怎么写代码才能避免这种死锁呢？下面的代码是一种解决办法：

这段代码看起来有点吃力，但是如果你学过操作系统对死锁的处理的话， 就变的很容易。

操作系统中的理论是这样的： 如果有多个线程对多个资源进行访问时， 需要对资源进行排序（排序的方法你自己确定）， 然后所有的线程都按同样的次序来访问资源，这样就不会出现环路等待了。

例如有 10 个线程， 每个都要访问多个资源， 对资源排序以后， 大家都先锁住 1 号资源进行访问（注意同一时刻，只有一个线程能获得锁，别的都得等待) 然后是 2 号， 3 号。。。

由于大家访问的次序是一样的， 就不会出现死锁的的情况。

理解了这一点， 对于上面的代码就很容易理解了， 实际就是对 Account(账户) 进行资源的排序， 通过 Java 内置的方法，得到 Hashcode。 然后按顺序访问。

如果 fromAccount 比较小， 那就先锁住 fromAccount, 然后锁住 toAccount, 反过来也是类似。

假设线程 1 做的操作是账户 A 给账户 B 转账， 先锁住了 A 账户（假设 A 的 hashcode 比较小）， 接下来试图申请 B 账户的锁，

与此同时线程 2 在从 账户 B 给账户 A 转账， 由于 A 的 hashcode 较小， 这个线程也试图先申请 A 的锁， 当然它申请不到， 因为已经被线程 1 持有了， 线程 2 只能等待

等到线程 1 完成操作以后， 线程 2 才能继续， 死锁就消除了。

如果两个账号的 hashCode 相等怎么办， 没办法，只好引用一个第三方的锁了解决了， 这就是上述代码的 else 分支 synchronized(lock) .

所以你看， 那些基础的理论还是挺重要的，的确是前辈们总结出来的精华， 学会了以后， 你看问题的角度和眼界就不同了。