死锁问题调试-思路分析

今儿晚上碰到一死锁问题，之前定位没定位出来，讨论问题时被人指出来了，感觉很羞愧。

记录下，下次碰到类似死锁要有思路。

咱们死锁一般有两种情况，

1.线程A和线程B相互死锁。这种情况下，通过堆栈查找两个等待锁之间的依赖关系，还是比较好确定的。

2.线程A自死锁，造成这种死锁的情况是自己加了锁之后，还没来得及释放，下次又继续等锁，而这种锁刚好又不是递归锁，就会出现自死锁的情况。

针对于情况一：

一般思路，还是用gdb观察当前线程快照，如果现在功能卡住，而且gdb几次快照都在某个预期很快获取到锁的地方等锁，那么基本能确定是死锁。 那么，第二步就应该是获取该锁的ownerID，看这把锁到底是被哪个线程持有。ok，问题来了，如果这个时候gdb看不到ownerID，原因有很多(比如给你的就只有一个gdb快照，但是已经被定位为死锁，现场已经被破坏了，而且很难复现)怎么办？那么只好根据堆栈来查代码了，看上一层堆栈进入时，有进入什么锁。。。一层一层查，看能否能查到和另外那个互死锁的锁进锁的地方。好吧，我承认这个方法很low。

针对情况二：

猜想的原因有两种，一种是自己这段代码中在加锁后真的就没有完成锁释放，而且下次还能继续执行到加锁进入的代码入口。第二种，是锁的加锁和释放锁确实成对了，但是在加锁后，有可能被中断，而中断执行的中断函数(或者信号函数)也有这边锁的进入，就会造成自死锁。

很不幸，我今儿碰到的是第二种。而且只看到了堆栈，没法用gdb查看堆栈内变量的值，现场也已经被