C++死锁问题定位与分析
C++程序异常一般有两种表现形式：程序崩溃和程序无响应。程序崩溃主要是由指针，数组越界等原因引起，这种情况可以直接通过在程序中加入Dump捕捉逻辑，分析dump文件，定位出崩溃的代码。程序无响应主要是由死循环和死锁两个原因造成的，死循环我们可以通过查看CPU使用情况来初步判断，然后转存为Dump进行分析；死锁问题是C++中最难定位和分析的一种程序异常问题，下面我们主要介绍下死锁问题的一般定位和分析方法。
一，测试代码
在介绍死锁分析方法之前，先看一下本文中我们使用的测试代码：
CRITICAL_SECTION cs1;
CRITICAL_SECTION cs2;
DWORD WINAPI Thread1(LPVOID lpParameter);
DWORD WINAPI Thread2(LPVOID lpParameter);
int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
//初始化关键代码段
InitializeCriticalSection(&cs1);
InitializeCriticalSection(&cs2);
//创建线程
HANDLE hThread1 = CreateThread(NULL, 0, Thread1, NULL, 0, NULL);
HANDLE hThread2 = CreateThread(NULL, 0, Thread2, NULL, 0, NULL);
//等待线程结束
WaitForSingleObject(hThread1, INFINITE);
WaitForSingleObject(hThread2, INFINITE);
Sleep(2000);
//关闭线程句柄
CloseHandle(hThread1);
CloseHandle(hThread2);
//释放关键代码段
DeleteCriticalSection(&cs1);
DeleteCriticalSection(&cs2);
return 0;
}
DWORD WINAPI Thread1(LPVOID lpParameter)
{
for (int i = 0; i < 10; i++)
{
EnterCriticalSection(&cs1);
Sleep(500);
EnterCriticalSection(&cs2);
std::cout << "Thread1" << std::endl;
LeaveCriticalSection(&cs2);
LeaveCriticalSection(&cs1);
}
return 1;
}
DWORD WINAPI Thread2(LPVOID lpParameter)
{
for (int i = 0; i < 10; i++)
{
EnterCriticalSection(&cs2);
Sleep(500);
EnterCriticalSection(&cs1);
std::cout << "Thread2" << std::endl;
LeaveCriticalSection(&cs1);
LeaveCriticalSection(&cs2);
}
return 1;
}
在这个例子中，Thread1等待Thread2，Thread2等待Thread1，同时主线程等待着Thread1和Thread2，三个线程陷入死锁状态。
二，等待链
等待链是线程和同步对象的交替序列;每个线程都在等待它后面的对象，该对象由链中的后续线程拥有。通过分析等待链，我们可以清晰地看到各个子线程/子进程挂起所在等待的下一个线程/进程。（等待链更多知识请转至Wait Chain Traversal）
在《Windows核心编程》一书附带的源码09-LockCop中，详细介绍了WCT的编码实现，感兴趣的可以去阅读一下源码，附上下载链接（Windows核心编程(第5版中文版) 源码）。编译09-LockCop，我们可以得到09-LockCop.exe应用程序，打开改程序，选择我们的进程DeadLockTest.exe，分析如下：
线程8248等待线程9524，9524在等待6432，而6432又在等待9524，陷入了互相等待的处境中，导致死锁。因此可以确认DeadLockTest.exe的无响应是由死锁造成的。
我们也可以直接通过windows的任务管理器来检测一个程序是否陷入死锁，打开任务管理器-性能-资源监视器，选中我们的测试程序，右键菜单“分析等待链”：
分析结果如下：
可以看到9524线程与6432线程陷入了互相等待锁资源的处境，程序死锁。
三，死锁的定位和分析
如果死锁的程序刚好在我们自己的开发机器上，那么使用WinDbg的Attach To A Proccess功能将死锁程序直接附加到WinDbg中进行分析；如果不在我们的机器上，可以通过Windows的资源管理器对进行进行创建转储文件转换为dump（注意32位和64位的区别），再通过WinDbg对dump进行分析。为了方便，我们直接以Attach方式讲解。
Attach程序后，输入!locks命令查看锁的状态：
总共有两个锁cs1（012e4394）和cs2（012e437c），这两个锁的LockCount（表示还有多少个线程在等待这个临界区）都为1，说明这两个锁都处于等待状态。
再输入~*kb查看一下当前各个线程的堆栈：
线程2534和线程1920都处于等待状态，线程2534等待锁012e437c，线程1920等待锁012e4394。再结合上面的锁信息可以知道，锁012e4394被线程2534拥有，锁012e437c被线程1920拥有，所以这两个线程陷入了互相等待的死锁中。等待锁的源码也直接定位到了，问题解决。
本文举例比较简单，主要是介绍死锁问题的定位以及分析的一般方法，具体问题还要视情况具体分析。