一.死鎖
經典的「哲學家進餐」問題很好地描述了死鎖狀況。5個哲學家去吃中餐，坐在-張圓桌旁。他們有5根筷子(而不是5雙)，並且每兩個人中間放一根筷子。哲學家們時而思考，時而進餐。每個人都需要- -雙筷子才能吃到東西，並在吃完後將筷子放回原處繼續思考。有些筷子管理演算法能夠使每個人都能相對及時地吃到東西(例如乙個飢餓的哲學家會嘗試獲得兩根鄰近的筷子，但如果其中一根正在被另乙個哲學家使用，那麼他將放棄已經得到的那根筷子，並等待幾分鐘之後再次嘗試)，但有些演算法卻可能導致一些或者所有哲學家都「餓死」(每個人都立即抓住自己左邊的筷子，然後等待自己右邊的筷子空出來，但同時又不放下已經拿到的筷子)。後一種情況將產生死鎖:每個人都擁有其他人需要的資源，同時又等待其他人已經擁有的資源，並且每個人在獲得所有需要的資源之前都不會放棄已經擁有的資源。
1.鎖順序死鎖
下面程式中的leftrightdeadlock存在死鎖風險。leftright 和rightleft這兩個方法分別獲得left鎖和right鎖。如果- 乙個執行緒呼叫了leftright, 而另-乙個執行緒呼叫了rightleft, 並且這兩個執行緒的操作是交錯執行，如下圖所示，那麼它們會發生死鎖。
}2.動態的鎖順序死鎖
有時候，並不能清楚地知道是否在鎖順序上有足夠的控制權來避免死鎖的發生。考慮下面程式中看似無害的**，它將資金從-乙個賬戶轉入另-乙個賬戶。在開始轉賬之前，首先要獲得這兩個account物件的鎖，以確保通過原子方式來更新兩個賬戶中的餘額，同時又不破壞- -些不變性條件，例如「賬戶的餘額不能為負數」。
public在transfermoney中如何發生死鎖?所有的執行緒似乎都是按照相同的順序來獲得鎖，但事實上鎖的順序取決於傳遞給transfermoney的引數順序，而這些引數順序又取決於外部輸人。如果兩個執行緒同時呼叫transfermoney,其中-乙個執行緒從x向y轉賬，另乙個執行緒從y向x轉賬，那 麼就會發生死鎖。class
dynamicorderdeadlock }}
}}
3.在協作物件之間發生的死鎖
4.開放呼叫
5.資源死鎖
二.死鎖的避免與診斷
1.支援定時的鎖
三.其他活躍性危險
1.飢餓
活躍性危險
經典的 哲學家進餐 問題就很好的描述了死鎖的狀況 死鎖的成因 如果每個人都擁有其他人需要的資源，但是同時又等待其他人已經擁有的資源，並且每個人在獲取所有需要的資源之前都不會放棄已經擁有的資源 發生死鎖的原因 兩個執行緒試圖以不同的順序來獲得相同的鎖。解決辦法 如果按照相同的順序請求鎖，那麼就不會出現...
第十章 避免活躍性危險
1.死鎖 檢測死鎖 在等待關係的有向圖中搜尋迴圈。產生死鎖的4個必要條件 1 互斥條件 共享資源獨佔訪問 2 不可剝奪條件 不能強制其他執行緒釋放資源 3 請求和保持條件 在等待申請的新的資源時，繼續占有已分配的資源 4 迴圈等待條件 發生死鎖時，存在乙個迴圈等待的佇列 p1等待p2占有的資源，p2...
多執行緒 7 執行緒安全性，活躍性，效能問題
安全性 資料競爭 多個執行緒同時訪問乙個資料，並且至少有乙個執行緒會寫這個資料。競態條件 程式的執行結果依賴程式執行的順序。也可以按照以下的方式理解競態條件 程式的執行依賴於某個狀態變數，在判斷滿足條件的時候執行，但是在執行時其他變數同時修改了狀態變數。if 狀態變數 滿足 執行條件 活躍性 死鎖 ...