strace命令，是Linux提供的跟踪系统调用的命令，需要sudo或root权限，可以查看进程(线程)使用的系统调用。

基本用法：sudo strace -p 进程号

如果一个线程递归获取同一个锁，或者多个线程以不同的顺序获取多个锁，那么就会导致至少有一个线程在持有锁的情况下再次等待在一个锁上(持有的锁和等待的锁可能相同或不同)，导致死锁(deadlock)。

这时，至少有一个线程会等在futex()系统调用上，可以使用strace命令查看具体哪个线程等在哪个锁上。

看图中的例子，线程函数thread()连续两次调用pthread_mutex_lock()加锁g_mutex，导致递归死锁。

这时它等在futex系统调用上，等待的锁是g_mutex。

如果main函数里打开注释的pthread_join，那么是等不到子线程返回的。

假设程序的文件名是a.out，在死锁后：

1，首先使用ps -ef | grep a.out 查看所有的名字叫a.out的进程，如图。

进程号2992的就是a.out，随后的2609表示的是父进程，即启动它的shell进程的pid。

2，使用top -H -p 2992查看该进程下的所有线程，这里只有2个线程，其中与2992同号的是主线程。

top -H -p 进程号，可以查看所有的线程，其中%CPU显示该线程的CPU使用率，越活跃的线程这个值越大。

这里只是为了获取所有的线程号。

3，然后用sudo strace -p 线程号，去跟踪它的系统调用。

2992调用了nanosleep ()函数，纳秒休眠，与我们在函数里写的while (1) sleep(1);代码相符合。

2993则调用了futex()函数，且等待的锁的地址是0x557a41002040。

4，这时，可以在锁的初始化的地方，打印锁的地址，这里是main函数的第24行，打印的地址对应的锁为g_mutex。

然后我们可以查看代码里使用了g_mutex加锁的地方，可以确定是16、17行的两次加锁导致的。

这么几行代码，是写不出这问题的:(

只有代码复杂起来之后，在一定条件下概率触发的死锁，才是实际项目里的常见情况。

这时，strace命令直接确定死锁的线程和锁的地址的作用，才可以发挥出来。

只要在步骤4的调试信息中打印了可能导致死锁的锁地址，在问题再次出现时就可以用strace跟踪到目标锁的变量，进而查到错误代码的位置。

像上图那么一改，是不是BUG就不显眼了:( 捂脸

main函数第43行的continue会跳过45行的解锁，导致第40行递归死锁，和thread函数的第19行死锁。

它是个概率问题，因为100是1000的因子，只有thread线程把g_count++到正好是100的倍数，然后在它下一次++之前main线程获取了锁，执行到第42行的if条件，才会出现continue越过45行的解锁，然后死锁。

下图的ctrl+c卡断的地方，就是出现了死锁的例子。

PS：如果把第42行的100改成500，降低if成立的概率，那么死锁的概率会降低。

如果在thread函数的while循环里加usleep睡眠，那么相当于提高了main函数获得锁的成功率，死锁的概率会提高。

这两个办法可以在调试时采用。

用户态程序，其实不怎么怕死锁，而是怕该锁的时候没锁，把malloc申请的内存破坏了，导致下一次不知道哪里free或malloc的时候程序挂了。

这属于多线程+竞争条件+野指针，C语言里最无语的BUG之一。

另一个是内核的自旋锁死锁，只要锁住一块CPU，就会锁住所有CPU，然后printk()打印不了信息了。

举报/反馈