Linux系统下常见的死锁现象及解决方法 (linux 死锁现象)
在Linux系统中，死锁是一种常见的现象。当不同的进程或线程同时请求相同资源时，可能会造成死锁。本文将介绍Linux系统下常见的死锁现象以及解决方法。
一、死锁现象
1.资源竞争
进程或线程之间竞争同一资源，例如同一文件或同一设备。
2.互斥
进程或线程只能以互斥的方式访问某些资源。当多个进程或线程都需要这些资源时，可能会发生死锁。
3.占用且等待
进程或线程占用了某些资源，并且等待其他资源，而这些资源已经被其他进程占用。
4.循环等待
当两个或多个进程或线程相互等待对方所持有的资源时，会发生循环等待。
二、死锁解决方法
1.避免死锁
避免死锁是更好的解决方法。在编程中，应该避免不必要的资源竞争和互斥，尽可能减少进程或线程对资源的需要，并确保每次只锁定必要的资源。此外，应该限制资源的占用时间和优先级。
2.检测和恢复
当死锁发生时，可以通过检测和恢复的方式解决。检测死锁可以通过算法来实现，最常用的是银行家算法。银行家算法可以检测系统中是否存在死锁，并且可以通过释放一些占用资源的进程或线程来解除死锁。此外，可以使用死锁恢复策略来避免死锁的出现。
3.破坏死锁
可以通过破坏死锁中的任一条件来解决死锁。可以释放一些进程或线程所占用的资源，以期待其他进程或线程可以接收这些资源。可以抢占某些进程或线程所持有的资源，以便其他进程或线程可以访问这些资源。可以撤销某些进程或线程，以释放资源，并尽可能减少死锁的存在。
三、代码示例
以下是一个简单的代码示例，演示如何使用互斥锁避免死锁。
“`c
#include
#include
#include
pthread_mutex_t mutex1 = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_t mutex2 = PTHREAD_MUTEX_INITIALIZER;
void *thread1(void *arg) {
pthread_mutex_lock(&mutex1);
printf(“Thread 1 locked mutex 1\n”);
sleep(1);
pthread_mutex_lock(&mutex2);
printf(“Thread 1 locked mutex 2\n”);
pthread_mutex_unlock(&mutex2);
pthread_mutex_unlock(&mutex1);
return NULL;
}
void *thread2(void *arg) {
pthread_mutex_lock(&mutex2);
printf(“Thread 2 locked mutex 2\n”);
sleep(1);
pthread_mutex_lock(&mutex1);
printf(“Thread 2 locked mutex 1\n”);
pthread_mutex_unlock(&mutex1);
pthread_mutex_unlock(&mutex2);
return NULL;
}
int mn() {
pthread_t t1, t2;
pthread_create(&t1, NULL, thread1, NULL);
pthread_create(&t2, NULL, thread2, NULL);
pthread_join(t1, NULL);
pthread_join(t2, NULL);
return 0;
}
“`
在以上示例中，两个线程都需要访问两个互斥锁。为了避免死锁，线程1首先锁定mutex1，然后尝试锁定mutex2。当线程2尝试锁定mutex2时，由于mutex2已被线程1锁定，线程2只能等待。当线程1释放mutex2并解锁mutex1后，线程2可以锁定mutex2，然后继续执行。这种方法可以避免死锁的出现。
相关问题拓展阅读：
linux rcu锁问题怎么查
众所周知，为了保护共享数空运据,需要一些同步机制,如自旋锁(spinlock)，读写锁(rwlock)，它们使用起来非常简单,而且是一种很有效的同步机制，在UNIX系统和Linux系统中得到了广泛的使用。但是随着计算机硬件的快速发展，获得这种锁的开销相对于CPU的速度在成倍地增加，原因很简单，CPU的速度与访问内存的速度差距越来越大，而这种锁使用了原子操作指令，它需要原子地访问内存，也就说获得锁的开销与访存速度相关，另外在大部分非x86架构上获取锁使用了内存栅(Memory Barrier)，这会导致处理器流水线停滞或刷新，因此它的开销相对于CPU速度而言就越来越大。
在操作系统中，数据一致性访问是一个非常重要的部分，通常我们可以采用锁机制实现数据的一致性访问。例如，semaphore、spinlock机制，在访问共享数据时，首先访问锁资源，在获取锁资源的前提下才能实现数据的访问。这种原理很简单，根本的思想就是在访问临界资源时，首先访问一个全局的变量（锁），通过全局变量的状态来控制线程对临界资源的访问。但是，这种思想是需要硬件支持的，硬件需要配合实现全局变量（锁）的读-修改-写，现代CPU都会提供这样的原子化指令。采用锁机制实现数据访问的一致性存在如下两个问题：
1、 效率问题。锁机制的实现需要对内存的原子化访问，这种访问操作会破坏流水线操作，降低了流水线效率。这是影响性能的一个因素。另外，在采用读写锁机制的情况下，写锁是排他锁，无法实现写锁与读锁的并发操作，在某些应用下回降低性能。
2、 扩展性问题。当系统中CPU数量增多的时候，采用锁机制实现数据的同步访问效率偏低。并且随着CPU数量的增多，效率降低，由此可见锁机制实现的数据一致性访问扩展性差。
为了解决上述问题，Linux中引进了RCU机制。该机制在多CPU的平台上比较适用，对于读多写少的应用尤其适游闷用。RCU的思路实际上很简单，下面对其进行描述：
1、对于读操作，可以直接对共享资源进行访问，但是前提是需要CPU支持访存操作的原子化，现代CPU对这一点都做了保证。但是RCU的读操作上下文是不可抢占的（这一点在下面解释），所以读访问共享资源时可以采用read_rcu_lock()，该函数的工作是停止抢占。
2、对于写操作，其需要将原来的老数据作一次备份（copy），然后对备份数据进行修改，修改完毕之后再用新数据更新老数据，更新老数据时采用了rcu_assign_pointer（）宏，在该函数中首先屏障一下memory，然后修改老数据。这个操作完成之后，需要进行老数据资源的回收。操作线程向系统注册回收方法，等待回收。采用数据备份的方法可以实现读者与写者之间的并发操作，但是不能解决多个写着之间的同步，所以当存在多个写者时，需要通过锁机制对其进行互斥，也就是在同一时刻只能存在一个写者。
3、在RCU机制中存在一个垃圾回收的daemon，当共享资源被update之后，可以采用该daemon实现老数据资源的回收。回收时间点就是在update之前的所有的读者全部退出。由此可见写者在update之后是需要睡眠等待的，需斗磨梁要等待读者完成操作，如果在这个时刻读者被抢占或者睡眠，那么很可能会导致系统死锁。因为此时写者在等待读者，读者被抢占或者睡眠，如果正在运行的线程需要访问读者和写者已经占用的资源，那么死锁的条件就很有可能形成了。
请教linux下用户态进程调度问题
在进行Linux系统操作的时候，有时候会遇到一次用户态进程死循环，即系统反应迟钝、进程挂死等问题，那么遇到这些问题又该如何解决呢？下面小编就给大家介绍下一次用户态进程死循环的问题该如何处瞎颤理。
Linux下如何处理一次用户态进程死循环问题
1、问题现象
业务进程（用户态多线程程序）挂死，操作系统反应迟钝，系统日志没有任何异常。从进程的内核态堆栈看，看似所有线程都卡在了内核态的如下堆栈流程中：
［root@vmc116 ~］# cat /proc/27007/task/11825/stack
［《ffffffff8100baf6》］ retint_careful+0x14/0x32
［《ffffffffffffffff》］ 0xffffffffffffffff
2、喊兄问题分析
1）内核堆栈分析
从内核堆栈看，所有进程都阻塞在 retint_careful上，这个是中断返回过程中的流程，代码（汇编）如下：
entry_64.S
代码如下：
ret_from_intr：
DISABLE_INTERRUPTS（CLBR_NONE）
TRACE_IRQS_OFF
decl PER_CPU_VAR（irq_count）
/* Restore saved previous stack */
popq %rsi
CFI_DEF_CFA rsi，SS+8-RBP /* reg/off reset after def_cfa_expr */
leaq ARGOFFSET-RBP（%rsi）， %rsp
CFI_DEF_CFA_REGISTER rsp
CFI_ADJUST_CFA_OFFSET RBP-ARGOFFSET
。。。
retint_careful：
CFI_RESTORE_STATE
bt $TIF_NEED_RESCHED，%edx
jnc retint_signal
TRACE_IRQS_ON
ENABLE_INTERRUPTS（CLBR_NONE）
pushq_cfi %rdi
磨渗败 SCHEDULE_USER
popq_cfi %rdi
GET_THREAD_INFO（%rcx）
DISABLE_INTERRUPTS（CLBR_NONE）
TRACE_IRQS_OFF
jmp retint_check
这其实是用户态进程在用户态被中断打断后，从中断返回的流程，结合retint_careful+0x14/0x32，进行反汇编，可以确认阻塞的点其实就在
SCHEDULE_USER
这其实就是调用schedule（）进行调度，也就是说当进程走到中断返回的流程中时，发现需要调度（设置了TIF_NEED_RESCHED），于是在这里发生了调度。
有一个疑问：为什么在堆栈中看不到schedule（）这一级的栈帧呢？
因为这里是汇编直接调用的，没有进行相关栈帧压栈和上下文保存操作。
2）进行状态信息分析
从top命令结果看，相关线程实际一直处于R状态，CPU几乎完全耗尽，而且绝大部分都消耗在用户态：
［root@vmc116 ~］# top
top – 09:42:23 up 16 days， 2:21， 23 users， load average： 84.08， 84.30， 83.62
Tasks： 1037 total， 85 running， 952 sleeping， 0 stopped， 0 zombie
Cpu（s）： 97.6%us， 2.2%sy， 0.2%ni， 0.0%id， 0.0%wa， 0.0%hi， 0.0%si， 0.0%st
Mem：k total，k used，k free，k buffers
Swap：k total， 38644k used，k free，k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
rootm 163m 14m R 10.2 0.5 321:06.17 z_itask_templat
rootm 163m 14m R 10.2 0.5 296:23.37 z_itask_templat
rootm 163m 14m R 10.2 0.5 337:57.26 z_itask_templat
rootm 163m 14m R 10.2 0.5 327:31.93 z_itask_templat
rootm 163m 14m R 10.2 0.5 306:49.44 z_itask_templat
rootm 163m 14m R 10.2 0.5 310:47.41 z_itask_templat
rootm 163m 14m R 10.2 0.5 283:03.37 z_itask_templat
rootm 163m 14m R 10.2 0.5 283:49.67 z_itask_templat
rootm 163m 14m R 10.2 0.5 261:24.46 z_itask_templat
rootm 163m 14m R 10.2 0.5 150:24.53 z_itask_templat
rootm 163m 14m R 10.2 0.5 100:26.77 z_itask_templat
rootm 163m 14m R 9.9 0.5 337:18.77 z_itask_templat
rootm 163m 14m R 9.9 0.5 314:24.17 z_itask_templat
rootm 163m 14m R 9.9 0.5 336:32.78 z_itask_templat
rootm 163m 14m R 9.9 0.5 338:55.08 z_itask_templat
rootm 163m 14m R 9.9 0.5 306:46.08 z_itask_templat
rootm 163m 14m R 9.9 0.5 316:49.51 z_itask_templat
。。。
3）进程调度信息
从相关线程的调度信息看：
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
发现相关线程的调度统计一直在增加，说明相关线程一直是在被调度运行的，结合其状态也一直是R，推测很可能在用户态发生了死循环（或者非睡眠死锁）。
这里又有问题：为什么从top看每个线程的CPU占用率只有10%左右，而不是通常看到的死循环进程导致的100%的占用率？
因为线程数很多，而且优先级都一样，根据CFS调度算法，会平均分配时间片，不会让其中一个线程独占CPU。结果为多个线程间轮流调度，消耗掉了所有的cpu。。
另一个问题：为什么这种情况下，内核没有检测到softlockup？
因为业务进程的优先级不高，不会影响watchdog内核线程（更高优先级的实时线程）的调度，所以不会产生softlockup的情况。
再一个问题：为什么每次查看线程堆栈时，总是阻塞在retint_careful，而不是其它地方？
因为这里（中断返回的时候）正是调度的时机点，在其它时间点不能发生调度（不考虑其它情况~），而我们查看线程堆栈的行为，也必须依赖于进程调度，所以我们每次查看堆栈时，正是查看堆栈的进程（cat命令）得到调度的时候，这时正是中断返回的时候，所以正好看到的阻塞点为retint_careful。
4）用户态分析
从上面的分析看，推测应该是用户态发生了死锁。
用户态确认方法：
部署debug信息，然后gdb attach相关进程，确认堆栈，并结合代码逻辑分析。
最终确认该问题确为用户态进程中产生了死循环。
我在linux中安装rpm包时候遇到麻烦，很有趣，类似我们学数据库oracle中的“死锁”问题,
说明这些都是相互有依赖关系的软件包，只需要一起同时安装即可。
方歼滚行法1：
rpm -ivh elfutils-libelf-devel-0.137-3.el5.x86_64.rmp elfutils-libelf-devel-static-0.137-3.el5.x86_64.rpm
如果还不能，请加备拿–nodeps,如果还不能装，请加氏哗–force
方法2：
yum install elfutils-libelf-devel*
可以使用斗粗喊–nodeps参数安装，作用是忽略空野依赖凳粗关系
rpm -ivh –nodeps elfutils-libelf-devel-static-x86_64.rpm
我也拦则是搞了一个晚上都不行，偶然间试镇衡衡了一御做下 yum install elfutils-libelf-devel* 结果提示可能为dnf插件，于是试了一下 dnf install elfutils-libelf-devel* 结果安装成功！！ 我是fedora27。
关于linux 死锁现象的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。
