一 引子
在Cpython解释器中,同一个进程下开启的多线程,同一时刻只能有一个线程执行,无法利用多核优势首先:需要明确的一点是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
二 GIL介绍
GIL本质就是一把互斥锁,既然是互斥锁,所有互斥锁的本质都一样,都是将并发运行变成串行,以此来控制同一时间内共享数据只能被一个任务所修改,进而保证数据安全。
可以肯定一点是:保护不同的数据的安全,就应该加不同的锁
要想了解GIL,首先确定一段,每次执行Python程序,就会产生一个独立的进程。例如Python test.py,python aaa.py,python bb.py 会产生3个不同的Python进程
验证Python test.py只会产生一个进程
1 2 3 4 |
|
1 2 3 4 5 6 7 8 |
|
在一个Python的进程内,不仅有test.py的主线程或者由该主线程开启的其它线程,还有解释器开启的垃圾回收等解释器级别的线程,总之,所有线程都运行在一个进程内
1 2 3 4 |
|
综上:
如果多个线程的target=work,那么执行流程是:
多个线程先访问到解释器的代码,即拿到执行权限,然后将target的代码交给解释器的代码去执行
解释器的代码是所有线程共享,所以垃圾回收线程也可能访问到解释器的代码而去执行,这就导致了一个问题:对于同一个数据100,可能线程1执行x=100的同时,而垃圾回收执行的是回收100的操作,解决这种问题没有声明高明的方法,就是加锁处理,如下图的GIL,保证Python解释器同一时间只能执行一个任务的代码
三 GIL与Lock
问题:Python已经有一个GIL来保证同一时间只能有一个线程来执行了,为什么这里还需要lock?
首先:我们需要达成共识:锁的目的是为了保护共享的数据,同一时间只能有一个线程来修改共享的数据
然后:我们可以得出结论:保护不同的数据就应该加不同的锁
最后:问题是很明朗了,GIL与LOCK是两把锁,保护的数据不一样,前者是解释器级别的(当然保护的就是解释器级别的数据,比如垃圾回收的数据),后者是保护用户自己开发的应用程序的数据,很明显GIL
负责这件事,只能用户自定义加锁处理,即Lock,如下图:
分析:
1 2 3 4 5 6 7 |
|
示例代码:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
|
四 GIL与多线程
有了GIL的存在,同一时刻同一进程中只有一个线程被执行
问题:进程可以利用多核,但是开销大,而Python的多线程开销小,但却无法利用多核优势,也就是说Python没用了,PHP才是最牛B的语言?
要解决这个问题,我们需要在几个点上达成一致:
1 2 3 4 5 |
|
一个工人相当于CPU,此时计算相当于工人在干活,I/O阻塞相当于为工人干活提供所需原材料的过程,工人干活的过程中如果没有原材料了,则工人干活的过程需要停止,直到原材料的到来
如果你的工厂的大多数任务需要有准备原材料的过程(I/O密集型),那么你有再多的工人,意义也不大,还不如一个人,在等材料的过程中让工人去干别的活
反过来讲,如果你的工厂原材料都齐全,那当然是工人越多,效率越高
结论:
1 2 3 |
|
假设我们有四个任务需要处理,处理方式肯定是要玩出并发的效果,解决方案可以是:
1 2 3 |
|
单核情况下,分析结果:
1 2 |
|
多核情况下,分析结果:
1 2 |
|
结论:
现在计算机基本上都是多核,Python对于计算密集型的任务开多个线程的效率并不能带来多大性能上的提升,甚者不如串行(没有大量切换),但是,对于I/O密集型的任务效率还是有显著提升的
五 多线程性能测试
如果并发的多个任务是计算 密集型:多进程效率高
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
|
如果并发的多个任务是I/O密集型:多线程效率高
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
|
应用
1 2 |
|