Cpython的多线程技术之痛

历史原因

在Python官网下载的默认解释器是采用C语言编写的Cpython解释器。在Python语言开发之初，计算机都是单核CPU，每个单核CPU同一时刻只能运行一个线程。为了模拟多线程工作，这里采用了模拟机制，让不同线程根据时间片段，轮流着去执行数据，使多线程具有相对均衡的时间机会使用CPU计算资源。基于当时的CPU技术，python语言发明人采用了单核CPU技术进程技术。为了保证线程执行的安全，在Cpython解释器上提供了全局解释器锁（Global Interpreter Lock，GIL），当在Cpython解释器上执行python代码时，GIL会保护代码的线程独立使用共享数据，直到解释器遇到I/O操作或者操作次数达到一定数目时才会释放GIL。所以Cpython解释器整体作为一个进程，同一时间只有一个获得GIL保护的线程在执行，其他线程则处于等待状态。由此，得出Cpython解释器下多线程执行的结论。

1、Cpython解释器环境下的python语言只存在模拟多线程状态，不存在真正的并发多线程。也就是说，在多核CPU情况下，无法利用多喝同时执行多个线程，以提高执行效率。

2、Cpython受全局解释器锁保护，提供了模拟多线程执行安全，但是无法实现真正的并发多线程。

3、多线程有两个应用方向，即CPU-bound（计算密集型）和I/Obound（I/O密集型）。计算密集型任务主要通过多线程，充分利用CPU的资源（特别是多核计算资源）解决特定复杂计算问题，如复杂的科学计算算法。I/O密集型任务主要通过多线程，对磁盘I/O、网络I/O进行读写处理，CPU计算任务比较小。这符合GIL快速锁定、快速释放特点。

由此可以得出CPython解释器环境下易执行I/O多线程操作，避免利用它做CPU多线程操作。
所以在CPython解释器下执行的多线程都受GIL这把全局锁保护，使多线程在某一时刻访问数据共享资源时，只能允许一个线程执行。这样保证了线程之间的安全，避免了数据共享资源的冲突，但是做不到真正的多线程并发处理。（其实Cpython的GIL问题是Python开源社区最难解决、最头疼的问题，为了避开其多线程技术的缺陷，甚至有专家建议用其他方法代替。）

python的多线程技术的替代方案

1、采用Jython、IronPython、PyPy等其他解释器。上述几种解释器不受GIL约束，实现了真正意义上的多线程并发技术。

2、利用ctypes模块绕过GIL约束。ctypes提供了在Python语言环境下调用C语言动态库的能力。借助C语言函数的功能实现对多内核CPU的使用。ctypes模块使用C语言方法，详见官网提供的《Python使用文档》的标准库相关文章内容。

3、利用multiprocessing模块、
subprocess模块
子进程模块允许通过产生新的进程连接到它们的输入、输出、错误管道中，并获得它们的返回代码。该模块旨在替换几个较旧的模块和功能。

sched模块、
调度模块定义了一个实现通用事件调度器的类。

4、concurrent模块，concurrent.futures模块为异步执行可调用对象提供了一个高级接口。该模块的ProcessPoolExecutor类可被用来在一个单独的Python解释器中执行计算密集型函数，并在多核CPU里并行执行。

5、不同编程语言有不同编程语言的应用优势，显然Python在多线程编程方面存在一些缺陷。如果纯粹为了解决多线程编程和应用问题，也可以选择其他功能更加强大的编程语言，如C、C++、Java等。