首页 > 其他分享 >死锁问题案例分析解决

死锁问题案例分析解决

时间：2024-12-31 18:27:36浏览次数：3  
标签：std __ thread lock 案例 死锁 mutex 解决 线程

死锁问题案例分析解决

        死锁的问题经常会考察到，面对哪些情况下会程序会发生死锁的问题，与其想着怎么把书上的理论背出来，不如从实践的角度举例说明，如何对死锁的问题进行分析定位，然后找到问题点进行修改。

        当我们的程序运行时，出现假死的现象，有可能是程序死循环了，有可能是程序等待的I/O、网络事件没发生导致程序阻塞了，也有可能是程序死锁了，下面举例说明在Linux系统下如何分许我们程序的死锁问题。

示例：
        当一个程序的多个线程获取多个互斥锁资源的时候，就有可能发生死锁问题，比如线程A先获取了锁1，线程B获取了锁2，进而线程A还需要获取锁2才能继续执行，但是由于锁2被线程B持有还没有释放，线程A为了等待锁2资源就阻塞了；线程B这时候需要获取锁1才能往下执行，但是由于锁1被线程A持有，导致A也进入阻塞。

        线程A和线程B都在等待对方释放锁资源，但是它们又不肯释放原来的锁资源，导致线程A和B一直互相等待，进程死锁了。下面代码示例演示这个问题：

#include <iostream>           //std::cout
#include <thread>             //std::thread
#include <mutex>              //std::mutex, std::unique_lock
#include <condition_variable> //std::condition_variable
#include <vector>

//锁资源1
std::mutex mtx1;
//锁资源2
std::mutex mtx2;

//线程A的函数
void taskA()
{
	//保证线程A先获取锁1
	std::lock_guard<std::mutex> lockA(mtx1);
	std::cout << "线程A获取锁1" << std::endl;

	//线程A睡眠2s再获取锁2，保证锁2先被线程B获取，模拟死锁问题的发生
	std::this_thread::sleep_for(std::chrono::seconds(2));

	//线程A先获取锁2
	std::lock_guard<std::mutex> lockB(mtx2);
	std::cout << "线程A获取锁2" << std::endl;

	std::cout << "线程A释放所有锁资源，结束运行！" << std::endl;
}

//线程B的函数
void taskB()
{
	//线程B先睡眠1s保证线程A先获取锁1
	std::this_thread::sleep_for(std::chrono::seconds(1));
	std::lock_guard<std::mutex> lockB(mtx2);
	std::cout << "线程B获取锁2" << std::endl;

	//线程B尝试获取锁1
	std::lock_guard<std::mutex> lockA(mtx1);
	std::cout << "线程B获取锁1" << std::endl;

	std::cout << "线程B释放所有锁资源，结束运行！" << std::endl;
}
int main()
{
	//创建生产者和消费者线程
	std::thread t1(taskA);
	std::thread t2(taskB);

	//main主线程等待所有子线程执行完
	t1.join();
	t2.join();

	return 0;
}

        可以看到，线程A获取锁1、线程B获取锁2以后，进程就不往下继续执行了，一直等待在这里，如果这是我们碰到的一个问题场景，我们如何判断出这是由于线程间死锁引起的呢？

先通过ps命令查看一下进程当前的运行状态和PID

root@lin-virtual-machine:/home/liu# ps -aux | grep a.out
liu 1953 0.0 0.0 98108 1904 pts/0 Sl+ 10:41 0:00 ./a.out
root 2064 0.0 0.0 21536 1076 pts/1 S+ 10:51 0:00 grep --color=auto a.out

         从上面的命令可以看出，a.out进程的PID是1953，当前状态是Sl+，相当于是多线程程序，全部进入阻塞状态。
通过top命令再查看一下进程内每个线程具体的运行情况

root@lin-virtual-machine:/home/liu# top -Hp 1953

进程 USER PR NI VIRT RES SHR CPU %MEM TIME+ COMMAND
1953 liu 20 0 98108 1904 1752 S 0.0 0.1 0:00.00 a.out
1954 liu 20 0 98108 1904 1752 S 0.0 0.1 0:00.00 a.out
1955 liu 20 0 98108 1904 1752 S 0.0 0.1 0:00.00 a.out

        从top命令的打印信息可以看出，所有线程都进入阻塞状态，CPU占用率都为0.0，可以排除是死循环的问题，因为死循环会造成CPU使用率居高不下，而且线程的状态也不会是S。那么接下来有可能是由于I/O网络事件没有发生使线程阻塞，或者是线程发生死锁问题了。

        通过gdb远程调试正在运行的程序，打印进程每一个线程的调用堆栈信息，过程如下：
通过gdb attach pid远程调试上面的a.out进程，命令如下：

root@liu-virtual-machine:/home/liu# gdb attach 1953

进入gdb调试命令行以后，打印所有线程的调用栈信息，信息如下：
(gdb) thread apply all bt
Thread 3 (Thread 0x7feb523ec700 (LWP 1955)):
#0 _llllock_wait () at …/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1 0x00007feb53928023 in __GI___pthread_mutex_lock (mutex=0x5646aabe7140 ) at …/nptl/pthread_mutex_lock.c:78
#2 0x00005646aa9e40bf in __gthread_mutex_lock(pthread_mutex_t*) ()
#3 0x00005646aa9e4630 in std::mutex::lock() ()
#4 0x00005646aa9e46ac in std::lock_guardstd::mutex::lock_guard(std::mutex&) ()
#5 0x00005646aa9e42c0 in taskB() ()
#6 0x00005646aa9e4bdb in void std::__invoke_impl)()>(std::__invoke_other, void (&&)()) ()
#7 0x00005646aa9e49e8 in std::__invoke_result)()>::type std::__invoke<void ()()>(void (&&)()) ()
#8 0x00005646aa9e50b6 in decltype (__invoke((_S_declval<0ul>)())) std::thread::_Invoker<std::tuple<void ()()> >::_M_invoke<0ul>(std::_Index_tuple<0ul>) ()
#9 0x00005646aa9e5072 in std::thread::_Invoker)()> >::operator()() ()
#10 0x00005646aa9e5042 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void ()()> > >::_M_run() ()
#11 0x00007feb5365257f in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#12 0x00007feb539256db in start_thread (arg=0x7feb523ec700) at pthread_create.c:463
#13 0x00007feb530ad88f in clone () at …/sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7feb52bed700 (LWP 1954)):
#0 _llllock_wait () at …/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1 0x00007feb53928023 in __GI___pthread_mutex_lock (mutex=0x5646aabe7180 ) at …/nptl/pthread_mutex_lock.c:78
#2 0x00005646aa9e40bf in __gthread_mutex_lock(pthread_mutex_t*) ()
#3 0x00005646aa9e4630 in std::mutex::lock() ()
#4 0x00005646aa9e46ac in std::lock_guardstd::mutex::lock_guard(std::mutex&) ()
#5 0x00005646aa9e4183 in taskA() ()
#6 0x00005646aa9e4bdb in void std::__invoke_impl)()>(std::__invoke_other, void (&&)()) ()
#7 0x00005646aa9e49e8 in std::__invoke_result)()>::type std::__invoke<void ()()>(void (&&)()) ()
#8 0x00005646aa9e50b6 in decltype (__invoke((_S_declval<0ul>)())) std::thread::_Invoker<std::tuple<void ()()> >::_M_invoke<0ul>(std::_Index_tuple<0ul>) ()
#9 0x00005646aa9e5072 in std::thread::_Invoker)()> >::operator()() ()
#10 0x00005646aa9e5042 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void ()()> > >::_M_run() ()
#11 0x00007feb5365257f in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#12 0x00007feb539256db in start_thread (arg=0x7feb52bed700) at pthread_create.c:463
#13 0x00007feb530ad88f in clone () at …/sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7feb53d4b740 (LWP 1953)):
—Type to continue, or q to quit—
#0 0x00007feb53926d2d in __GI___pthread_timedjoin_ex (threadid=140648682280704, thread_return=0x0, abstime=0x0,
block=) at pthread_join_common.c:89
#1 0x00007feb536527d3 in std::thread::join() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#2 0x00005646aa9e43bb in main ()
(gdb)

        从上面的线程调用栈信息可以看到，当前进程有三个线程，分别是Thread1是main线程，Thread2是taskA线程，Thread3是taskB线程。

        从调用栈信息可以看到，Thread3线程进入S阻塞状态的原因是因为它最后在#0 _llllock_wait () at，也就是它在等待获取一把锁(lock_wait)，而且堆栈信息打印的很清晰，#1 0x00007feb53928023 in __GI___pthread_mutex_lock (mutex=0x5646aabe7140 ) at …/nptl/pthread_mutex_lock.c:78，Thread3在获取而获取不到，因此进入阻塞状态了。这里结合代码分析，Thread3线程（也就是taskB）最后在这里阻塞了：

void taskB()
{undefined
//线程B先睡眠1s保证线程A先获取锁1
std::this_thread::sleep_for(std::chrono::seconds(1));
std::lock_guardstd::mutex lockB(mtx2);
std::cout << "线程B获取锁2"<< std::endl;
//线程B尝试获取锁1
std::lock_guardstd::mutex lockA(mtx1); //===》 这里阻塞了！如果不知道怎么定位到源代码行上，看下一小节！
std::cout << "线程B获取锁1" << std::endl;
std::cout << "线程B释放所有锁资源，结束运行！" << std::endl;
}

        依然是从调用栈信息可以看到，Thread2线程进入S阻塞状态的原因是因为它最后在#0 _llllock_wait () at，也就是它在等待获取一把锁(lock_wait)，而且堆栈信息打印的很清晰，#1 0x00007feb53928023 in __GI___pthread_mutex_lock (mutex=0x5646aabe7180 ) at …/nptl/pthread_mutex_lock.c:78，Thread2在获取而获取不到，因此进入阻塞状态了。这里结合代码分析，Thread2线程（也就是taskA）最后在这里阻塞了：

void taskA()
{undefined
// 保证线程A先获取锁1
std::lock_guardstd::mutex lockA(mtx1);
std::cout << "线程A获取锁1"<< std::endl;
// 线程A睡眠2s再获取锁2，保证锁2先被线程B获取，模拟死锁问题的发生
std::this_thread::sleep_for(std::chrono::seconds(2));
// 线程A先获取锁2
std::lock_guardstd::mutex lockB(mtx2); ===》 这里阻塞了！如果不知道怎么定位到源代码行上，看下一小节！
std::cout << "线程A获取锁2" << std::endl;
std::cout << "线程A释放所有锁资源，结束运行！" << std::endl;
}

        既然定位到taskA和taskB线程阻塞的原因，都是因为锁获取不到，然后再结合源码进行分析定位，最终发现taskA之所以获取不到mtx2，是因为mtx2早被taskB线程获取了；同样taskB之所以获取不到mtx1，是因为mtx1早被taskA线程获取了，导致所有线程进入阻塞状态，等待锁资源的获取，但是又因为没有线程释放锁，最终导致死锁问题。（从各线程调用栈信息能看出来，这里面和I/O网络事件没什么关系）.


怎么在源码上定位到问题代码

        实际上，上面的代码运行一般是发布后的release版本，内部没有调试信息，我们如果想把死锁的原因定位到源码的某一行代码上，就需要一个debug版本（g++编译添加-g选项），操作如下：
1.编译命令

liu@liu-virtual-machine:~/code$ g++ 20190316.cpp -g -lpthread

2. 运行代码

liu@liu-virtual-machine:~/code$ ./a.out

线程A获取锁1
线程B获取锁2
…(程序到这里不往下运行了)

3.gdb调试该进程

root@liu-virtual-machine:/home/liu/code# ps -ef | grep a.out
liu 2617 1535 0 12:32 pts/0 00:00:00 ./a.out
root@tony-virtual-machine:/home/liu/code# gdb attach 2617

4.查看当前所有的线程
(gdb) info threads

  Id   Target Id         Frame 
* 1    Thread 0x7f8c63002740 (LWP 2617) "a.out" 0x00007f8c62bddd2d in __GI___pthread_timedjoin_ex (
    threadid=140240914892544, thread_return=0x0, abstime=0x0, block=<optimized out>) at pthread_join_common.c:89
  2    Thread 0x7f8c61ea4700 (LWP 2618) "a.out" __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
  3    Thread 0x7f8c616a3700 (LWP 2619) "a.out" __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135

可以看到有三个线程。
5.切换到线程2
(gdb) thread 2
6.查看线程2目前的调用栈信息，where或者bt命令都可以
(gdb) where

(gdb) where
#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x00007f8c62bdf023 in __GI___pthread_mutex_lock (mutex=0x55678928e180 <mtx2>) at ../nptl/pthread_mutex_lock.c:78
#2  0x000055678908b0bf in __gthread_mutex_lock (__mutex=0x55678928e180 <mtx2>)
    at /usr/include/x86_64-linux-gnu/c++/7/bits/gthr-default.h:748
#3  0x000055678908b630 in std::mutex::lock (this=0x55678928e180 <mtx2>) at /usr/include/c++/7/bits/std_mutex.h:103
#4  0x000055678908b6ac in std::lock_guard<std::mutex>::lock_guard (this=0x7f8c61ea3dc0, __m=...)
    at /usr/include/c++/7/bits/std_mutex.h:162
#5  0x000055678908b183 in taskA () at 20190316.cpp:23
#6  0x000055678908bbdb in std::__invoke_impl<void, void (*)()> (__f=@0x556789d78e78: 0x55678908b0f7 <taskA()>)
    at /usr/include/c++/7/bits/invoke.h:60
#7  0x000055678908b9e8 in std::__invoke<void (*)()> (__fn=@0x556789d78e78: 0x55678908b0f7 <taskA()>)
    at /usr/include/c++/7/bits/invoke.h:95
#8  0x000055678908c0b6 in std::thread::_Invoker<std::tuple<void (*)()> >::_M_invoke<0ul> (this=0x556789d78e78)
    at /usr/include/c++/7/thread:234
#9  0x000055678908c072 in std::thread::_Invoker<std::tuple<void (*)()> >::operator() (this=0x556789d78e78)
    at /usr/include/c++/7/thread:243
#10 0x000055678908c042 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)()> > >::_M_run (
    this=0x556789d78e70) at /usr/include/c++/7/thread:186
#11 0x00007f8c6290957f in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#12 0x00007f8c62bdc6db in start_thread (arg=0x7f8c61ea4700) at pthread_create.c:463
#13 0x00007f8c6236488f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

7.查看上面线程2的第5帧信息#5 0x000055678908b183 in taskA () at 20190316.cpp:23
(gdb) f 5

#5 0x000055678908b183 in taskA () at 20190316.cpp:23
23 std::lock_guard< std::mutex > lockB(mtx2);

        可以看到，这里就直接定位到代码一直阻塞在了20190316.cpp的第23行，对应的行代码是std::lock_guard< std::mutex > lockB(mtx2);


死锁问题代码修改

        既然发现了问题，那么就知道这个问题场景发生死锁，是由于多个线程获取多个锁资源的时候，顺序不一致导致的死锁问题，那么保证它们获取锁的顺序是一致的，问题就可以解决，代码修改如下：

#include <iostream>           //std::cout
#include <thread>             //std::thread
#include <mutex>              //std::mutex, std::unique_lock
#include <condition_variable> //std::condition_variable
#include <vector>

//锁资源1
std::mutex mtx1;
//锁资源2
std::mutex mtx2;

// 线程A的函数
void taskA()
{
	//保证线程A先获取锁1
	std::lock_guard<std::mutex> lockA(mtx1);
	std::cout << "线程A获取锁1" << std::endl;

	//线程A尝试获取锁2
	std::lock_guard<std::mutex> lockB(mtx2);
	std::cout << "线程A获取锁2" << std::endl;

	std::cout << "线程A释放所有锁资源，结束运行！" << std::endl;
}

// 线程B的函数
void taskB()
{
	//线程B获取锁1
	std::lock_guard<std::mutex> lockA(mtx1);
	std::cout << "线程B获取锁1" << std::endl;

	//线程B尝试获取锁2
	std::lock_guard<std::mutex> lockB(mtx2);
	std::cout << "线程B获取锁2" << std::endl;

	std::cout << "线程B释放所有锁资源，结束运行！" << std::endl;
}
int main()
{
	//创建生产者和消费者线程
	std::thread t1(taskA);
	std::thread t2(taskB);

	//main主线程等待所有子线程执行完
	t1.join();
	t2.join();

	return 0;
}

标签：std,__,thread,lock,案例,死锁,mutex,解决,线程
From： https://blog.csdn.net/2301_78353179/article/details/144855077

相关文章

  • 【Video标签的详细使用及案例介绍，看完通透直接学会！】
    前言好久没更新了，最近工作上项目比较忙，在2024年的最后一天给大家分享一下近期项目所遇到的问题的一些分享一、video标签video标签是HTML5的标签，表示视频嵌入元素，video元素用于在文档中嵌入媒体播放器，用于支持文档内的视频播放。https://developer.mozilla.org/zh-CN/docs/W......
  • Creo许可错误解决方法
    在使用Creo软件进行设计和创新时，可能会遇到各种许可错误，这些错误可能会阻碍您的工作流程并降低生产效率。为了帮助用户快速、有效地解决这些问题，本文提供了一站式的Creo许可错误解决方法。一、常见Creo许可错误及其原因在使用Creo软件时，您可能会遇到诸如“许可证过期”、“许可......
  • QT程序监控不到拖拽事件如dragEnterEvent - Windows权限问题的解决方案
    问题：当客户端已高完整性启动（例如启动客户端的进程是BypassUAC启动的高完整性的进程，导致客户端继承了其高完整性），由于explorer.exe资源管理器是以中等Medium权限启动，客户端的权限较高，导致设置了qt编写的客户端设置了的setAcceptDrops(true)后依然无法触发dropEvent，导致无法接受其它......
  • Delinea 协议 是 Delinea 公司（原名 ThycoticCentrify）推出的一个网络安全解决方案， Deli
    Delinea协议是Delinea公司（原名ThycoticCentrify）推出的一个网络安全解决方案，用于特权访问管理（PAM,PrivilegedAccessManagement）。Delinea的功能主要集中在确保特权账号、会话和资产的安全管理。由于它主要涉及身份和访问控制（IAM,IdentityandAccessManagement）、特权账户......
  • 案例拆解：用AI实现小红书壁纸号变现！
    如果说2021年最火的互联网科技产品是Clubhouse，2022年最火的是元宇宙，那么2023年最火的产品非ChatGPT莫属。随着ChatGPT的火爆，国内不少互联网大厂开始研发类似的产品，不仅仅是互联网大厂，不少嗅觉敏感的人开始将它视为一种能够赚钱的工具，并围绕ChatGPT打造多个不同......
  • 2024年回顾：AI大模型在科学研究中的十大应用案例
    大语言模型(LLM)已迅速成为科学研究的变革力量，彻底改变了科学家处理复杂问题、分析数据和产生新见解的方式。本文重点介绍 2024年在科学研究中十个案例，展示了LLM在各个科学领域的多样化和有影响力的应用。 1.药物研发牛津大学与瑞士联邦理工学院（EPFL）、剑桥大学、康......
  • 布局2025年计划：看板工具的使用技巧与实战案例
    又至年末，过去的一年，你的目标是否都如愿完成？无论答案如何，现在正是重新整理思路、规划2025年蓝图的时候。【如何让计划不再停留在纸面，而是真正落地执行？答案是：将目标可视化，并高效管理执行进度。】为什么选择用看板布局新年目标？看板工具（如板栗看板等）是通过可视化任务管理，实现高效......
  • 解决Spring boot集成quartz时service注入失败为null的问题
    解决Springboot集成quartz时service注入失败为null的问题一、报错信息二、代码任务类源代码配置类原代码三、注入失败原因四、解决的思路11、任务类修改2、配置类修改五、解决的思路2一、报错信息java.lang.NullPointerException:nullatfarbun.server.schedul......
  • Gradle下载Plugins插件连接超时 failed: Connection timed out: connect的解决方法
    可以去gradle官方plugin仓库看看插件是否存在。出现超时的问题多半都是网络因素，可能是复杂的网络导致你访问不了吧，配置下plugins可访问使用的仓库即可。需要注意buildscript在plugins之上的位置。buildscript{repositories{mavenLocal()maven{url'https://......
  • 解决uniapp安卓打包targetSdkVersion报错
    解决GooglePlay版本检查问题的实用方案。Error:GooglePlayrequiresthatappstargetAPIlevel33orhigher.[ExpiredTargetSdkVersion]问题描述打包时遇到以下错误：Error:GooglePlayrequiresthatappstargetAPIlevel33orhigher.[ExpiredTargetSdkVersion]......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99