为啥有人说 Python 的多线程是鸡肋

Posted 2023-05-08

因为 Python 中臭名昭著的 GIL。

那么 GIL 是什么？为什么会有 GIL？多线程真的是鸡肋吗？ GIL 可以去掉吗？带着这些问题，我们一起往下看，同时需要你有一点点耐心。

多线程是不是鸡肋，我们先做个实验，实验非常简单，就是将数字 “1亿” 递减，减到 0 程序就终止，这个任务如果我们使用单线程来执行，完成时间会是多少？使用多线程又会是多少？show me the code

单线程

在我的4核 CPU 计算机中，单线程所花的时间是 6.5 秒。可能有人会问，线程在哪里？其实任何程序运行时，默认都会有一个主线程在执行。（关于线程与进程这里不展开，我会单独开一篇文章）

多线程

创建两个子线程 t1、t2，每个线程各执行 5 千万次减操作，等两个线程都执行完后，主线程终止程序运行。结果，两个线程以合作的方式执行是 6.8 秒，反而变慢了。按理来说，两个线程同时并行地运行在两个 CPU 之上，时间应该减半才对，现在不减反增。

是什么原因导致多线程不快反慢的呢？

原因就在于 GIL ，在 Cpython 解释器（Python语言的主流解释器）中，有一把全局解释锁（Global Interpreter Lock），在解释器解释执行 Python 代码时，先要得到这把锁，意味着，任何时候只可能有一个线程在执行代码，其它线程要想获得 CPU 执行代码指令，就必须先获得这把锁，如果锁被其它线程占用了，那么该线程就只能等待，直到占有该锁的线程释放锁才有执行代码指令的可能。

因此，这也就是为什么两个线程一起执行反而更加慢的原因，因为同一时刻，只有一个线程在运行，其它线程只能等待，即使是多核CPU，也没办法让多个线程「并行」地同时执行代码，只能是交替执行，因为多线程涉及到上线文切换、锁机制处理（获取锁，释放锁等），所以，多线程执行不快反慢。

什么时候 GIL 被释放呢？

当一个线程遇到 I/O 任务时，将释放GIL。计算密集型（CPU-bound）线程执行 100 次解释器的计步（ticks）时（计步可粗略看作 Python 虚拟机的指令），也会释放 GIL。可以通过设置计步长度，查看计步长度。相比单线程，这些多是多线程带来的额外开销

CPython 解释器为什么要这样设计？

多线程是为了适应现代计算机硬件高速发展充分利用多核处理器的产物，通过多线程使得 CPU 资源可以被高效利用起来，Python 诞生于1991年，那时候硬件配置远没有今天这样豪华，现在一台普通服务器32核64G内存都不是什么司空见惯的事

但是多线程有个问题，怎么解决共享数据的同步、一致性问题，因为，对于多个线程访问共享数据时，可能有两个线程同时修改一个数据情况，如果没有合适的机制保证数据的一致性，那么程序最终导致异常，所以，Python之父就搞了个全局的线程锁，不管你数据有没有同步问题，反正一刀切，上个全局锁，保证数据安全。这也就是多线程鸡肋的原因，因为它没有细粒度的控制数据的安全，而是用一种简单粗暴的方式来解决。

这种解决办法放在90年代，其实是没什么问题的，毕竟，那时候的硬件配置还很简陋，单核 CPU 还是主流，多线程的应用场景也不多，大部分时候还是以单线程的方式运行，单线程不要涉及线程的上下文切换，效率反而比多线程更高（在多核环境下，不适用此规则）。所以，采用 GIL 的方式来保证数据的一致性和安全，未必不可取，至少在当时是一种成本很低的实现方式。

那么把 GIL 去掉可行吗？

还真有人这么干多，但是结果令人失望，在1999年Greg Stein 和Mark Hammond 两位哥们就创建了一个去掉 GIL 的 Python 分支，在所有可变数据结构上把 GIL 替换为更为细粒度的锁。然而，做过了基准测试之后，去掉GIL的 Python 在单线程条件下执行效率将近慢了2倍。

Python之父表示：基于以上的考虑，去掉GIL没有太大的价值而不必花太多精力。

参考技术A 差不多是这样子。多线程目前仅用于网络多线程采集， 以及性能测试。

其它的语言也有类似的情况，线程本身的特点导致线程的适用范围是受限的。只有CPU过剩，而其它的任务很慢，此时用线程才是有益的，可以很好平衡等待时间，提高并发性能。

线程的问题主要是线程的安全稳定性。线程无法强制中止，同时线程与主进程共享内存，可能会影响主进程的内存管理。

在python里线程出问题，可能会导致主进程崩溃。 虽然python里的线程是操作系统的真实线程。

那么怎么解决呢？通过我们用进程方式。子进程崩溃后，会完全的释放所有的内存和错误状态。所以进程更安全。 另外通过进程，python可以很好的绕过GIL，这个全局锁问题。

但是进程也是有局限的。不要建立超过CPU总核数的进程，否则效率也不高。

简单的总结一下。
当我们想实现多任务处理时，首先要想到使用multiprocessing， 但是如果觉着进程太笨重，那么就要考虑使用线程。 如果多任务处理中需要处理的太多了，可以考虑多进程，每个进程再采用多线程。如果还处理不要，就要使用轮询模式，比如使用poll event, twisted等方式。如果是GUI方式，则要通过事件机制，或者是消息机制处理，GUI使用单线程。

所以在python里线程不要盲目用， 也不要滥用。 但是线程不安全是事实。如果仅仅是做几个后台任务，则可以考虑使用守护线程做。如果需要做一些危险操作，可能会崩溃的，就用子进程去做。 如果需要高度稳定性，同时并发数又不高的服务。则强烈建议用多进程的multiprocessing模块实现。

在linux或者是unix里，进程的使用代价没有windows高。还是可以接受的。 参考技术B 差不多是这样子。多线程目前仅用于网络多线程采集， 以及性能测试。

其它的语言也有类似的情况，线程本身的特点导致线程的适用范围是受限的。只有CPU过剩，而其它的任务很慢，此时用线程才是有益的，可以很好平衡等待时间，提高并发性能。

线程的问题主要是线程的安全稳定性。线程无法强制中止，同时线程与主进程共享内存，可能会影响主进程的内存管理。

在python里线程出问题，可能会导致主进程崩溃。 虽然python里的线程是操作系统的真实线程。

那么怎么解决呢？通过我们用进程方式。子进程崩溃后，会完全的释放所有的内存和错误状态。所以进程更安全。 另外通过进程，python可以很好的绕过GIL，这个全局锁问题。

但是进程也是有局限的。不要建立超过CPU总核数的进程，否则效率也不高。

简单的总结一下。
当我们想实现多任务处理时，首先要想到使用multiprocessing， 但是如果觉着进程太笨重，那么就要考虑使用线程。 如果多任务处理中需要处理的太多了，可以考虑多进程，每个进程再采用多线程。如果还处理不要，就要使用轮询模式，比如使用poll event, twisted等方式。如果是GUI方式，则要通过事件机制，或者是消息机制处理，GUI使用单线程。

所以在python里线程不要盲目用， 也不要滥用。 但是线程不安全是事实。如果仅仅是做几个后台任务，则可以考虑使用守护线程做。如果需要做一些危险操作，可能会崩溃的，就用子进程去做。 如果需要高度稳定性，同时并发数又不高的服务。则强烈建议用多进程的multiprocessing模块实现。

在linux或者是unix里，进程的使用代价没有windows高。还是可以接受的。本回答被提问者和网友采纳 参考技术C Python多线程是不是鸡肋，是，GIL那个东西再那里摆着，就算在多核下面Python也是无法并行的，这个好理解嘛，就相当于做了个分时复用。
Python多线程有没有用，有，你去爬图片站的时候，用单进程单线程这种方式，进程很容易阻塞在获取数据socket函数上，多线程可以缓解这种情况。你说解决没有，要是每个请求都阻塞起了，那多线程也没什么用（当然，这种情况没见过哈）。
Python的优势就在于写起来快，用起来方便。你要做计算密集型的，还想并行化的话，还是用C吧。

Python多进程和多线程是鸡肋嘛？转

GIL是什么

Python的代码执行由 Python虚拟机（也叫解释器主循环，CPython版本）来控制，Python在设计之初就考虑到在解释器的主循环中，同时只有一个线程在运行。即每个CPU在任意时刻只有一个线程在解释器中运行。对 Python虚拟机访问的控制由全局解释锁GIL控制，正是这个锁来控制同一时刻只有一个线程能够运行。——在单核CPU下的多线程其实都只是并发，不是并行 。

并发与并行区别

• 并发：两个或多个事件在同一时间间隔发生，或者说交替做不同事件的能力，或者说不同的代码块交替执行。
• 并行：两个或者多个事件在同一时刻发生，或者说同时做不同事件的能力，或者说不同的代码块同时执行。

 

并发和并行的意义

并发和并行都可以处理“多任务”，二者的主要区别在于是否是“同时进行”多个的任务。但是涉及到任务分解（有先后依赖耦合度高的任务无法做到并行）、任务运行（可能要考虑互斥、锁、共享等）、结果合并。

---

Python 下的多线程

在Python多线程下，每个线程的执行方式，如下：

1. 获取GIL
2. 切换到这个线程去执行
3. 运行代码，这里有两种机制：
4. 指定数量的字节码指令（100个）
5. 固定时间15ms线程主动让出控制
6. 把线程设置为睡眠状态
7. 释放GIL
8. 再次重复以上步骤

在Python2中，在解释器解释执行任何 Python 代码时，都需要先获得这把锁才行（同一时间只会有一个获得了 GIL 的线程在跑，其它的线程都处于等待状态等着 GIL 的释放），在遇到 I/O 操作时会释放这把锁。如果是纯计算的程序，没有 I/O 操作，解释器会每隔 100 次操作就释放这把锁，让别的线程有机会执行（这个次数可以通过 sys.setcheckinterval 来调整）也正是这种设定，是的多线程的CPU密集型计算非常鸡肋，下面会讲到为何如此。

而在python3中，GIL不使用ticks计数(100次，释放GIL)，改为使用计时器（执行时间达到15ms阈值后，当前线程释放 GIL），使得执行计算的次数更多，释放次数减少，这样对CPU密集型程序更加友好，但依然没有解决GIL导致的同一时间只能执行一个线程的问题，所以效率依然不尽如人意。

---

那么是不是Python的多线程是鸡肋嘛？

CPU密集型(各种循环处理、计数等等)，在这种情况下，ticks计数很快就会达到阈值，然后触发GIL的释放与再竞争（多个线程来回切换是需要消耗资源的），所以python下的多线程对 CPU密集型代码并不友好，会触发相当频繁的线程切换。

IO密集型(文件处理、网络爬虫等)，多线程能够有效提升效率(单线程下有IO操作会进行IO 等待，造成不必要的时间浪费，而开启多线程能在线程A等待时，自动切换到线程B，可以不浪费 CPU的资源，从而能提升程序执行效率，一个线程获得GIL发送消息，然后等待返回消息（阻塞），Python此时释放GIL, 其他线程得到GIL发送消息，然后同样等待返回消息（阻塞）......，这样保证了IO传输过程时间的合理利用，减少了IO等待造成的资源浪费，提高IO传输效率)。所以python的多线程对IO密集型代码比较友好。

---

有哪些结论？

I/O密集型使用多线程并发执行提高效率、计算密集型使用多进程（multiprocessing ）并行执行提高效率。通常程序既包含IO操作又包含计算操作,那么这种情况下，在开始并发任务之前，可以先进行测试，测试多线程、多进程哪个效率高就是用哪种方式。

请注意：多核多线程比单核多线程更差，多核多进程下，CPU1释放GIL后，其他CPU上的线程都会进行竞争，但GIL可能会马上又被CPU1拿到，CPU2释放GIL后……，导致其他几个CPU上被唤醒后的线程会醒着等待到切换时间后又进入待调度状态，这样会造成线程颠簸(thrashing)，导致效率更低。

多线程下的CPU密集型计算也不是无药可医，可以利用ctypes绕过GIL，ctypes可以使py直接调用任意的C动态库的导出函数。所要做的只是把关键部分用 C/C++ 写成 Python 扩展。而且，ctypes会在调用C函数前释放GIL。

同时，可以了解下协程，又称微线程。

协程最大的优势就是协程极高的执行效率。因为子程序切换不是线程切换，而是由程序自身控制，因此，没有线程切换的开销，和多线程比，线程数量越多，协程的性能优势就越明显。

第二大优势就是不需要多线程的锁机制，因为只有一个线程，也不存在同时写变量冲突，在协程中控制共享资源不加锁，只需要判断状态就好了，所以执行效率比多线程高很多。

因为协程是一个线程执行，那怎么利用多核CPU呢？最简单的方法是多进程+协程，既充分利用多核，又充分发挥协程的高效率，可获得极高的性能。

 

转自

Python多进程和多线程是鸡肋嘛？ https://www.toutiao.com/a6738231652184490247/