詳解監視程序中死鎖的一些處理方法
監視程序主要是用來監控是否出現死鎖等情況，但是這種.NET監視程序一般只能在測試中使用，如果大范圍使用，很可能造成性能的下降。
每天回家路上總有一段比較長的路一片漆黑無法看書。這種時候，如果我有興致則會用手機上上網，但是大部分情況下還是用來想問題的。剛才在路上想起今天的工作之一是讓一個類型中的所有方法對多線程“完全互斥”——我不知道如何為它命名，我的意思是一個類中任意兩個方法A或B，在A沒有退出前，另一個線程是無法訪問B的（當然也無法訪問A）。最簡單的方式應該是把每個方法標記為：
- [MethodImpl(MethodImplOptions.Synchronized)]
- public void SomeMethod() { ... }
但是這意味著每進入一個方法，都會自動lock(方法所在的類型)，鎖定這樣一個公開對象（甚至還是跨AppDomain的）自然不是一個好的做法。更好的做法是聲明一個私有變量，然后對它進行lock。但是這意味著每個方法都需要用lock包含，我嫌麻煩，不知怎么又想嘗試著使用一個公用的Lock方法，并傳入一個Action對象，這樣lock語句就只出現一次了：
- private object m_mutex = new object();
- private void Lock(Action action) { lock (this.m_mutex) action(); }
但是，這又意味著每個公開方法內部都要使用Lock方法，這和直接使用lock(this.m_mutex)又有什么區別呢？區別當然是有的，硬要說起來，使用Lock方法意味著“如果某一天”我要把“互斥”這個條件去掉的話，我只要修改Lock方法一個就可以了——否則我需要修改所有的公開方法。
當然，我覺得就這點理論上的“優勢”是不足以修改代碼的，那么我還是繼續使用MethodImplOptions.Synchronized方式吧。
經過了上面這一圈沒有帶來多大價值的思考之后，我又回憶起今天園子首頁的一篇文章談到死鎖。死鎖很容易出現，例如下面的代碼引發死鎖的概率幾乎是100%：
- var mutexA = new object();
- var mutexB = new object();
- ThreadPool.QueueUserWorkItem((_) =>
- {
- lock (mutexA)
- {
- Console.WriteLine("Mutex A acquired.");
- Thread.Sleep(1000);
- Console.WriteLine("Trying to acquire mutex B.");
- lock (mutexB)
- {
- Console.WriteLine("Mutex B acquired.");
- }
- }
- });
- ThreadPool.QueueUserWorkItem((_) =>
- {
- lock (mutexB)
- {
- Console.WriteLine("Mutex B acquired.");
- Thread.Sleep(1000);
- Console.WriteLine("Trying to acquire mutex A.");
- lock (mutexA)
- {
- Console.WriteLine("Mutex A acquired.");
- }
- }
- });
這種情況下兩個內層lock中的代碼都無法執行，因為每個線程都在等待對方釋放才能繼續下去，這種mutex鎖定順序不一致的情況導致死鎖。那么概括下來，什么情況下會出現死鎖呢？其實就是：“如果線程A正持有對象a而請求鎖定b，同時線程B持有b而請求鎖定c，同時線程C持有c而請求……鎖定a”，無論這個循環有多長，其中涉及到多少個線程，一旦出現這種循環，則進入死鎖。其實我想任何一本講操作系統的書都會談到到如何檢查死鎖——以及解開死鎖。既然lock語句只能讓我們靜悄悄地等待下去，那么不如由我們自己提供一個實現，避免發生死鎖的情況。例如：
- public static class Lock
- {
- public static void With(object mutex, Action action) { ... }
- }
- 于是原本使用lock的語句現在就可以變成：
- //lock (mutex)
- //{
- // ...
- //}
- Lock.With(mutex, () =>
- {
- ...
- });
而在Lock.With方法中，我們除了調用Monitor.Enter/Exit方法來實現真正的鎖之外，還需要在Enter之前判斷這個mutex能否正確獲得。其實就是查看一點：于此同時是否有另一個線程正持有當前mutex對象，并且（經過一個“鏈”）也在等待當前線程正持有的其他mutex對象。如果出現了這樣的情況，則Lock.With不會調用Monitor.Enter，而是拋出異常。這樣做肯定是可行的，問題的關鍵在于如何設計一個方便使用，性能優越，并且線程安全的數據結構。
可惜，等我興沖沖地回到家，打開電腦，在搜索引擎敲入“.NET Deadlock Detect”之后，卻找到了MSDN Magazine上的兩篇文章——原來又是別人的二手貨。《Advanced Techniques To Avoid And Detect Deadlocks In .NET Apps》中講述了檢查和打破死鎖的算法，而《Deadlock monitor》一文中甚至將我想要做的東西完全實現了出來。簡單的說，這兒已經沒我什么事情了。感興趣的朋友們可以閱讀這兩篇文章，提到了實踐中我考慮到和沒有考慮到的各種細節。仔細研究一遍，相信會有很大幫助的。
當然，這種做法只適合在測試環境中“檢查”是否有可能出現死鎖情況，在實際情況下這種做法還是非常消耗性能的。不過，我們可以在編譯產品環境的時候使用特別的編譯選項，把用于檢查死鎖的代碼給短路掉，這自然就沒有任何問題了。
原文標題：監視程序中的死鎖及其他
鏈接：http://www.cnblogs.com/JeffreyZhao/archive/2009/09/10/dotnet-deadlock-detect.html
【編輯推薦】
