摘要：
        在對多線程并發的編程環境下，死鎖是我們經常碰到的和經常需要解決的問題。所謂死鎖，即：由于資源占用是互斥的，當某個線（進）程提出申請資源后，使得有關進程在無外力協助下，永遠分配不到必需的資源而無法繼續運行，這就產生了一種特殊現象死鎖，如下圖：

        線程#1在獲得Lock A后，需要獲得Lock B,而同時，線程#2在Lock B后，需要獲得Lock A。對于線程#1和#2，由于都不能獲得滿足的條件，而無法繼續執行，死鎖就形成了。
        死鎖是多線程并發編程的大難題，我們可以通過Log Trace、多線程編程輔助工具、IDE調試環境等手段進行調試、跟蹤。然而，另一個更難對付的問題是“假死鎖”（我在這里暫且稱為“假死鎖”，實在找不到什么更好的稱呼）。所謂的假死鎖，我給出的定義是：在有限的時間內的死鎖。與死鎖不同的是，其持續的時間是有限的，而大家都知道，死鎖持續的時間是無限的，如果碰到死鎖，程序接下來是什么都干不了了。而正是由于假死鎖的相對的持續時間，給我們編程人員會帶來更大的麻煩。可以想象得到，我們想通過某些工具來Trace這樣一個特定的時間段是非常困難的，更多的情況下，我們需要結合LOG進行合理的分析，使得問題得以解決。本文就假死鎖產生的條件，環境，以及解決的辦法做一個討論。
一、假死鎖的產生條件。

    考慮下面的例子（我只是給給出了偽代碼），假設我們系統中的線程個數是確定的，有限的。在本例中，系統總的線程數目是3。如下圖：

線程#1，#2，#3都可能被調度進入臨界區A,我們假設線程#1執行臨界區A時花費了10s的時間，而在這10s的時間里，線程#2與線程#3都處于等待的狀態。也就是說：在這個10s的時間里，系統是沒法響應任何的其他請求。我們稱之為10s的假死鎖。如果在這段時間里，系統需要一些關鍵的請求被執行，這些關鍵請求是需要real time地被處理，比如說是Timer事件，則后果是不堪設想的。（注意：我們的假定是系統中的線程只有#1,#2,#3)。
       以此，總結一下發生假死鎖的條件，如下：
--〉臨界區的代碼在集中的時間段內，可能被系統中的任意線程執行，完全由操作系統決定。
--〉臨界區的代碼在某些情況下，可能是很耗時的。（比如：其執行時間大于100ms，或者，甚至是秒級別的）
二、在Proactor(IOCP)中的假死鎖。
        在前面的文章中，我提到過在windows平臺上，Proactor設計模式是基于IOCP的。在這里，本文不會用過多的語言來闡述Proactor是怎樣的設計，重點放在Proactor的假死鎖及其一些解決的辦法。另外需要說明的是，我這里所說的Proactor，在技術層面上，等同于IOCP，我們也可以按照IOCP來理解我所闡釋的概念。
        我們都知道，IOCP是靠工作者線程來驅動的。工作者線程與一個完成端口對象相關聯，當IO 請求被投遞到完成端口對象時，這些線程為完成端口服務。需要說明的是，應該創建多少個線程來為完成端口服務，是你的應用設計來決定的（很重要的的一點是：在調用CreateIoCompletionPort時指定的并發線程的個數，和創建的工作者線程的個數是有區別的，詳細的技術細節，請參考其他資料）。但是總的來說，在你的系統交付運行后，工作者線程的線程數目是一個確定的值。其結構圖，大致如下：

         我們假定使用了線程數目為4的工作者線程來為完成端口服務，它們通過調用來GetQueuedCompletionStatus方法來從完成端口中獲取IO相關的packet，一旦獲得，它們都會回調業務邏輯層的代碼來進行相關的業務邏輯處理。到這里我們看到，假設，在業務邏輯層存在臨界互斥區,并且在某一個集中的時間段內，工作者線程都可能被調度執行該臨界互斥區，那么，假死鎖的條件基本形成，如果某一個線程在該區域花費的時間比較長，假死鎖就會發生。
        一般來說，解決這樣的問題的關鍵就是打破形成假死鎖的條件：
       第一、在回調函數里，盡量減少鎖的使用。
       第二、減量減少臨界互斥區的執行時間。對于一些慢速的操作尤其注意。比如：當你在臨界互斥區訪問慢速的IO操作時（打開文件，讀寫文件等），可能需要考慮Cache機制，通過使用內存來代替慢速的disk。
       第三、將臨界互斥區代碼委托給另外獨立的線程（或線程組）執行，代價是增加這些線程間的通訊。
       第四、通過使用流控等手段，避免讓所有的線程在集中的時間段內訪問該臨界互斥區。
三、結束語：
         事實上，類似這樣的問題，一旦存在，是很難發現和調試的。不過對于多線程的編程，我們都應該遵守以下的基本原則，以最大化的防止死鎖和假死鎖的發生。