本文环境: Python 2.7.10 (CPython)。
TOC
首先我们看下Global Interpreter Lock(GIL)的官方介绍:
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.)
简而言之,因为CPython的内存管理不是线程安全的,所以需要加一个全局解释锁来保障Python内部对象是线程安全的。
GIL的存在导致Python多线程是不完整的多线程,Python社区内部对是否保留GIL一致激烈讨论,这里我们就不在累述。
正如上节所说,Python的多线程是不完整的多线程。不过抛开具体应用场景谈“Python多线程是否鸡肋”就是耍流氓了!
为什么需要多线程呢?总结一下,多线程多应用在如下场景:
计算密集型任务的特点是要进行大量的计算,消耗CPU资源,比如计算圆周率、对视频进行高清解码等等,全靠CPU的运算能力。这种计算密集型任务虽然也可以用多任务完成,但是任务越多,花在任务切换的时间就越多,CPU执行任务的效率就越低,所以,要最高效地利用CPU,计算密集型任务同时进行的数量应当等于CPU的核心数。计算密集型任务由于主要消耗CPU资源,因此,代码运行效率至关重要。
IO密集型,涉及到网络、磁盘IO的任务都是IO密集型任务,这类任务的特点是CPU消耗很少,任务的大部分时间都在等待IO操作完成(因为IO的速度远远低于CPU和内存的速度)。对于IO密集型任务,任务越多,CPU效率越高,但也有一个限度。常见的大部分任务都是IO密集型任务,比如Web应用。IO密集型任务执行期间,99%的时间都花在IO上,花在CPU上的时间很少。
Python作为一门脚本语言,本身执行效率极低,完全不适合计算密集型任务的开发。再加上GIL的存在,需要花费大量时间用在线程间的切换,其多线程性能甚至低于单线程。以下是一个验证例子:
顺序执行的单线程(single_thread.py)
#! /usr/bin/python
from threading import Thread
import time
def my_counter():
i = 0
for _ in range(100000000):
i = i + 1
return True
def main():
thread_array = {}
start_time = time.time()
for tid in range(2):
t = Thread(target=my_counter)
t.start()
t.join()
end_time = time.time()
print("Total time: {}".format(end_time - start_time))
if __name__ == '__main__':
main()
同时执行的两个并发线程(multi_thread.py)
#! /usr/bin/python
from threading import Thread
import time
def my_counter():
i = 0
for _ in range(100000000):
i = i + 1
return True
def main():
thread_array = {}
start_time = time.time()
for tid in range(2):
t = Thread(target=my_counter)
t.start()
thread_array[tid] = t
for i in range(2):
thread_array[i].join()
end_time = time.time()
print("Total time: {}".format(end_time - start_time))
if __name__ == '__main__':
main()
多线程执行更慢了!
经过大量测试,Python多线程下一般最多只能占用1.5~2核,完全无法充分利用CPU资源。
在低计算场景(普通后台任务、IO密集型任务)下,Python多线程还是有一点用武之地。但是计算密集型任务的话,Python多线程是真鸡肋,甚至会严重拖后腿。
既然有GIL这个语言级的锁,那我们是不是可以不关注锁与线程安全,直接起飞了?
且看下面这个例子
#! /usr/bin/python
import threading
i = 0
def test():
global i
for x in range(100000):
i += 1
threads = [threading.Thread(target=test) for t in range(10)]
for t in threads:
t.start()
for t in threads:
t.join()
assert i == 100000, i
显然失败了。因为高级语言的一条语句执行时都是分为若干条执行码,即使一个简单的计算:i += 1,也是分为4个执行码。
Python解释器默认每100个操作码切换一个活动线程(通过从一个线程释放GIL以便另一个线程可以使用)。当100个操作码切换时,就会出现争抢,从而出现线程不安全的情况。此时就需要我们加一个简单的锁。
#!/usr/bin/python
import threading
i = 0
i_lock = threading.Lock()
def test():
global i
i_lock.acquire()
try:
for x in range(100000):
i += 1
finally:
i_lock.release()
threads = [threading.Thread(target=test) for t in range(10)]
for t in threads:
t.start()
for t in threads:
t.join()
assert i == 100000, i
相比Java那种天生面向多线程的语言不同,Python本身多线程就是不太完善的多线程。GIL的存在导致多线程CPU利用效率甚至低于单线程,却仍然要面对锁与线程安全的问题。同时Python语言又不像Java自带多种线程安全的数据类型,增加了多线程编程的复杂度,所以很少有资料大篇幅讲解Python多线程。
正如《Python高手之路》所言: (Python)处理好多线程是很难的,其复杂程度意味着与其他方式(异步事件\多进程)相比它是bug的更大来源,而且考虑到通常能够获取的好处很少,所以最好不要在多线程上浪费太多精力。
is-the-operator-thread-safe-in-python
《Python高手之路》(《The Hacker's Guide to Python》)
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。