今天要跟大家一起来学习一下Python的多线程机制。有两个原因，其一是自己在学习中经常会使用到多线程，其二当然是自己对Python中的多线程并不是很了解。那么，今天和大家一起了解下~
Python多线程机制
开发多线程的应用系统，是在日常开发中经常会遇到的需求。同时，Python也为多线程系统的开发提供了很好的支持。
大家应该都知道，Python多线程机制是在GIL(Global Interpreter Lock)全局解释锁的基础上建立的。
那么Python为什么需要全局解释锁？
为什么需要全局解释锁？
我们知道，要支持多线程的话，一个基本的要求就是不同线程对共享资源访问的互斥，所以Python中引入了GIL，当然这是第一个原因。
Python中的GIL是一个非常霸道的互斥实现，在一个线程拥有了解释器的访问权之后，其它的所有线程都必须等待它释放解释器的访问权，即使这些线程的下一条指令并不会互相影响。
这样的说法也就意味着，无论如何，在同一时间，只能有一个线程能访问Python提供的API。因为单处理器的本质是不可能并行的，这里的同一时间确实对于单处理器是毫无意义的，但是对于多处理器，同一时间，确实可以有多个时间独立运行。然而正是由于GIL限制了这样的情形，使得多处理器最终退化为单处理器，性能大打折扣。那么，为什么还要使用GIL呢？这里就要提到第二个原因。
当然，Python社区也早都认识到了这个问题，并且在不断探索，Greg Stein和Mark Hammond两位老兄曾经创建过一份去除GIL的branch，但是很不幸，这个分支在很多的基准测试中，尤其是在单线程的测试上，效率只有使用GIL的一半左右。
使用GIL时，保护机制的粒度比较大，也就是我们似乎只需要将可能被多个线程共享的资源保护起来即可，对于不会被多个线程共享的资源，完全可以不用保护。但是，如果使用更细粒度的锁机制进行保护，那么，会导致大量的加锁和解锁功能，加锁和解锁对于操作系统来说，是一个比较重量级的动作，同时，没有GIL的保护，编写Python的扩展模块的难度也大大增加。
所以，目前为止，GIL仍然是多线程机制的基石。
对于Python而言，字节码解释器是Python的核心所在，所以Python通过GIL来互斥不同线程对解释器的使用。这里举个例子进行说明：
假设，现在有三个线程A、B和C，它们都需要解释器来执行字节码，进行对应的计算，那么在这之前，它们必须获得GIL。那么现在假设线程A获得了GIL，其它线程只能等A释放GIL之后，才能获得。
对！是这样没错，于是，有两个问题：
1. 线程A何时释放GIL呢（如果A使用完解释器之后才释放GIL，那么，并行的计算退化为串行，多线程的意义何在？）
2. 线程B和C谁将在A释放GIL之后获得GIL呢？
所以毫无疑问的，Python拥有其自己的一套线程调度机制。
关于线程调度
和操作系统的进程调度一样，线程调度机制主要解决两个问题：
1. 在何时挂起当前线程，选择处于等待状态的下一个线程？
2. 在众多处于等待状态的线程中，应该选择激活哪个线程？
对于何时进行线程调度的问题，是由Python自身决定的。我们可以联想操作系统进行进程切换的问题，当一个进程执行了一段时间之后，发生了时钟中断，于是操作系统响应时钟中断，并在这时开始进程的调度。
与此类似，Python中通过软件模拟了这样的中断，来激活线程的调度。Python的字节码解释器是按照指令的顺序一条一条的顺序执行从而工作的，Python内部维护着这样一个数值，作为Python内部的时钟，假设这个值为N，那么Python将在执行了N条指令之后立刻启动线程调度机制。
也就是说，当一个线程获得GIL后，Python内部的监测机制就开始启动，当这个线程执行了N条指令后，Python解释器将强制挂起当前线程，开始切换到下一个处于等待状态的线程。
在Python中，可以这样获得这个数值（N）：
那么，下一个问题，Python会在众多等待的线程中选择哪一个呢？
答案是，不知道。因为这个问题是交给了底层的操作系统来解决的，Python借用了底层操作系统所提供的线程调度机制来决定下一个获得GIL进入解释器的线程是谁。
所以说，Python中的线程实际上就是操作系统所支持的原生线程。
那么，接下来，我们一起揭开Python中GIL的真实面目。
关于GIL
应该知道，Python中多线程常用的两个模块：Thread和在其之上的threading。其中Thread是使用C实现的，而Threading是用python实现。
我们可以通过Thread模块进行分析（以Python2.7.13为例）。
创建线程
首先从创建线程说起，在threadmodule.c中，thread_PyThread_start_new_thread()函数通过三个主要的动作完成一个线程的创建：