python多线程性能（Python 的 GIL 是什么鬼，多线程性能究竟如何）

本文目录

• Python 的 GIL 是什么鬼，多线程性能究竟如何
• 为什么python多线程这么慢
• Python 多线程效率不高吗
• python多线程能提高效率吗

Python 的 GIL 是什么鬼，多线程性能究竟如何

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那么CPython实现中的GIL又是什么呢？GIL全称 Global Interpreter Lock 为了避免误导，我们还是来看一下官方给出的解释：In CPython, the global interpreter lock, or GIL, is a mutex that prevents multiple native threads from executing Python bytecodes at once. This lock is necessary mainly because CPython’s memory management is not thread-safe. (However, since the GIL exists, other features have grown to depend on the guarantees that it enforces.)好吧，是不是看上去很糟糕？一个防止多线程并发执行机器码的一个Mutex，乍一看就是个BUG般存在的全局锁嘛！别急，我们下面慢慢的分析。为什么会有GIL由于物理上得限制，各CPU厂商在核心频率上的比赛已经被多核所取代。为了更有效的利用多核处理器的性能，就出现了多线程的编程方式，而随之带来的就是线程间数据一致性和状态同步的困难。 即使在CPU内部的Cache也不例外 ，为了有效解决多份缓存之间的数据同步时各厂商花费了不少心思，也不可避免的带来了一定的性能损失。Python当然也逃不开，为了利用多核，Python开始支持多线程。 而解决多线程之间数据完整性和状态同步的最简单方法自然就是加锁。 于是有了GIL这把超级大锁，而当越来越多的代码库开发者接受了这种设定后，他们开始大量依赖这种特性（即默认python内部对象是thread-safe的，无需在实现时考虑额外的内存锁和同步操作）。慢慢的这种实现方式被发现是蛋疼且低效的。但当大家试图去拆分和去除GIL的时候，发现大量库代码开发者已经重度依赖GIL而非常难以去除了。有多难？做个类比，像MySQL这样的“小项目”为了把Buffer Pool Mutex这把大锁拆分成各个小锁也花了从5.5到5.6再到5.7多个大版为期近5年的时间，本且仍在继续。MySQL这个背后有公司支持且有固定开发团队的产品走的如此艰难，那又更何况Python这样核心开发和代码贡献者高度社区化的团队呢？所以简单的说GIL的存在更多的是历史原因。如果推到重来，多线程的问题依然还是要面对，但是至少会比目前GIL这种方式会更优雅。GIL的影响从上文的介绍和官方的定义来看，GIL无疑就是一把全局排他锁。毫无疑问全局锁的存在会对多线程的效率有不小影响。甚至就几乎等于Python是个单线程的程序。那么读者就会说了，全局锁只要释放的勤快效率也不会差啊。只要在进行耗时的IO操作的时候，能释放GIL，这样也还是可以提升运行效率的嘛。或者说再差也不会比单线程的效率差吧。理论上是这样，而实际上呢？Python比你想的更糟。下面我们就对比下Python在多线程和单线程下得效率对比。测试方法很简单，一个循环1亿次的计数器函数。一个通过单线程执行两次，一个多线程执行。最后比较执行总时间。测试环境为双核的Mac pro。注：为了减少线程库本身性能损耗对测试结果带来的影响，这里单线程的代码同样使用了线程。只是顺序的执行两次，模拟单线程。顺序执行的单线程(single_thread.py)#! /usr/bin/pythonfrom threading import Threadimport timedef my_counter():i = 0for _ in range(100000000):i = i + 1return Truedef main():thread_array = {}start_time = time.time()for tid in range(2):t = Thread(target=my_counter)t.start()thread_array = tfor i in range(2):thread_array.join()end_time = time.time()print("Total time: {}".format(end_time - start_time))if __name__ == ’__main__’:main()同时执行的两个并发线程(multi_thread.py)#! /usr/bin/pythonfrom threading import Threadimport timedef my_counter():i = 0for _ in range(100000000):i = i + 1return Truedef main():thread_array = {}start_time = time.time()for tid in range(2):t = Thread(target=my_counter)t.start()thread_array = tfor i in range(2):thread_array.join()end_time = time.time()print("Total time: {}".format(end_time - start_time))if __name__ == ’__main__’:main()

为什么python多线程这么慢

差不多是这样子。多线程目前仅用于网络多线程采集， 以及性能测试。 其它的语言也有类似的情况，线程本身的特点导致线程的适用范围是受限的。只有CPU过剩，而其它的任务很慢，此时用线程才是有益的，可以很好平衡等待时间，提高并发性能。线程的问题主要是线程的安全稳定性。线程无法强制中止，同时线程与主进程共享内存，可能会影响主进程的内存管理。 在python里线程出问题，可能会导致主进程崩溃。 虽然python里的线程是操作系统的真实线程。那么怎么解决呢？通过我们用进程方式。子进程崩溃后，会完全的释放所有的内存和错误状态。所以进程更安全。 另外通过进程，python可以很好的绕过GIL，这个全局锁问题。 但是进程也是有局限的。不要建立超过CPU总核数的进程，否则效率也不高。 简单的总结一下。当我们想实现多任务处理时，首先要想到使用multiprocessing， 但是如果觉着进程太笨重，那么就要考虑使用线程。 如果多任务处理中需要处理的太多了，可以考虑多进程，每个进程再采用多线程。如果还处理不要，就要使用轮询模式，比如使用poll event, twisted等方式。如果是GUI方式，则要通过事件机制，或者是消息机制处理，GUI使用单线程。所以在python里线程不要盲目用， 也不要滥用。 但是线程不安全是事实。如果仅仅是做几个后台任务，则可以考虑使用守护线程做。如果需要做一些危险操作，可能会崩溃的，就用子进程去做。 如果需要高度稳定性，同时并发数又不高的服务。则强烈建议用多进程的multiprocessing模块实现。在linux或者是unix里，进程的使用代价没有windows高。还是可以接受的。

Python 多线程效率不高吗

Python由于有全锁局的存在（同一时间只能有一个线程执行），并不能利用多核优势。所以，如果你的多线程进程是CPU密集型的，那多线程并不能带来效率上的提升，相反还可能会因为线程的频繁切换，导致效率下降；如果是IO密集型，多线程进程可以利用IO阻塞等待时的空闲时间执行其他线程，提升效率。

python多线程能提高效率吗

• 如果你的代码是CPU密集型，多个线程的代码很有可能是线性执行的。所以这种情况下多线程是鸡肋，效率可能还不如单线程因为有context switch但是：如果你的代码是IO密集型，多线程可以明显提高效率。例如制作爬虫（我就不明白为什么Python总和爬虫联系在一起…不过也只想起来这个例子…），绝大多数时间爬虫是在等待socket返回数据。这个时候C代码里是有release GIL的，最终结果是某个线程等待IO的时候其他线程可以继续执行。反过来讲：你就不应该用Python写CPU密集型的代码…效率摆在那里…如果确实需要在CPU密集型的代码里用concurrent，就去用multiprocessing库。这个库是基于multi process实现了类multi thread的API接口，并且用pickle部分地实现了变量共享。再加一条，如果你不知道你的代码到底算CPU密集型还是IO密集型，教你个方法：multiprocessing这个module有一个dummy的sub module，它是基于multithread实现了multiprocessing的API。假设你使用的是multiprocessing的Pool，是使用多进程实现了concurrencyfrom multiprocessing import Pool如果把这个代码改成下面这样，就变成多线程实现concurrencyfrom multiprocessing.dummy import Pool两种方式都跑一下，哪个速度快用哪个就行了。UPDATE:刚刚才发现concurrent.futures这个东西，包含ThreadPoolExecutor和ProcessPoolExecutor，可能比multiprocessing更简单