超过十年以上，没有比解释器全局锁（GIL）让Python新手和专家更有挫折感或者更有好奇心。 未解决的问题随处都是问题。难度大、耗时多肯定是其中一个问题。仅仅是尝试解决这个问题就会让人惊讶。之前是整个社区的尝试，但现在只是外围的开发人员在努力。对于新手，去尝试解决这样的问题，主要是因为问题难度足够大，解决之后可以获得相当的荣誉。计算机科学中未解决的 P = NP 就是这样的问题。对此如果能给出多项式时间复杂度的答案，那简直就可以改变世界了。Python最困难的问题比证明P = NP要容易一些，不过迄今仍然没有一个满意的解决，要知道，这个问题的实用的解决方案同样能起着变革性的作用。正因为如此，很容易看到Python社区会有如此多的人关注于这样的问题: "对于解释器全局锁能做什么?" Python的底层要理解GIL的含义，我们需要从Python的基础讲起。像C++这样的语言是编译型语言，所谓编译型语言，是指程序输入到编译器，编译器再根据语言的语法进行解析，然后翻译成语言独立的中间表示，最终链接成具有高度优化的机器码的可执行程序。编译器之所以可以深层次的对代码进行优化，是因为它可以看到整个程序（或者一大块独立的部分）。这使得它可以对不同的语言指令之间的交互进行推理，从而给出更有效的优化手段。 与此相反，Python是解释型语言。程序被输入到解释器来运行。解释器在程序执行之前对其并不了解；它所知道的只是Python的规则，以及在执行过程中怎样去动态的应用这些规则。它也有一些优化，但是这基本上只是另一个级别的优化。由于解释器没法很好的对程序进行推导，Python的大部分优化其实是解释器自身的优化。更快的解释器自然意味着程序的运行也能“免费”的更快。也就是说，解释器优化后，Python程序不用做修改就可以享受优化后的好处。 这一点很重要，让我们再强调一下。如果其他条件不变，Python程序的执行速度直接与解释器的“速度”相关。不管你怎样优化自己的程序，你的程序的执行速度还是依赖于解释器执行你的程序的效率。这就很明显的解释了为什么我们需要对优化Python解释器做这么多的工作了。对于Python程序员来说，这恐怕是与免费午餐最接近的了。 免费午餐结束了还是没有结束？摩尔定律给出了硬件速度会按照确定的时间周期增长，与此同时，整整一代程序员学会了如何编码。如果一个人写了比较慢的代码，最简单的结果通常是更快的处理器去等待代码的执行。显然，摩尔定律仍然是正确的，并且还会在很长一段时间生效，不过它提及的方式有了根本的变化。并非是时钟频率增长到一个高不可攀的速度，而是通过多核来利用晶体管密度提高带来的好处。在新处理器上运行的程序要想充分利用其性能，必须按照并发方式进行重写。 大部分开发者听到“并发”通常会立刻想到多线程的程序。目前来说，多线程执行还是利用多核系统最常用的方式。尽管多线程编程大大好于“顺序”编程，不过即便是仔细的程序员也没法在代码中将并发性做到最好。编程语言在这方面应该做的更好，大部分应用广泛的现代编程语言都会支持多线程编程。 意外的事实现在我们来看一下问题的症结所在。要想利用多核系统，Python必须支持多线程运行。作为解释型语言，Python的解释器必须做到既安全又高效。我们都知道多线程编程会遇到的问题。解释器要留意的是避免在不同的线程操作内部共享的数据。同时它还要保证在管理用户线程时保证总是有最大化的计算资源。 那么，不同线程同时访问时，数据的保护机制是怎样的呢？答案是解释器全局锁。从名字上看能告诉我们很多东西，很显然，这是一个加在解释器上的全局（从解释器的角度看）锁（从互斥或者类似角度看）。这种方式当然很安全，但是它有一层隐含的意思（Python初学者需要了解这个）：对于任何Python程序，不管有多少的处理器，任何时候都总是只有一个线程在执行。 许多人都是偶然发现这个事实的。网上的很多讨论组和留言板都充斥着来自Python初学者和专家的类似这样的问题——”为什么我全新的多线程Python程序运行得比其只有一个线程的时候还要慢？“许多人在问这个问题时还是非常犯晕的，因为显然一个具有两个线程的程序要比其只有一个线程时要快（假设该程序确实是可并行的）。事实上，这个问题被问得如此频繁以至于Python的专家们精心制作了一个标准答案：”不要使用多线程，请使用多进程。“但这个答案比那个问题更加让人困惑。难道我不能在Python中使用多线程？在Python这样流行的一个语言中使用多线程究竟是有多糟糕，连专家都建议不要使用。难道我真的漏掉了一些东西？ 很遗憾，没有任何东西被漏掉。由于Python解释器的设计，使用多线程以提高性能应该算是一个困难的任务。在最坏的情况下，它将会降低（有时很明显）你的程序的运行速度。一个计算机科学与技术专业的大学生新手可能会告诉你当多个线程都在竞争一个共享资源时将会发生什么。结果通常不会非常理想。很多情况下多线程都能很好地工作，可能对于解释器的实现和内核开发人员来说，没有关于Python多线程性能的过多抱怨。 现在该怎么办？惊慌？那么，这又能怎样？问题解决了吗？难道我们作为Python开发人员就意味着要放弃使用多线程来探索并行的想法了？为什么无论怎样，GIL需要保证只有一个线程在某一时刻处于运行中？难道不可以添加细粒度的锁来阻止多个独立对象的同时访问？并且为什么之前没有人去尝试过类似的事情？ 这些实用的问题有着十分有趣的回答。GIL对诸如当前线程状态和为垃圾回收而用的堆分配对象这样的东西的访问提供着保护。然而，这对Python语言来说没什么特殊的，它需要使用一个GIL。这是该实现的一种典型产物。现在也有其它的Python解释器（和编译器）并不使用GIL。虽然，对于CPython来说，自其出现以来已经有很多不使用GIL的解释器。 那么为什么不抛弃GIL呢？许多人也许不知道，在1999年，针对Python 1.5，一个经常被提到但却不怎么理解的“free threading”补丁已经尝试实现了这个想法，该补丁来自Greg Stein。在这个补丁中，GIL被完全的移除，且用细粒度的锁来代替。然而，GIL的移除给单线程程序的执行速度带来了一定的代价。当用单线程执行时，速度大约降低了40%。使用两个线程展示出了在速度上的提高，但除了这个提高，这个收益并没有随着核数的增加而线性增长。由于执行速度的降低，这一补丁被拒绝了，并且几乎被人遗忘。 |
