1死鎖發生的條件
當且僅當以下四個條件同時成立時，死鎖才會發生：
1) 互斥。同乙個資源在同一時刻最多只能被乙個程序占用。
2) 占有並等待。必然有乙個程序至少占用了系統中的乙個資源，同時在等待獲取被其他程序占用的資源。
3) 不可剝奪。乙個程序不能剝奪被其他程序占用的資源。
4) 迴圈等待。在等待圖中有乙個迴圈。
2 處理死鎖的策略
有三種處理死鎖的策略:
1) 預防死鎖。限制請求,保證前文提到的四個死鎖條件中至少有乙個不能發生, 從而預防死鎖；
2) 避免死鎖。如果結果狀態是安全的, 就將資源動態地分給程序。如果至少有乙個執行串行使所有的程序都能完成執行, 那麼這個狀態就是安全的；
3) 檢測死鎖和從死鎖中恢復, 允許死鎖發生, 然後發現並解除死鎖。
死鎖預防和避免採用一種悲觀方法，即認為死鎖會經常發生並試圖阻止或避免它。雖然死鎖避免策略在集中式系統中廣為應用，並且有許多演算法，但是在分布式系統中很少使用。這是因為在分布式系統中沒有全域性時鐘，檢查安全性狀態會涉及到大量程序和資源的計算，從而引起昂貴的開銷。死鎖檢測和恢復使用樂觀方法，然而這種方法對於死鎖發生頻繁的應用程式可能並不有效。
3 死鎖的and條件和or條件
一般地，有兩種死鎖：資源死鎖和通訊死鎖。在通訊死鎖中，程序等待的資源就是報文。資源死鎖和通訊死鎖的真正區別在於資源死鎖通常使用and條件，而通訊死鎖通常使用or條件。所謂and條件就是當程序取得所有所需資源時，它才能繼續執行；所謂or條件就是當程序得到至少乙個所需資源，它就能繼續執行。由於多數分布式控制結構是不確定的，乙個程序可能在等待來自多個程序的報文，而不能確定將被收到的報文究竟來自那個程序，需要每收到乙個報文就進行處理，所以通訊死鎖使用or條件。
在使用and條件的系統中，死鎖條件是在等待圖中存在迴路。但是在使用or條件的系統中，等待圖中的迴路未必會引發死鎖。在使用or條件的系統中，死鎖條件是存在結(knot)。
4 死鎖的預防
死鎖預防演算法通過限制程序的資源請求方法來預防死鎖。死鎖預防通常通過下列方法之一來實現。它們都基於打破四個死鎖條件中的一種：
1)靜態分配資源。要求程序必須在開始執行前就申請它所需要的全部資源，並且只有當系統能滿足程序的資源申請要求並把資源分配給程序之後，該程序才開始執行。這種策略可以預防死鎖的發生是由於其破壞了「占有且等待資源」和「迴圈等待資源」的條件，從而系統中的所有程序必然不會發生死鎖。
2)按序分配資源。在系統中的每乙個資源都會給出乙個編號。分配資源的時候作了以下規定：任何程序在申請兩個以上資源時，總是按照編號的大小順序申請。這種策略可以預防死鎖的發生是由於其破壞了「迴圈等待資源」的條件，從而系統中的所有程序必然不會發生死鎖。
3)剝奪式分配資源。當乙個程序申請資源得不到滿足時，可從另乙個擁有這種資源的程序那裡去搶奪，然後繼續執行。這種策略可以預防死鎖的發生是由於其破壞了「非搶奪式分配」的條件，從而系統中的所有程序必然不會發生死鎖。
4.1 等待-死亡方案（wait-die scheme）
4.2 傷害-等待方案（wound-wait scheme）
它是一種基於剝奪的方法。當程序pi請求的資源正被程序pj占有時，只有當程序pi的時間戳比程序pj的時間戳大時，即pi比pj年輕時，pi才能等待。否則pj被卷回（roll-back），即死亡。只要被卷回的程序重新啟動時，使用原有的時間戳，這兩種方案都能避免死鎖和餓死現象。由於時間戳總是增加的，被卷回的程序最終將具有最小的時間戳。
5 死鎖的檢測
為了降低系統開銷，在分配資源時會不加限制，只要系統中有剩餘的資源，總是把資源分配給申請者。顯然，這樣的結果是可能會出現死鎖。那麼，為了使系統能夠正常工作，在系統中會採用定時執行乙個「死鎖檢測」程式的方法，當檢測到死鎖時該程式將會設法將其排除。在分布式系統中的死鎖檢測法不會造成很多不必要的程序流產，但是也會增加了系統的額外開銷和複雜度。
5.1集中式死鎖檢測
在分布式系統中，每個站點都有乙個本地死鎖檢測程式，其任務是判斷在其站點所有潛在的全域性死鎖；其方法是：在站點的輸入埠開始，沿本地等待圖反向搜尋，如果最終會搜尋到輸出埠，就說明具有潛在的全域性死鎖。
5.2分布式死鎖檢測
分布式死鎖檢測和集中式的主要差別是：在集中式方案中全部潛在的死鎖迴圈都傳送給某個指定的站點，而在分布式檢測方案中則沒有這種站點。分布式死鎖檢測機構中沒有本地和非本地死鎖檢測程式的任何區別，每個站點具有同樣的責任。在分布式方案中，死鎖檢測程式需要一種規則來決定應該把潛在的死鎖迴圈傳送給哪個站點，這種規則必須保證能最終檢測到全域性死鎖，並且必須盡量減小傳送的資訊量。
（1）路徑推動演算法（path-pushing algorithm）。先在每個機器上建立形式簡單的全域性等待圖。每當進行死鎖檢測時，各個機器就將等待圖的拷貝送往一定數量的鄰居節點。區域性拷貝更新後又被傳播下去。這一過程重複進行直到某個節點獲得了足夠的資訊來構造乙個等待圖以便做出是否存在死鎖的結論。不幸的是，這類演算法中的許多演算法在實際中是錯誤的。主要原因是傳輸過程中的部分等待圖並不能代表整個全域性等待圖，因為各個節點採集資料的方法是非同步的。
（2）邊跟蹤演算法（edge-chasing algorithm）。分布式網路結構圖中的迴路可以通過沿圖的邊傳播一種叫探測器的特殊資訊來檢測。當乙個發起者得到乙個與自己傳送的探測器相匹配的探測器時，它就知道它在圖中的乙個迴路裡。
（3）擴散計算（diffusing computation）。懷疑有死鎖發生時，事務管理器通過向依賴於它的程序傳送查詢啟動乙個擴散程序。這裡不會生成全域性等待圖。傳送查詢資訊時，擴散計算就增長；接收回答後，擴散計算就縮減。根據所得資訊，發起者會檢測到死鎖的發生。典型情況是，擴散程序動態地生成等待圖的乙個子樹。
（4）全域性狀態檢測（global state detection）。這個方法基於chandy和lamport 的快照方法。可以通過建立乙個一致的全域性狀態而無需暫停當前的計算來生成乙個一致的全域性等待圖。
分布式系統中的分布式事務
分布式事務中可以借助mq訊息系統來進行事務控制，這一點與可靠訊息最終一致方案一樣。看來mq中介軟體確實在乙個分布式系統架構中，扮演者重要的角色。最大努力通知方案是比較簡單的分布式事務方案，它本質上就是通過定期校對，實現資料一致性。中介軟體如何保證訊息的一致性 問題的問法多種多樣，怎麼保證兩個伺服器的...
分布式資料庫系統中的死鎖處理
在分布式環境下，由於通訊延遲的不確定性 地域的分布性以及資源和資料的高度共享性等影響因素的存在，使得死鎖預防和檢測變得極為困難。在分布式計算系統中，有兩個以上的程序在併發執行，每個程序都在等待被其它的程序所占用的系統資源而不能繼續執行，即導致系統中任何乙個程序都無法執行下去 死迴圈 這就產生了死鎖。...
分布式系統session處理
分布式系統中同乙個使用者的請求可能會被分發到不同的伺服器上，而session是儲存在單個伺服器上，所以有可能會導致session失效,對於前端使用者最明顯的感覺就是需要重新登入。主要有如下幾種解決方案 1.session sticky 方式 由負載均衡來負責標記每次的請求,將同乙個會話請求傳送到同乙...