1.避免活躍度危險
安全性和活躍度通常相互牽制。使用鎖來保證線程安全，但是濫用鎖可能引起鎖順序死鎖；使用線程池和信號量來約束資源的使用，但是卻可能使活動形成資源死鎖
死鎖
當一個線程永遠佔有一個鎖，而其他線程嘗試去獲得這個鎖，那麼它們將永遠被阻塞。當線程A佔有鎖L時，想要獲得鎖M，但是同時，線程B持有鎖M，並嘗試獲得鎖L，兩個線程將永遠等待下去。這種情況是死鎖最簡單的形式（致命的擁抱，deadly embrace）。發生在多個線程因環路的鎖依賴關係而永遠等待的情況下。與很多其他的併發危險相同，死鎖很少能被立即發現。一個類如果有發生死鎖的潛在可能並不意味着死鎖每次都將發生，它只發生在該發生的時候。當死鎖出現的時候，往往是遇到了最不幸的時候----在高負載之下。
DB系統的避免死鎖設計：一個事務（transaction）可能需要獲取鎖，並可能一直持有這些鎖，直到所有事務都提交。DB的處理：當DB監測到一個事務集發生了死鎖（通過在表示==正在等待（is-waiting-for）==關係的有向圖上搜索循環），它會選擇一個犧牲者，使它退出事務。這個犧牲者釋放的資源，使得其他事務能夠繼續進行。應用程序可以重新執行那個被強行退出的事務，現在這個事務可能就能夠成功完成了，因爲所有跟它競爭資源的事務都已經完成了。
JVM的處理：當一個Java線程集發生死鎖時，“遊戲”到此結束—這些線程永遠不能再使用了。根據線程完成的不同工作，application可能完全停止或特定子系統停止，可能是性能收到影響。恢復application健康的唯一方式就是中止並重啓，然後寄希望於不要再發生同樣的事情。
避免和診斷死鎖
