记一次项目的死锁分析

1.场景

公司项目使用多线程开发，因此使用gdb exec -c corefile运行core文件后，使用bt打印堆栈信息 看不出问题，需要进入到线程内部分析。

2.分析

    1. info threads 打印线程信息

    

可以看到有多个__lll_lock_wait () , 看到这里，我们推测可能是锁出现问题了。那么继续往，进入到线程内部，随便找一个是__lll_lock_wait ()状态的，使用thread（缩写 t）t 639 ，在使用bt查看堆栈

使用frame（错写 f） f 3进入到函数内部，打印函数内部的变量查看是哪个锁被哪个线程锁住了

可以看到 gUserStateInfoLock 被线程 19204 锁住了。在info thread 打印的线程信息可以看到19204 对应的线程号是566，进入到 566 线程内部 t 566，该线程占用了 gUserStateInfoLock

在findCorpInfoNodeByPhoneNu 内部，请求使用g_XmlCorpInfoListLock 锁，该锁被 t 14 占用

t 14 线程占用了g_XmlCorpInfoListLock ，同时又在等待 gUserStateInfoLock，

而gUserStateInfoLock 被19024 这个程序，因此可以断定是发生死锁了。

3 解决

使用了四种解决死锁方式里其中的一种，就是保持枷锁顺序的一致性。线程1使用锁1,和锁2的顺序，那么线程2也应该使用锁1和锁2 的顺序