同步鎖使用的弊端：當線程任務中出現了多個同步(多個鎖)時，如果同步中嵌套了其他的同步。這時容易引發一種現象：程序出現無限等待，這種現象我們稱為死鎖。這種情況能避免就避免掉。 ~~~ synchronzied(A鎖){ synchronized(B鎖){ } } ~~~ 這是一個關于死鎖的問題，代碼如下：  很明顯，這段代碼在多線程情況下，會產生死鎖： 假設線程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) .