死鎖場景描述： 
        針對之前一個版本反饋回來的問題，對資料通訊模組升級，做了精簡和重構

        因為ABA問題的存在，將之前以Socket為key改為以只增的Int為key。使用的鎖為臨界區鎖。

        修改完成，聯調後進行壓力測試，發現當後臺的執行緒池滿的時候會必然發生死鎖。

死鎖定位過程：

    第一步：精簡執行緒模型，將授權檢測執行緒、超時檢測等輔助執行緒通通遮蔽。

    大壓力測試，仍然死鎖。

    第二步: 在第一步的基礎上，將通訊工作執行緒減到1個。

    大壓力測試，仍然死鎖。

     因為涉及模組比較多，為了快速定位問題，使用windbg來檢測死鎖點

     第三步：使用windbg

      當應用程式掛死後，使用windbg Attach到程序。

      1. 使用 ~*kb，檢視堆疊資訊

   8  Id: 368.bd4 Suspend: 1 Teb: 7ffd6000 Unfrozen ChildEBP RetAddr  Args to Child               0614fd4c 7c92df5a 7c939b23 00000604 00000000 ntdll!KiFastSystemCallRet 0614fd50 7c939b23 00000604 00000000 00000000 ntdll!NtWaitForSingleObject+0xc 0614fdd8 7c921046 0012fe08 5f401b5f 0012fe08 ntdll!RtlpWaitForCriticalSection+0x132 0614fde0 5f401b5f 0012fe08 0012fdfc 0614fedc ntdll!RtlEnterCriticalSection+0x46 0614fdf0 0040b207 ffffffff 77d2b326 03103ee0 MFC42D!CCriticalSection::Lock+0x14 0614fedc 5f438514 0012fd30 ffffffff 77d2b326 RecExtraction!CRecExtractionModule::ThreadAnalysis+0x185 [G:\Code\vc2012\VSIP\DigitalViewer_V1\RecExtraction\RecExtractionModule.cpp @ 331] 0614ff80 1020c323 0012f4f4 ffffffff 77d2b326 MFC42D!_AfxThreadEntry+0x2c4 0614ffb4 7c80b729 03103ee0 ffffffff 77d2b326 MSVCRTD!_beginthreadex+0x133 0614ffec 00000000 1020c2b0 03103ee0 00000000 kernel32!BaseThreadStart+0x37 
 

       其中，上圖中的8是執行緒編號，368是程序ID，bd4是執行緒ID。
      可以看到ntdll!NtWaitForSingleObject ，沒有拿到鎖，說明死鎖發生了。

0614fd4c 7c92df5a 7c939b23 00000604 00000000 ntdll!KiFastSystemCallRet
0614fd50 7c939b23 00000604 00000000 00000000 ntdll!NtWaitForSingleObject+0xc
0614fdd8 7c921046 0012fe08 5f401b5f 0012fe08 ntdll!RtlpWaitForCriticalSection+0x132
這裡的第一個是ebp,第二個是返回函式地址，接下來才是函式的引數。
 

     要看下比如 ntdll!NtWaitForSingleObject引數定義：

NTSTATUS WINAPI NtWaitForSingleObject( 
  _In_  HANDLE Handle, 
  _In_  BOOLEAN Alertable, 
  _In_  PLARGE_INTEGER Timeout 
); 

    所以 00000604 00000000 00000000分別對應上面的Handle,Alrtable,Timeout.

    如上所述，handle是00000604，

!cs 00000604     

再看一個網上的例子：

0:004> ~1kb
ChildEBP RetAddr  Args to Child             
0051fe48 7c92df5a 7c939b23 00000034 00000000 ntdll!KiFastSystemCallRet
0051fe4c 7c939b23 00000034 00000000 00000000 ntdll!NtWaitForSingleObject+0xc
0051fed4 7c921046 00417140 00411420 00417140 ntdll!RtlpWaitForCriticalSection+0x132
*** WARNING: Unable to verify checksum for D:\Project1\test2\Debug\test2.exe
0051fedc 00411420 00417140 00000000 00000000 ntdll!RtlEnterCriticalSection+0x46
0051ffb4 7c80b729 00000000 00000000 00000000 test2!thread1+0x50 [d:\project1\test2\test2\test2.cpp @ 10]
0051ffec 00000000 00411122 00000000 00000000 kernel32!BaseThreadStart+0x37
0:004> !cs 00417140
-----------------------------------------
Critical section   = 0x00417140 (test2!cs2+0x0)
DebugInfo          = 0x7c99ea00
LOCKED
LockCount          = 0x2
OwningThread       = 0x00001f60
RecursionCount     = 0x1
LockSemaphore      = 0x34
SpinCount          = 0x00000000

可以看出該臨界區的持有者（OwningThread）是 0x00001f60

這個地址是執行緒在核心中的ID，需要轉換為使用者態的ID，使用~~[]命令。

~~[執行緒核心id]

0:003> ~~[0x0000185c]
        2  Id: 1a98.185c Suspend: 1 Teb: 7ffdd000 Unfrozen
         Start: test2+0x1030 (00401030)
         Priority class: 32; Affinity: f

通過轉換，可以看到鎖的持有者是2號執行緒。

這樣就可以很明確的找到鎖的持有者了，如果pdb載入正確，通過~2kb就已經可以對應到程式碼行了。

查詢死鎖很困難，但是一旦找到點，解決起來就容易多了。

以上的例子部分來自網貼，在此對原作者表示感謝。

---------------------------------

對於死鎖的小結：

1. 對上層提供的函式，需要通過設計，規避操作帶鎖。

2.在鎖中避免呼叫回撥，因為回撥的操作不可預知，易發生死鎖。