主要内容：
一、GIL全局解释器锁
二、死锁和递归锁
三、信号量、Event事件、定时器
1️⃣ GIL全局解释器锁
1、Cpython的GIL解释器锁的工作机制
1.1 在Cpython解释器中，同一个进程下开启的多线程，同一时刻只能有一个线程执行，无法利用多核优势。GIL本质就是一把互斥锁，既然是互斥锁，所有互斥锁的本质都一样，都是将并发运行变成串行，以此来控制
需要明确的一点是GIL并不是Python的特性，它是在实现Python解析器(CPython)时所引入的一个概念。就好比
C++是一套语言（语法）标准，但是可以用不同的编译器来编译成可执行代码。>有名的编译器例如GCC，INTEL C++，Visual C++等。
Python也一样，同样一段代码可以通过CPython，PyPy，Psyco等不同的Python执行环境来执行。像其中的JPython就没有GIL。
然而因为CPython是大部分环境下默认的Python执行环境。所以在很多人的概念里CPython就是Python，也就想当然的把GIL归结为
Python语言的缺陷。所以这里要先明确一点：GIL并不是Python的特性，Python完全可以不依赖于GIL。
1.2 GIL的介绍
同一时间内共享数据只能被一个任务所修改，进而保证数据安全。可以肯定的一点是：保护不同的数据的安全，就
应该加不同的锁。要想了解GIL，首先确定一点：每次执行python程序，都会产生一个独立的进程。例如python test1.py，
python test2.py，python test3.py会产生3个不同的python进程。
验证进程的方法：
#test.py内容
import os,time
print(os.getpid())
time.sleep(1000)
#打开终端执行
python3 test.py
#在windows下查看
tasklist |findstr python
#在linux下下查看
ps aux |grep python
在一个python的进程内，不仅有test.py的主线程或者由该主线程开启的其他线程，还有解释器开启的
垃圾回收等解释器级别的线程，总之，毫无疑问，所有线程都运行在这一个进程内。
1.3 GIL原理分析
第一点：所有数据都是共享的，这其中，代码作为一种数据也是被所有线程共享的（test.py的所有代码以及Cpython解释器的所有代码） 例如：test.py定义一个函数work（代码内容如下图），在进程内所有线程都能访问到work的代码，于是我们可以开启三个线程
然后target都指向该代码，能访问到意味着就是可以执行。
第二点：
所有线程的任务，都需要将任务的代码当做参数传给解释器的代码去执行，即所有的线程要想运行自己的任务，如果多个线程的target=work，那么执行流程是多个线程先访问到解释器的代码，即拿到执行权限，
首先需要解决的是能够访问到解释器的代码。
由以上两点不难得知：
然后将target的代码交给解释器的代码去执行。
重点：
解释器的代码是所有线程共享的，所以垃圾回收线程也可能访问到解释器的代码而去执行，这就导致了一个问题:对于同一个数据100，可能线程1执行x=100的同时，而垃圾回收执行的是回收100的操作，解决这种问题没有什么高明的方法，就是加锁处理，即GIL,保证python解释器同一时间只能执行一个任务的代码。
如图所示：
1.4 GIL 和 Lock
Python已经有一个GIL来保证同一时间只能有一个线程来执行了，为什么这里还需要lock?
我们已经知道：锁的目的是为了保护共享的数据，同一时间只能有一个线程来修改共享的数据。保护不同的数据就应该加不同的锁。
所以，解释就是GIL 与Lock是两把锁，保护的数据不一样，前者是解释器级别的（当然保护的就是解释器级别的数据，比如垃圾回收的数据），
后者是保护用户自己开发的应用程序的数据，很明显GIL不负责这件事，只能用户自定义加锁处理，即Lock。如下图：
解释如下：
1、100个线程去抢GIL锁，即抢执行权限
2、肯定有一个线程先抢到GIL（暂且称为线程1），然后开始执行，一旦执行就会拿到lock.acquire()
3、极有可能线程1还未运行完毕，就有另外一个线程2抢到GIL，然后开始运行，但线程2发现互斥锁lock还未被线程1释放，于是阻塞，被迫交出执行权限，即释放GIL
4、直到线程1重新抢到GIL，开始从上次暂停的位置继续执行，直到正常释放互斥锁lock，然后其他的线程再重复2 3 4的过程