GIL影响

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

前言：博主在刚接触Python的时候时常听到GIL这个词，并且发现这个词经常和Python无法高效的实现多线程划上等号。本着不光要知其然，还要知其所以然的研究态度，博主搜集了各方面的资料，花了一周内几个小时的闲暇时间深入理解了下GIL，并归纳成此文，也希望读者能通过次本文更好且客观的理解GIL。

文章欢迎转载，但转载时请保留本段文字，并置于文章的顶部 作者：卢钧轶(cenalulu) 本文原文地址：http://cenalulu.github.io/python/gil-in-python/

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/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在多线程的情况下居然比单线程整整慢了45%。按照之前的分析，即使是有GIL全局锁的存在，串行化的多线程也应该和单线程有一样的效率才对。那么怎么会有这么糟糕的结果呢？

让我们通过GIL的实现原理来分析这其中的原因。

---

当前GIL设计的缺陷

基于pcode数量的调度方式

按照Python社区的想法，操作系统本身的线程调度已经非常成熟稳定了，没有必要自己搞一套。所以Python的线程就是C语言的一个pthread，并通过操作系统调度算法进行调度（例如linux是CFS）。为了让各个线程能够平均利用CPU时间，python会计算当前已执行的微代码数量，达到一定阈值后就强制释放GIL。而这时也会触发一次操作系统的线程调度（当然是否真正进行上下文切换由操作系统自主决定）。

伪代码

while True:
    acquire GIL
    for i in 1000:
        do something
    release GIL
    /* Give Operating System a chance to do thread scheduling */

这种模式在只有一个CPU核心的情况下毫无问题。任何一个线程被唤起时都能成功获得到GIL（因为只有释放了GIL才会引发线程调度）。但当CPU有多个核心的时候，问题就来了。从伪代码可以看到，从release GIL到acquire GIL之间几乎是没有间隙的。所以当其他在其他核心上的线程被唤醒时，大部分情况下主线程已经又再一次获取到GIL了。这个时候被唤醒执行的线程只能白白的浪费CPU时间，看着另一个线程拿着GIL欢快的执行着。然后达到切换时间后进入待调度状态，再被唤醒，再等待，以此往复恶性循环。

PS：当然这种实现方式是原始而丑陋的，Python的每个版本中也在逐渐改进GIL和线程调度之间的互动关系。例如先尝试持有GIL在做线程上下文切换，在IO等待时释放GIL等尝试。但是无法改变的是GIL的存在使得操作系统线程调度的这个本来就昂贵的操作变得更奢侈了。 关于GIL影响的扩展阅读

为了直观的理解GIL对于多线程带来的性能影响，这里直接借用的一张测试结果图（见下图）。图中表示的是两个线程在双核CPU上得执行情况。两个线程均为CPU密集型运算线程。绿色部分表示该线程在运行，且在执行有用的计算，红色部分为线程被调度唤醒，但是无法获取GIL导致无法进行有效运算等待的时间。 由图可见，GIL的存在导致多线程无法很好的立即多核CPU的并发处理能力。

那么Python的IO密集型线程能否从多线程中受益呢？我们来看下面这张测试结果。颜色代表的含义和上图一致。白色部分表示IO线程处于等待。可见，当IO线程收到数据包引起终端切换后，仍然由于一个CPU密集型线程的存在，导致无法获取GIL锁，从而进行无尽的循环等待。 

简单的总结下就是：Python的多线程在多核CPU上，只对于IO密集型计算产生正面效果；而当有至少有一个CPU密集型线程存在，那么多线程效率会由于GIL而大幅下降。

---

如何避免受到GIL的影响

说了那么多，如果不说解决方案就仅仅是个科普帖，然并卵。GIL这么烂，有没有办法绕过呢？我们来看看有哪些现成的方案。

用multiprocessing替代Thread

multiprocessing库的出现很大程度上是为了弥补thread库因为GIL而低效的缺陷。它完整的复制了一套thread所提供的接口方便迁移。唯一的不同就是它使用了多进程而不是多线程。每个进程有自己的独立的GIL，因此也不会出现进程之间的GIL争抢。

当然multiprocessing也不是万能良药。它的引入会增加程序实现时线程间数据通讯和同步的困难。就拿计数器来举例子，如果我们要多个线程累加同一个变量，对于thread来说，申明一个global变量，用thread.Lock的context包裹住三行就搞定了。而multiprocessing由于进程之间无法看到对方的数据，只能通过在主线程申明一个Queue，put再get或者用share memory的方法。这个额外的实现成本使得本来就非常痛苦的多线程程序编码，变得更加痛苦了。具体难点在哪有兴趣的读者可以扩展阅读这篇文章

用其他解析器

之前也提到了既然GIL只是CPython的产物，那么其他解析器是不是更好呢？没错，像JPython和IronPython这样的解析器由于实现语言的特性，他们不需要GIL的帮助。然而由于用了Java/C#用于解析器实现，他们也失去了利用社区众多C语言模块有用特性的机会。所以这些解析器也因此一直都比较小众。毕竟功能和性能大家在初期都会选择前者，Done is better than perfect。

所以没救了么？

当然Python社区也在非常努力的不断改进GIL，甚至是尝试去除GIL。并在各个小版本中有了不少的进步。有兴趣的读者可以扩展阅读这个Slide 另一个改进Reworking the GIL

• 将切换颗粒度从基于opcode计数改成基于时间片计数
• 避免最近一次释放GIL锁的线程再次被立即调度
• 新增线程优先级功能（高优先级线程可以迫使其他线程释放所持有的GIL锁）

总结

Python GIL其实是功能和性能之间权衡后的产物，它尤其存在的合理性，也有较难改变的客观因素。从本分的分析中，我们可以做以下一些简单的总结：

因为GIL的存在，只有IO Bound场景下得多线程会得到较好的性能

如果对并行计算性能较高的程序可以考虑把核心部分也成C模块，或者索性用其他语言实现

GIL在较长一段时间内将会继续存在，但是会不断对其进行改进                  

这里：

• 1	static PyThread_type_lock interpreter_lock = 0 ; /* This is the GIL */

  这一行代码摘自 ceval.c —— CPython 2.7 解释器的源代码，Guido van Rossum 的注释”This is the GIL“ 添加于2003 年，但这个锁本身可以追溯到1997年他的第一个多线程 Python 解释器。在 Unix系统中，PyThread_type_lock 是标准 C  mutex_t 锁的别名。当 Python 解释器启动时它初始化：

  1 2 3 4 5 6

  void PyEval_InitThreads ( void ) {      interpreter_lock = PyThread_allocate_lock ( ) ;      PyThread_acquire_lock ( interpreter_lock ) ; }

  解释器中的所有 C 代码在执行 Python 时必须保持这个锁。Guido 最初加这个锁是因为它使用起来简单。而且每次从 CPython 中去除 GIL 的尝试会耗费单线程程序太多性能，尽管去除 GIL 会带来多线程程序性能的提升，但仍是不值得的。（前者是Guido最为关切的, 也是不去除 GIL 最重要的原因, 一个简单的尝试是在1999年, 最终的结果是导致单线程的程序速度下降了几乎2倍.）

  GIL 对程序中线程的影响足够简单，你可以在手背上写下这个原则：“一个线程运行 Python ，而其他 N 个睡眠或者等待 I/O.”（即保证同一时刻只有一个线程对共享资源进行存取）  Python 线程也可以等待threading.Lock或者线程模块中的其他同步对象；线程处于这种状态也称之为”睡眠“。

  
  

  线程何时切换？一个线程无论何时开始睡眠或等待网络 I/O，其他线程总有机会获取 GIL 执行 Python 代码。这是协同式多任务处理。CPython 也还有抢占式多任务处理。如果一个线程不间断地在 Python 2 中运行 1000 字节码指令，或者不间断地在 Python 3 运行15 毫秒，那么它便会放弃 GIL，而其他线程可以运行。把这想象成旧日有多个线程但只有一个 CPU 时的时间片。我将具体讨论这两种多任务处理。

  
  

  把 Python 看作是旧时的大型主机，多个任务共用一个CPU。

  协同式多任务处理

  当一项任务比如网络 I/O启动，而在长的或不确定的时间，没有运行任何 Python 代码的需要，一个线程便会让出GIL，从而其他线程可以获取 GIL 而运行 Python。这种礼貌行为称为协同式多任务处理，它允许并发；多个线程同时等待不同事件。

  也就是说两个线程各自分别连接一个套接字：
  1 2 3 4 5 6 7

  def do_connect ( ) :      s = socket . socket ( )      s . connect ( ( 'python.org' , 80 ) )    # drop the GIL   for i in range ( 2 ) :      t = threading . Thread ( target = do_connect )      t . start ( )

  两个线程在同一时刻只能有一个执行 Python ，但一旦线程开始连接，它就会放弃 GIL ，这样其他线程就可以运行。这意味着两个线程可以并发等待套接字连接，这是一件好事。在同样的时间内它们可以做更多的工作。

  让我们打开盒子，看看一个线程在连接建立时实际是如何放弃 GIL 的，在 socketmodule.c 中:

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

  /* s.connect((host, port)) method */ static PyObject * sock_connect ( PySocketSockObject * s , PyObject * addro ) {      sock_addr_t addrbuf ;      int addrlen ;      int res ;        /* convert (host, port) tuple to C address */      getsockaddrarg ( s , addro , SAS2SA ( & addrbuf ) , & addrlen ) ;        Py_BEGIN_ALLOW_THREADS      res = connect ( s -> sock_fd , addr , addrlen ) ;      Py_END_ALLOW _THREADS        /* error handling and so on .... */ }

  线程正是在Py_BEGIN_ALLOW_THREADS 宏处放弃 GIL；它被简单定义为：

  1	PyThread_release_lock ( interpreter_lock ) ;

  当然 Py_END_ALLOW_THREADS 重新获取锁。一个线程可能会在这个位置堵塞，等待另一个线程释放锁；一旦这种情况发生，等待的线程会抢夺回锁，并恢复执行你的Python代码。简而言之：当N个线程在网络 I/O 堵塞，或等待重新获取GIL，而一个线程运行Python。

  下面来看一个使用协同式多任务处理快速抓取许多 URL 的完整例子。但在此之前，先对比下协同式多任务处理和其他形式的多任务处理。

  抢占式多任务处理

  Python线程可以主动释放 GIL，也可以先发制人抓取 GIL 。

  让我们回顾下 Python 是如何运行的。你的程序分两个阶段运行。首先，Python文本被编译成一个名为字节码的简单二进制格式。第二，Python解释器的主回路，一个名叫 pyeval_evalframeex() 的函数，流畅地读取字节码，逐个执行其中的指令。

  当解释器通过字节码时，它会定期放弃GIL，而不需要经过正在执行代码的线程允许，这样其他线程便能运行：

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

  for ( ; ; ) {      if ( -- ticker < 0 ) {          ticker = check_interval ;            /* Give another thread a chance */          PyThread_release_lock ( interpreter_lock ) ;            /* Other threads may run now */            PyThread_acquire_lock ( interpreter_lock , 1 ) ;      }        bytecode = * next_instr ++ ;      switch ( bytecode ) {          /* execute the next instruction ... */      } }

  默认情况下，检测间隔是1000 字节码。所有线程都运行相同的代码，并以相同的方式定期从他们的锁中抽出。在 Python 3 GIL 的实施更加复杂，检测间隔不是一个固定数目的字节码，而是15 毫秒。然而，对于你的代码，这些差异并不显著。

  Python中的线程安全

  
  

  将多个线状物编织在一起，需要技能。

  如果一个线程可以随时失去 GIL，你必须使让代码线程安全。 然而 Python 程序员对线程安全的看法大不同于 C 或者 Java 程序员，因为许多 Python 操作是原子的。

  在列表中调用 sort()，就是原子操作的例子。线程不能在排序期间被打断，其他线程从来看不到列表排序的部分，也不会在列表排序之前看到过期的数据。原子操作简化了我们的生活，但也有意外。例如，+ = 似乎比 sort() 函数简单，但+ =不是原子操作。你怎么知道哪些操作是原子的，哪些不是？
  看看这个代码：
  1 2 3 4 5

  n = 0 def foo ( ) :      global n      n += 1

  我们可以看到这个函数用 Python 的标准 dis 模块编译的字节码：

  1 2 3 4 5 6

  >>> import dis >>> dis . dis ( foo ) LOAD _GLOBAL                0 ( n ) LOAD _CONST                1 ( 1 ) INPLACE_ADD STORE _GLOBAL              0 ( n )

  代码的一行中， n += 1，被编译成 4 个字节码，进行 4 个基本操作：

  1. 将 n 值加载到堆栈上
  2. 将常数 1 加载到堆栈上
  3. 将堆栈顶部的两个值相加
  4. 将总和存储回 n
  记住，一个线程每运行 1000 字节码，就会被解释器打断夺走 GIL 。如果运气不好，这（打断）可能发生在线程加载 n 值到堆栈期间，以及把它存储回 n 期间。很容易可以看到这个过程会如何导致更新丢失：
  1 2 3 4 5 6 7 8 9 10 11 12

  threads = [ ] for i in range ( 100 ) :      t = threading . Thread ( target = foo )      threads . append ( t ) for t in threads :      t . start ( ) for t in threads :      t . join ( ) print ( n )

  通常这个代码输出 100，因为 100 个线程每个都递增 n 。但有时你会看到 99 或 98 ，如果一个线程的更新被另一个覆盖。
  所以，尽管有 GIL，你仍然需要加锁来保护共享的可变状态：
  1 2 3 4 5 6 7

  n = 0 lock = threading . Lock ( ) def foo ( ) :      global n      with lock :          n += 1

  如果我们使用一个原子操作比如 sort() 函数会如何呢？：

  1 2 3 4

  lst = [ 4 , 1 , 3 , 2 ] def foo ( ) :      lst . sort ( )

  这个函数的字节码显示 sort() 函数不能被中断，因为它是原子的：

  1 2 3 4

  >>> dis . dis ( foo ) LOAD _GLOBAL                0 ( lst ) LOAD _ATTR                  1 ( sort ) CALL _FUNCTION              0

  一行被编译成 3 个字节码：

  1. 将 lst 值加载到堆栈上
  2. 将其排序方法加载到堆栈上
  3. 调用排序方法

  即使这一行  lst.sort() 分几个步骤，调用 sort 自身是单个字节码，因此线程没有机会在调用期间抓取 GIL 。我们可以总结为在 sort() 不需要加锁。或者，为了避免担心哪个操作是原子的，遵循一个简单的原则：始终围绕共享可变状态的读取和写入加锁。毕竟，在 Python 中获取一个 threading.Lock 是廉价的。

  尽管 GIL 不能免除我们加锁的需要，但它确实意味着没有加细粒度的锁的需要（所谓细粒度是指程序员需要自行加、解锁来保证线程安全，典型代表是 Java , 而 CPthon 中是粗粒度的锁，即语言层面本身维护着一个全局的锁机制,用来保证线程安全）。在线程自由的语言比如 Java，程序员努力在尽可能短的时间内加锁存取共享数据，减轻线程争夺，实现最大并行。然而因为在 Python 中线程无法并行运行，细粒度锁没有任何优势。只要没有线程保持这个锁，比如在睡眠，等待I/O, 或者一些其他失去 GIL 操作，你应该使用尽可能粗粒度的，简单的锁。其他线程无论如何无法并行运行。

  并发可以完成更快

  我敢打赌你真正为的是通过多线程来优化你的程序。通过同时等待许多网络操作，你的任务将更快完成，那么多线程会起到帮助，即使在同一时间只有一个线程可以执行 Python 。这就是并发，线程在这种情况下工作良好。

  线程中代码运行更快

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

  import threading import requests urls = [ . . . ] def worker ( ) :      while True :          try :              url = urls . pop ( )          except IndexError :              break    # Done.          requests . get ( url ) for _ in range ( 10 ) :      t = threading . Thread ( target = worker )      t . start ( )

  正如我们所看到的，在 HTTP上面获取一个URL中，这些线程在等待每个套接字操作时放弃 GIL，所以他们比一个线程更快完成工作。

  Parallelism 并行

  如果想只通过同时运行 Python 代码，而使任务完成更快怎么办？这种方式称为并行，这种情况 GIL 是禁止的。你必须使用多个进程，这种情况比线程更复杂，需要更多的内存，但它可以更好利用多个 CPU。

  这个例子 fork 出 10 个进程，比只有 1 个进程要完成更快，因为进程在多核中并行运行。但是 10 个线程与 1 个线程相比，并不会完成更快，因为在一个时间点只有 1 个线程可以执行 Python：

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

  import os import sys nums = [ 1 for _ in range ( 1000000 ) ] chunk_size = len ( nums ) // 10 readers = [ ] while nums :      chunk , nums = nums [ : chunk_size ] , nums [ chunk_size : ]      reader , writer = os . pipe ( )      if os . fork ( ) :          readers . append ( reader )    # Parent.      else :          subtotal = 0          for i in chunk : # Intentionally slow code.              subtotal += i          print ( 'subtotal %d' % subtotal )          os . write ( writer , str ( subtotal ) . encode ( ) )          sys . exit ( 0 ) # Parent. total = 0 for reader in readers :      subtotal = int ( os . read ( reader , 1000 ) . decode ( ) )      total += subtotal print ( "Total: %d" % total )

  因为每个 fork 的进程有一个单独的 GIL，这个程序可以把工作分派出去，并一次运行多个计算。

  （Jython 和 IronPython 提供单进程的并行，但它们远没有充分实现 CPython 的兼容性。有软件事务内存的 PyPy 有朝一日可以运行更快。如果你对此好奇，试试这些解释器。）