日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時(shí)間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
詳解監(jiān)視程序中死鎖的一些處理方法

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

10余年建站經(jīng)驗(yàn)， 網(wǎng)站設(shè)計(jì)制作、網(wǎng)站設(shè)計(jì)客戶的見證與正確選擇。創(chuàng)新互聯(lián)建站提供完善的營銷型網(wǎng)頁建站明細(xì)報(bào)價(jià)表。后期開發(fā)更加便捷高效，我們致力于追求更美、更快、更規(guī)范。

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

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


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


 
但是，這又意味著每個(gè)公開方法內(nèi)部都要使用Lock方法，這和直接使用lock(this.m_mutex)又有什么區(qū)別呢？區(qū)別當(dāng)然是有的，硬要說起來，使用Lock方法意味著“如果某一天”我要把“互斥”這個(gè)條件去掉的話，我只要修改Lock方法一個(gè)就可以了——否則我需要修改所有的公開方法。
當(dāng)然，我覺得就這點(diǎn)理論上的“優(yōu)勢”是不足以修改代碼的，那么我還是繼續(xù)使用MethodImplOptions.Synchronized方式吧。
經(jīng)過了上面這一圈沒有帶來多大價(jià)值的思考之后，我又回憶起今天園子首頁的一篇文章談到死鎖。死鎖很容易出現(xiàn)，例如下面的代碼引發(fā)死鎖的概率幾乎是100%：
 
 
 
    
  
  
  
  1. var mutexA = new object();  
    2.   
  
  
  2. var mutexB = new object();  
    3.   
  
  
  3. ThreadPool.QueueUserWorkItem((_) => 
    4.   
  
  
  4. {  
    5.   
  
  
  5.     lock (mutexA)  
    6.   
  
  
  6.     {  
    7.   
  
  
  7.         Console.WriteLine("Mutex A acquired.");  
    8.   
  
  
  8.         Thread.Sleep(1000);  
    9.   
  
  
  9.  
    10.   
  
  
  10.         Console.WriteLine("Trying to acquire mutex B.");  
    11.   
  
  
  11.         lock (mutexB)  
    12.   
  
  
  12.         {  
    13.   
  
  
  13.             Console.WriteLine("Mutex B acquired.");  
    14.   
  
  
  14.         }  
    15.   
  
  
  15.     }  
    16.   
  
  
  16. });  
    17.   
  
  
  17.  
    18.   
  
  
  18. ThreadPool.QueueUserWorkItem((_) => 
    19.   
  
  
  19. {  
    20.   
  
  
  20.     lock (mutexB)  
    21.   
  
  
  21.     {  
    22.   
  
  
  22.         Console.WriteLine("Mutex B acquired.");  
    23.   
  
  
  23.         Thread.Sleep(1000);  
    24.   
  
  
  24.         Console.WriteLine("Trying to acquire mutex A.");  
    25.   
  
  
  25.         lock (mutexA)  
    26.   
  
  
  26.         {  
    27.   
  
  
  27.             Console.WriteLine("Mutex A acquired.");  
    28.   
  
  
  28.         }  
    29.   
  
  
  29.     }  
    30.   
  
  
  30. }); 
    31.  
 
 


這種情況下兩個(gè)內(nèi)層lock中的代碼都無法執(zhí)行，因?yàn)槊總€(gè)線程都在等待對方釋放才能繼續(xù)下去，這種mutex鎖定順序不一致的情況導(dǎo)致死鎖。那么概括下來，什么情況下會出現(xiàn)死鎖呢？其實(shí)就是：“如果線程A正持有對象a而請求鎖定b，同時(shí)線程B持有b而請求鎖定c，同時(shí)線程C持有c而請求……鎖定a”，無論這個(gè)循環(huán)有多長，其中涉及到多少個(gè)線程，一旦出現(xiàn)這種循環(huán)，則進(jìn)入死鎖。其實(shí)我想任何一本講操作系統(tǒng)的書都會談到到如何檢查死鎖——以及解開死鎖。既然lock語句只能讓我們靜悄悄地等待下去，那么不如由我們自己提供一個(gè)實(shí)現(xiàn)，避免發(fā)生死鎖的情況。例如：
 
 
 
    
  
  
  
  1. public static class Lock  
    2.   
  
  
  2. {  
    3.   
  
  
  3.     public static void With(object mutex, Action action) { ... }  
    4.   
  
  
  4. }  
    5.   
  
  
  5. 　　于是原本使用lock的語句現(xiàn)在就可以變成：  
    6.   
  
  
  6.  
    7.   
  
  
  7. //lock (mutex)  
    8.   
  
  
  8. //{   
    9.   
  
  
  9. //    ...  
    10.   
  
  
  10. //}  
    11.   
  
  
  11.  
    12.   
  
  
  12. Lock.With(mutex, () => 
    13.   
  
  
  13. {  
    14.   
  
  
  14.     ...  
    15.   
  
  
  15. }); 
    16.  
 
 


而在Lock.With方法中，我們除了調(diào)用Monitor.Enter/Exit方法來實(shí)現(xiàn)真正的鎖之外，還需要在Enter之前判斷這個(gè)mutex能否正確獲得。其實(shí)就是查看一點(diǎn)：于此同時(shí)是否有另一個(gè)線程正持有當(dāng)前mutex對象，并且（經(jīng)過一個(gè)“鏈”）也在等待當(dāng)前線程正持有的其他mutex對象。如果出現(xiàn)了這樣的情況，則Lock.With不會調(diào)用Monitor.Enter，而是拋出異常。這樣做肯定是可行的，問題的關(guān)鍵在于如何設(shè)計(jì)一個(gè)方便使用，性能優(yōu)越，并且線程安全的數(shù)據(jù)結(jié)構(gòu)。
可惜，等我興沖沖地回到家，打開電腦，在搜索引擎敲入“.NET Deadlock Detect”之后，卻找到了MSDN Magazine上的兩篇文章——原來又是別人的二手貨?！禔dvanced Techniques To Avoid And Detect Deadlocks In .NET Apps》中講述了檢查和打破死鎖的算法，而《Deadlock monitor》一文中甚至將我想要做的東西完全實(shí)現(xiàn)了出來。簡單的說，這兒已經(jīng)沒我什么事情了。感興趣的朋友們可以閱讀這兩篇文章，提到了實(shí)踐中我考慮到和沒有考慮到的各種細(xì)節(jié)。仔細(xì)研究一遍，相信會有很大幫助的。
當(dāng)然，這種做法只適合在測試環(huán)境中“檢查”是否有可能出現(xiàn)死鎖情況，在實(shí)際情況下這種做法還是非常消耗性能的。不過，我們可以在編譯產(chǎn)品環(huán)境的時(shí)候使用特別的編譯選項(xiàng)，把用于檢查死鎖的代碼給短路掉，這自然就沒有任何問題了。
原文標(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#完全限定名簡單分析
  5. C#數(shù)據(jù)類型簡單介紹
                                                

                                                文章名稱：詳解監(jiān)視程序中死鎖的一些處理方法                                                

                                                文章轉(zhuǎn)載：http://www.5511xx.com/article/dposoio.html