为什么 Python 多线程无法利用多核？
全局解释器锁（Global Interpreter Lock）是计算机程序设计语言解释器用于同步线程的一种机制，它使得任何时刻有且仅有一个线程在执行。
即便在多核处理器上，使用GIL的解释器也只允许同一时间执行一个线程，常见的使用GIL的解释器有CPython 和 Ruby MRI。
可以看到GIL并不是Python独有的特性，是解释型语言处理多线程问题的一种机制而非语言特性。
Python 是一门解释器语言，代码通过解释器执行，Python存在多种解释器，分别基于不同语言开发，每个解释器有不同的特点。
Python 程序的解释和执行过程简图：
- CPython
CPython 是主流版本的解释器，这个解释器是使用C语言编写的，也是使用最为广泛的解释器，可以方便的和C/C++的类库进行交互，因此也是最受关注的解释器。 - Jython
一种由 java 语言编写的 python 解释器，是将 Python 编译成 Java 字节码然后执行的一种解释器，可以方便地和 Java 的类库进行交互。 - IronPython
将 Python 代码解释为 .Net 平台上运行的字节码进行执行，类似Jython解释器，可以方便的和.Net 平台上的类库进行交互，IPython 在交互效果上有所增强，但执行过程和功能方面和Cpython是一样的。 - PyPy
一种使用JIT(just-in-time)技术的编译器，专注于执行速度，对Python代码进行动态编译，从而提高python的执行速度。
PyPy在处理python代码的过程中，一小部分功能的处理和CPython的执行结果是有差异的，如果项目中使用PyPy来进行执行效率的提升，一定要事先了解下PyPy和CPython的区别。
Cpython的线程操作系统的原生线程，在Linux的pthread完全由操作系统调度实现。
pthread本身不是线程安全的，需要使用者通过锁来实现多线程的安全运行，因此CPython解释器下Python实现多线程也必然存在线程不安全的问题。
这也就为GIL在多核时代的使用埋下了隐患。
Python是Guido van Rossum在1989年发布的，那个时候计算机的主频还没有达到1G，程序全部都是运行在单核计算机上面，直到2005年多核处理器才被 Intel 开发出来。
多核化对软件系统的冲击
戈登·摩尔1965年预测，每个集成电路的元件数量每18到24个月就会翻一倍，它的适用性预计会持续到2015年-2020年。
摩尔定律未失效前软件系统可以单纯借助硬件的进步来获得性能上的提升或者只需少量改进，就可以坐享性能飞跃。
然而从2005年开始，时钟速率的增长和晶体管的数量的增长已不再同步。
由于处理器材料的物理性质限制，时钟速率已停止增长甚至下降，处理器制造商开始将更多执行单元核心封装到单个芯片中。
这一趋势给应用程序开发和编程语言设计带来越来越大的压力。
程序员和编程语言决策者不得不考虑如何快速适应多核硬件，来提高软件性能和编程语言的市场占有率，Python 也不例外受到冲击。
多核化对CPython的冲击
在单核时代，崇尚优美，清晰，简单的吉多·范罗苏姆选择在解释器层面实现了一把全局互斥锁，来保护Python 对象而实现对单核CPU的使用率，这种做法在单核时代很奏效。
倘若在单核时代未选择GIL，那么开发者就需要自己实现任务的管理，这样做对于CPU的利用率提高无法做到极致。
但是随着多核时代的到来，高效的利用CPU核心的有效方法就是使用并行性，多线程是充分实现并行的好方法，但是CPython的GIL却阻碍了对多核CPU的利用。
痛并快乐着的GIL
CPython 的GIL给使用者带来了便利，并且在GIL的基础上开发了许多重要的Package和语言功能。
但是多核CPU的普适和其他语言对Python的冲击，让GIL显的原始而粗暴，无法有效利用多核处理器成为了弊端。
要搞清楚GIL对多线程程序的影响就要了解GIL运行基本原理。
单核CPU情况
CPyhon的Pthread是通过操作系统调度算法调度执行的。
Python解释器每执行一定数量的字节码，或遇到系统IO时，会强制释放GIL，然后触发一次操作系统的线程调度，实现单核CPU的充分利用，并且在单核上释放和重新执行的时间间隔非常短。
多核CPU情况
多核情况下多线程执行时，一个线程在CPU-A执行完之后释放GIL，其他CPU上的线程都会进行竞争，但CPU-A可能又马上获取到了GIL。
这就导致其他CPU上被唤醒的线程只能眼巴巴地看着CPU-A上的线程再次执行，而自己只能等待，直到又被切换到待调度的状态。
这就会产生多核CPU频繁进行线程切换，消耗着资源，但只有一个线程能够拿到GIL真正执行Python代码，这就导致多线程在多核CPU情况下，效率还不如单线程执行效率高。
这种情况非常类似于网络编程中的多个线程监听同一个端口造成的惊群现象，只不过是CPU级别的，造成的浪费更加奢侈。
- I/O 密集型
在单核CPU上执行多线程时由解释器实现了有效的切换，这一点是很有益处的。
在I/O密集型的诸如网络爬虫等类型的程序即使使用GIL控制下的多线程性能也不会像你想象中那么糟糕。 - CPU 密集型
对于CPU密集型的计算类程序GIL就有比较大的问题，因为CPU密集型的程序本身没有太多等待，不需要解释器介入并且所有任务只能等待1个核心，其他核心空闲也无法使用，这么看对多核的使用确实很糟糕。
GIL一直备受争议，为此PEP也多次尝试删除或者优化GIL，但是解释器本身的复杂性和众多GIL下的类库都让GIL移除成为了遥不可及的想法。
Python做为生命力极强的热门语言，绝对不会在多核时代坐以待毙。即便有GIL的限制，任然有许多方法让程序拥抱多核。 - 多进程
Python2.6引入了MultiProcess库来弥补Threading库中GIL带来的缺陷，基于此开发多进程程序，每个进程有单独的GIL，避免多进程之间对GIL的竞争，从而实现多核的利用。但是也带来了一些同步和通信问题，这也是必然会出现的。 - Ctypes
CPython的优势就是与C模块的结合，因此可以借助Ctypes调用C的动态库来实现将计算转移，C动态库没有GIL可以实现对多核的利用。 - 协程
协程也是一个很好的手段，在Python3.4之前没用对协程的支持，存在一些三方库的实现，比如gevent和Tornado。
Python3.4之后就内置了 asyncio 标准库真正实现了协程这一特性。
GIL任然是Python语言里最困难的技术挑战，GIL的问题并不是编程语言的本身问题，换做其他语言只是将问题转移到了用户层面，相反Python的作者尝试将这种问题转移到解释器给使用者呈现一个优雅的语言。
虽然多核时代到来暴露了GIL的缺陷，但是Python决策者和社区开发者已经做出来许多其他措施来拥抱多核，无知的诟病GIL是不明智的做法。
