Linux产生死锁的必要条件和常见的锁种类

偏执的太偏执、 2024-03-27 09:23 13阅读 0赞

#### 目录 ####

*  前言
 *  产生死锁的4个必要条件
 *  预防(解决)死锁
 *  Linux常见的锁
 *   *  互斥锁(普通锁)
     *  自旋锁
     *   *  互斥锁和自旋锁小结
     *  递归锁
     *  读写锁
     *  乐观锁与悲观锁
     *   *  乐观锁和悲观锁小结
     *  其他锁(了解)

## 前言 ##

1.  之前面试的时候，有面试官问我产生死锁的(4个)必要条件，这个我之前有了解过，但是当时觉得这些必要条件很官方，也就没有重视，最后答得支支吾吾，面试官笑着说下去去可以看看，这个在面试中跟智能指针一样还挺常见的;（面试全程都很顺利，卡在这个简单的问题上确实不应该）
2.  由此面试碰到了让我介绍linux下mutex的种类，这个也是之前略知一二，但是详细场景和机制还是欠缺;

这篇博客根据上面两个面试中出现的问题，以本人个人理解进行总结:

--------------------

## 产生死锁的4个必要条件 ##

> 下面四个必要条件不详细介绍，如果不理解需要温习一下mutex互斥量的作用和lock,unlock加锁解锁的底层原理;

（1）`互斥条件`：进程要求对所分配的资源进行排它性控制，即**所分配的资源在一段时间内某资源仅为一进程所占用**。  
（2）`请求与保持条件`：当进程因请求资源而**阻塞时，对已获得的资源保持不放**。(请求新资源的时候，保持已获得的旧资源)  
（3）`不剥夺条件`：**进程已获得的资源在未使用完之前，不能剥夺**，只能在使用完时由自己释放。  
（4）`循环等待条件`：在发生死锁时，**必然存在一个进程–资源的环形链**。

--------------------

## 预防(解决)死锁 ##

破坏4个必要条件中的任一个:

> 互斥这个规则，这个为了临界区的安全，肯定不能破坏呀;那就破坏后3个;

（1）`资源一次性分配`：**一次性分配所有资源，用完一次性全部释放**，这样就不会再有别的进程请求时的冲突的现象了：

（2）`可剥夺资源`：即当某进程获**得了部分资源，但得不到其它资源，则释放(剥夺)已占有的资源**（破坏不可剥夺条件）  
（3）`资源有序分配法`：系统给每类资源赋予一个编号，每一个进程**按编号递增的顺序请求资源**，释放则相反,就不会出现环路了（破坏环路等待条件）;

--------------------

## Linux常见的锁 ##

我们在开发中常用的锁主要有**互斥锁，递归锁，自旋锁，读写锁、乐观锁和悲观**锁这五种：

### 互斥锁(普通锁) ###

*  正常进程间保护临界区的普通锁，没有什么特点，就是lock()和unlock()的正常上锁解锁;

1.  **当线程加锁失败时**，内核会把线程的状态从运行状态设置为睡眠状态，然后把CPU切换给其他进程运行；
2.  **当需要的锁被其他线程释放时**，之前睡眠状态的进程会变为就绪状态，然后内核会在合适的时候，把CPU切换给该线程运行。

**普通锁看似使用简单**，但是由于内核帮我们切换进程的内核态和用户态，**存在一定的开销**（进行了两次线程上下文切换）

--------------------

### 自旋锁 ###

*  自旋锁**在用户态完成加锁和解锁的操作**，**不会主动产生内核态和用户态的切换和上下文的切换**，所以相比互斥锁来说，会快一些，开销也小一些。

自旋锁的工作原理是在**一段时间内反复尝试获取被占用的锁**：

当**加锁失败**时，**互斥锁用线程切换来应对，自旋锁则用忙等待（反复尝试获取锁）来应对**。

--------------------

#### 互斥锁和自旋锁小结 ####

如果能确定被锁住的**代码执行时间很短**，而且多核处理器，就应该**使用自旋锁**，**减少了普通mutex线程上下文切换**的开销;

如果被锁住的**代码执行时间长**，而且单核处理器，还是**用普通mutex**好点，因为这时候**递归锁反复长时间轮询检测，无疑是浪费了cpu资源的举措**。

> mutex和自旋锁是锁的两种最基本处理方式，更高级的锁都会选择其中一个方式来实现;
> 
> 比如**读写锁**既可以选择基于互斥锁实现，也可以选择基于自旋锁实现。

--------------------

### 递归锁 ###

**递归锁只是互斥锁的一个特例**，同样**只能有一个线程访问该对象**;

但**递归锁允许同一个线程在 未释放其拥有的锁时 反复对 该锁 进行加锁操作**（普通的锁就死锁了）

> 显然递归锁的常见场景就是对某一个**包含加锁操作的递归类型函数**进行调用; 某线程反复递归这个函数的时候，使用递归锁就不会像普通mutex那样第二次遇到加锁操作就直接进入睡眠状态挂起了;

--------------------

### 读写锁 ###

**线程间读临界区资源的时候，不阻塞**，**只有在有写的时候才起到mutex的作用，线程间互相阻塞**;

> 这是一种提高效率的锁，比如mysql中的读写锁，读的时候因为不会修改临界区的资源，不会产生线程安全问题，因此读不阻塞效率更高;
> 
> 写的时候存在线程安全问题，那就阻塞了;

--------------------

### 乐观锁与悲观锁 ###

**悲观锁**

前面提到的互斥锁、自旋锁、读写锁，都属于悲观锁

**悲观锁认为多线程同时对共享资源进行修改的事件发生概率比较高**，很容易出现冲突问题，**所以访问共享资源前，必须先上锁**。（做法有点谨慎，悲观，因此得名）

--------------------

**乐观锁(无锁编程)**

*  与悲观锁相反，乐观锁认为冲突的概率很低;

它的工作方式是：**先修改完共享资源，再验证这段时间内有没有发生冲突**：

1.  如果没有其他线程在修改资源，那么操作完成;(赚了，没发生冲突而且执行效率还高)
2.  如果发现有其他线程已经修改过这个资源，就直接无脑放弃本次操作。(不亏，有冲突，放弃**这次操作**以免事态恶化，之后进行重试； 做法很乐观，因此得名)

**乐观锁全程没有加锁，所以它也叫无锁编程**

--------------------

#### 乐观锁和悲观锁小结 ####

> 悲观锁直接进行加锁操作，进行加锁的操作，适用于冲突事件发生概率高的场景(这个场景用悲观锁得不停地)
> 
> 乐观锁虽然去除了加锁解锁的操作，**但是一旦发生冲突，重试的成本其实也非常高**，所以只有**在冲突事件发生的概率非常低，且加锁成本非常高的场景(比如cpu执行效率非常快)时，才考虑使用乐观锁**。

### 其他锁(了解) ###

> 还有很多锁，比如mysql在RR隔离级别下处理幻读问题使用了**row行锁+GAP间隙锁等**，都是一些高级的适用于某种场景的锁，所以锁的可拓展性还是很大的;