死锁 + 条件变量 + 生产消费者模型

死锁

现象 ： 代码不会继续往后推进了

问题
一把锁有没有可能产生死锁呢？
有可能

线程第一次申请锁成功，继续再次申请，第二次申请就失败了，当前线程抱着锁就被挂起了
其他线程申请都失败阻塞了。
1.你抱着锁去休眠了
2.没有人释放锁了
3. 剩余线程申请锁都不成功
所有整个线程全部都卡住了

上面是单执行流，单锁，更一般的情况是多锁，多执行流

一组执行流（这里按多线程说），并发编程时锁可能不止一个，正常编程时各个线程都由调度器自由去申请锁，此时就可能出现问题，一个线程持有一把锁，另一个线程持有另一把锁，但是他们两个却互相申请对方的锁，进而导致一种永久等待的状态，这种状态成为死锁。

所有的死锁都是由于程序员代码写的不太合适或者调度过程中出现异常问题

例子
张三和李四去商店买糖，他们俩每人只有五毛钱，但是棒棒糖一块钱，张三要李四的那五毛，
李四要张三那五毛，他们两个人就在商店这里卡住了。

多线程会产生死锁其实有四个必要条件
什么叫必要条件？
只要产生了死锁必定满足这四个条件，并不代表使用这四个条件百分百产生死锁
反过来理解
只要四个条件中有一个条件不满足就一定不会产生死锁

1.互斥条件
要有死锁的前提肯定是要先用了锁
2.请求与保持条件
比如例子中张三请求李四的五毛钱并且不释放自己的五毛，李四也遵循相同的规则
3.不剥夺条件
张三拿着自己的五毛钱还在请求对方的五毛，但不能强行抢李四的五毛
4.循环等待条件
若干执行流之间形成一种头尾相接的循环等待资源的关系

我们写的抢票就是遵循互斥条件，有请求与保持，只不过只有一把锁，也有不剥夺条件，但是没产生死锁
因为必须形成环路等待才能产生死锁

如何解决死锁问题呢？

理念
一旦有死锁必定要同时满足四个必要条件，解决的话必然需要破坏4个必要条件之一

方法
1.代码死锁了，那我重写一下代码我不用锁了那就没有互斥了也没有死锁了

2.请求与不保持
张三问李四要五毛失败了，此时张三把五毛释放了，反正张三也走不到后面买不了棒棒糖
具体怎么操作呢？
之前pthread_mutex_lock 线程申请锁失败后不是立马出错返回而是把自己阻塞住
pthread_mutex_trylock 申请锁如果失败它会立即返回，是申请锁的非阻塞版本
它返回后把锁释放掉然后从新开始申请锁，这样就很容易破坏请求与保持条件
我们用的lock本来就是保持的，你不给我锁我就在这阻塞住，只不过只有一把锁

3.破坏不剥夺条件，那就是要剥夺，剥夺的本质不就是释放对方的锁吗
怎么剥夺呢？
直接释放锁
以前讲解锁的原理不是把以前交换的锁换回去，而是直接把锁置1 了

第一条破坏改动比较大，2,3是通过接口可以实现的

4.环路等待问题，申请资源形成一个环路

要破坏它通过编码来完成
张三要李四的锁2，李四要张三的锁1，为什么会这样？
谁让你申请锁时不按顺序申请而是交叉着申请，为什么不让两个线程同时申请锁1然后再同时申请锁2。
也就是说你要同时持有两把锁你必须得按顺序申请锁，也就破坏了环路等待问题

避免死锁

破坏死锁的四个必要条件

加锁顺序保持一致
两个线程都按顺序申请锁1锁2，不要倒着来，尽可能减少环路等待

避免锁未释放的场景
写代码锁要尽快释放

资源一次性分配
尽量把资源一次性给线程，不要让线程花了多次持有锁申请资源
一次给它，意味着加锁场景少一些，产生死锁场景就少了

条件变量

生产消费者模型