監(jiān)視程序主要是用來(lái)監(jiān)控是否出現(xiàn)死鎖等情況，但是這種.NET監(jiān)視程序一般只能在測(cè)試中使用，如果大范圍使用，很可能造成性能的下降。

每天回家路上總有一段比較長(zhǎng)的路一片漆黑無(wú)法看書。這種時(shí)候，如果我有興致則會(huì)用手機(jī)上上網(wǎng)，但是大部分情況下還是用來(lái)想問(wèn)題的。剛才在路上想起今天的工作之一是讓一個(gè)類型中的所有方法對(duì)多線程“完全互斥”——我不知道如何為它命名，我的意思是一個(gè)類中任意兩個(gè)方法A或B，在A沒(méi)有退出前，另一個(gè)線程是無(wú)法訪問(wèn)B的（當(dāng)然也無(wú)法訪問(wèn)A）。最簡(jiǎn)單的方式應(yīng)該是把每個(gè)方法標(biāo)記為：

[MethodImpl(MethodImplOptions.Synchronized)]  
public void SomeMethod() { ... } 

但是這意味著每進(jìn)入一個(gè)方法，都會(huì)自動(dòng)lock(方法所在的類型)，鎖定這樣一個(gè)公開(kāi)對(duì)象（甚至還是跨AppDomain的）自然不是一個(gè)好的做法。更好的做法是聲明一個(gè)私有變量，然后對(duì)它進(jìn)行l(wèi)ock。但是這意味著每個(gè)方法都需要用lock包含，我嫌麻煩，不知怎么又想嘗試著使用一個(gè)公用的Lock方法，并傳入一個(gè)Action對(duì)象，這樣lock語(yǔ)句就只出現(xiàn)一次了：

private object m_mutex = new object();  
private void Lock(Action action) { lock (this.m_mutex) action(); } 

但是，這又意味著每個(gè)公開(kāi)方法內(nèi)部都要使用Lock方法，這和直接使用lock(this.m_mutex)又有什么區(qū)別呢？區(qū)別當(dāng)然是有的，硬要說(shuō)起來(lái)，使用Lock方法意味著“如果某一天”我要把“互斥”這個(gè)條件去掉的話，我只要修改Lock方法一個(gè)就可以了——否則我需要修改所有的公開(kāi)方法。

當(dāng)然，我覺(jué)得就這點(diǎn)理論上的“優(yōu)勢(shì)”是不足以修改代碼的，那么我還是繼續(xù)使用MethodImplOptions.Synchronized方式吧。

經(jīng)過(guò)了上面這一圈沒(méi)有帶來(lái)多大價(jià)值的思考之后，我又回憶起今天園子首頁(yè)的一篇文章談到死鎖。死鎖很容易出現(xiàn)，例如下面的代碼引發(fā)死鎖的概率幾乎是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.");  
        }  
    }  
}); 

這種情況下兩個(gè)內(nèi)層lock中的代碼都無(wú)法執(zhí)行，因?yàn)槊總€(gè)線程都在等待對(duì)方釋放才能繼續(xù)下去，這種mutex鎖定順序不一致的情況導(dǎo)致死鎖。那么概括下來(lái)，什么情況下會(huì)出現(xiàn)死鎖呢？其實(shí)就是：“如果線程A正持有對(duì)象a而請(qǐng)求鎖定b，同時(shí)線程B持有b而請(qǐng)求鎖定c，同時(shí)線程C持有c而請(qǐng)求……鎖定a”，無(wú)論這個(gè)循環(huán)有多長(zhǎng)，其中涉及到多少個(gè)線程，一旦出現(xiàn)這種循環(huán)，則進(jìn)入死鎖。其實(shí)我想任何一本講操作系統(tǒng)的書都會(huì)談到到如何檢查死鎖——以及解開(kāi)死鎖。既然lock語(yǔ)句只能讓我們靜悄悄地等待下去，那么不如由我們自己提供一個(gè)實(shí)現(xiàn)，避免發(fā)生死鎖的情況。例如：

public static class Lock  
{  
    public static void With(object mutex, Action action) { ... }  
}  
　　于是原本使用lock的語(yǔ)句現(xiàn)在就可以變成：  
 
//lock (mutex)  
//{   
//    ...  
//}  
 
Lock.With(mutex, () => 
{  
    ...  
}); 

而在Lock.With方法中，我們除了調(diào)用Monitor.Enter/Exit方法來(lái)實(shí)現(xiàn)真正的鎖之外，還需要在Enter之前判斷這個(gè)mutex能否正確獲得。其實(shí)就是查看一點(diǎn)：于此同時(shí)是否有另一個(gè)線程正持有當(dāng)前mutex對(duì)象，并且（經(jīng)過(guò)一個(gè)“鏈”）也在等待當(dāng)前線程正持有的其他mutex對(duì)象。如果出現(xiàn)了這樣的情況，則Lock.With不會(huì)調(diào)用Monitor.Enter，而是拋出異常。這樣做肯定是可行的，問(wèn)題的關(guān)鍵在于如何設(shè)計(jì)一個(gè)方便使用，性能優(yōu)越，并且線程安全的數(shù)據(jù)結(jié)構(gòu)。

可惜，等我興沖沖地回到家，打開(kāi)電腦，在搜索引擎敲入“.NET Deadlock Detect”之后，卻找到了MSDN Magazine上的兩篇文章——原來(lái)又是別人的二手貨?！?A >Advanced Techniques To Avoid And Detect Deadlocks In .NET Apps》中講述了檢查和打破死鎖的算法，而《Deadlock monitor》一文中甚至將我想要做的東西完全實(shí)現(xiàn)了出來(lái)。簡(jiǎn)單的說(shuō)，這兒已經(jīng)沒(méi)我什么事情了。感興趣的朋友們可以閱讀這兩篇文章，提到了實(shí)踐中我考慮到和沒(méi)有考慮到的各種細(xì)節(jié)。仔細(xì)研究一遍，相信會(huì)有很大幫助的。

當(dāng)然，這種做法只適合在測(cè)試環(huán)境中“檢查”是否有可能出現(xiàn)死鎖情況，在實(shí)際情況下這種做法還是非常消耗性能的。不過(guò)，我們可以在編譯產(chǎn)品環(huán)境的時(shí)候使用特別的編譯選項(xiàng)，把用于檢查死鎖的代碼給短路掉，這自然就沒(méi)有任何問(wèn)題了。

原文標(biāo)題：監(jiān)視程序中的死鎖及其他

鏈接：http://www.cnblogs.com/JeffreyZhao/archive/2009/09/10/dotnet-deadlock-detect.html

【編輯推薦】

1. C#線程同步與死鎖
2. 如何分析Java虛擬機(jī)死鎖
3. Java和C#頂層聲明概述
4. C#完全限定名簡(jiǎn)單分析
5. C#數(shù)據(jù)類型簡(jiǎn)單介紹