一、死锁会在什么情况发生
1、假设有如下代码
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
mutex; //代表一个全局互斥对象 void A() { mutex.lock(); //这里操作共享数据 B(); //这里调用B方法 mutex.unlock(); return; } void B() { mutex.lock(); //这里操作共享数据 mutex.unlock(); return; } |
此时会由于在A、B方法中相互等待unlock而导致死锁。
2、假设有如何代码
|
1
2
3
4
5
6
7
8
9
10
11
12
|
mutex; //代表一个全局互斥对象 void A() { mutex.lock(); //这里操作共享数据 if(.....) { return; } mutex.unlock(); return; } |
由于在if的执行体内直接retun，而没有调用unlock，导致另一个线程再调用A方法就出现死锁。
二、另一个总结
不管什么原因，死锁的危机都是存在的。那么，通常出现的死锁都有哪些呢？我们可以一个一个看过来，
（1）忘记释放锁
|
1
2
3
4
5
6
7
|
void data_process() { EnterCriticalSection(); if(/* error happens */) return; LeaveCriticalSection(); } |
（2）单线程重复申请锁
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
void sub_func() { EnterCriticalSection(); do_something(); LeaveCriticalSection(); } void data_process() { EnterCriticalSection(); sub_func(); LeaveCriticalSection(); } |
（3）双线程多锁申请
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
void data_process1() { EnterCriticalSection(&cs1); EnterCriticalSection(&cs2); do_something1(); LeaveCriticalSection(&cs2); LeaveCriticalSection(&cs1); } void data_process2() { EnterCriticalSection(&cs2); EnterCriticalSection(&cs1); do_something2(); LeaveCriticalSection(&cs1); LeaveCriticalSection(&cs2); } |
（4）环形锁申请
/*
* A - B
* | |
* C - D
*/
假设有A、B、C、D四个人在一起吃饭，每个人左右各有一只筷子。所以，这其中要是有一个人想吃饭，他必须首先拿起左边的筷子，再拿起右边的筷子。现在，我们让所有的人同时开始吃饭。那么就很有可能出现这种情况。每个人都拿起了左边的筷子，或者每个人都拿起了右边的筷子，为了吃饭，他们现在都在等另外一只筷子。此时每个人都想吃饭，同时每个人都不想放弃自己已经得到的一那只筷子。所以，事实上大家都吃不了饭。
总结：
（1）死锁的危险始终存在，但是我们应该尽量减少这种危害存在的范围
（2）解决死锁花费的代价是异常高昂的
（3）最好的死锁处理方法就是在编写程序的时候尽可能检测到死锁
（4）多线程是一把双刃剑，有了效率的提高当然就有死锁的危险
（5）某些程序的死锁是可以容忍的，大不了重启机器，但是有些程序不行
