Python 最难的问题
高出十年以上，没有比表明器全局锁（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这样风行的一个语言中利用多线程毕竟是有多糟糕，连专家都发起不要利用。莫非我真的遗漏了一些对象？
#p#分页标题#e#
很遗憾，没有任何对象被遗漏。由于Python表明器的设计，利用多线程以提高机能应该算是一个坚苦的任务。在最坏的环境下，它将会低落（有时很明明）你的措施的运行速度。一个计较机科学与技能专业的大学生新手大概会汇报你当多个线程都在竞争一个共享资源时将会产生什么。功效凡是不会很是抱负。许多环境下多线程都能很好地事情，大概对付表明器的实现和内核开拓人员来说，没有关于Python多线程机能的过多诉苦。
此刻该怎么办？惶恐？
那么，这又能奈何？问题办理了吗？莫非我们作为Python开拓人员就意味着要放弃利用多线程来摸索并行的想法了？为什么无论奈何，GIL需要担保只有一个线程在某一时刻处于运行中？莫非不行以添加细粒度的锁来阻止多个独立工具的同时会见？而且为什么之前没有人去实验过雷同的工作？
这些实用的问题有着十分有趣的答复。GIL对诸如当前线程状态和为垃圾接纳而用的堆分派工具这样的对象的会见提供着掩护。然而，这对Python语言来说没什么非凡的，它需要利用一个GIL。这是该实现的一种典范产品。此刻也有其它的Python表明器（和编译器）并不利用GIL。固然，对付CPython来说，自其呈现以来已经有许多不利用GIL的表明器。
那么为什么不丢弃GIL呢？很多人也许不知道，在1999年，针对Python 1.5，一个常常被提到但却不怎么领略的“free threading”补丁已经实验实现了这个想法，该补丁来自Greg Stein。在这个补丁中，GIL被完全的移除，且用细粒度的锁来取代。然而，GIL的移除给单线程措施的执行速度带来了必然的价钱。当用单线程执行时，速度约莫低落了40%。利用两个线程展示出了在速度上的提高，但除了这个提高，这个收益并没有跟着核数的增加而线性增长。由于执行速度的低落，这一补丁被拒绝了，而且险些被人遗忘。
移除GIL很是坚苦，让我们去购物吧！
不外，“free threading”这个补丁是有开导性意义的，其证明白一个关于Python表明器的根基要点：移除GIL长短常坚苦的。由于该补丁宣布时所处的年月，表明器变得依赖更多的全局状态，这使得想要移除当今的GIL变得越发坚苦。值得一提的是，也正是因为这个原因，很多人对付实验移除GIL变得越发有乐趣。坚苦的问题往往很有趣。
可是这大概有点被误导了。让我们思量一下：假如我们有了一个神奇的补丁，其移除了GIL，而且没有对单线程的Python代码发生机能上的下降，那么什么工作将会产生？我们将会得到我们一直想要的：一个线程API大概会同时操作所有的处理惩罚器。那么此刻，我们已经得到了我们但愿的，但这确实是一个功德吗？
基于线程的编程毫无疑问是坚苦的。每当某小我私家以为他相识关于线程是如何事情的一切的时候，老是会悄无声息的呈现一些新的问题。因为在这方面想要获得正确公道的一致性真的是太难了，因此有一些很是知名的语言设计者和研究者已经总结得出了一些线程模子。就像某个写过多线程应用的人可以汇报你的一样，不管是多线程应用的开拓照旧调试城市比单线程的应用难上数倍。措施员凡是所具有的顺序执行的思维模恰恰就是与并行执行模式不相匹配。GIL的呈现无意中辅佐了开拓者免于陷入逆境。在利用多线程时仍然需要同步原语的环境下，GIL事实上辅佐我们保持差异线程之间的数据一致性问题。
那么此刻看起来接头Python最可贵问题是有点问错了问题。我们有很是好的来由来说明为什么Python专家推荐我们利用多历程取代多线程，而不是去试图埋没Python线程实现的不敷。更进一步，我们勉励开拓者利用更安详更直接的方法实现并发模子，同时保存利用多线程举办开拓除非你觉的真的很是须要的话。对付大大都人来说什么是最好的并行编程模子大概并不是十分清楚。可是今朝我们清楚的是多线程的方法大概并不是最好的。
至于GIL，不要认为它在那的存在就是静态的和未经阐明过的。Antoine Pitrou 在Python 3.2中实现了一个新的GIL，而且带着一些努力的功效。这是自1992年以来，GIL的一次最主要改变。这个改变很是庞大，很难在这里表明清楚，可是从一个更高条理的角度来说，旧的GIL通过对Python指令举办计数来确定何时放弃GIL。这样做的功效就是，单条Python指令将会包括大量的事情，即它们并没有被1:1的翻译成呆板指令。在新的GIL实现中，用一个牢靠的超时时间来指示当前的线程以放弃这个锁。在当前线程保持这个锁，且当第二个线程请求这个锁的时候，当前线程就会在5ms后被强制释放掉这个锁（这就是说，当前线程每5ms就要查抄其是否需要释放这个锁）。当任务是可行的时候，这会使得线程间的切换越发可预测。
#p#分页标题#e#
然而，这并不是一个完美的改变。对付在各类范例的任务上有效操作GIL这个规模里，最活泼的研究者大概就是David Beazley了。除了对Python 3.2之前的GIL研究最深入，他还研究了这个最新的GIL实现，而且发明白许多有趣的措施方案。对付这些措施，纵然是新的GIL实现，其表示也相当糟糕。他今朝仍然通过一些实际的研究和宣布一些尝试功效来引领并推进着有关GIL的接头。
不管某一小我私家对Python的GIL感受如何，它仍然是Python语言里最坚苦的技能挑战。想要领略它的实现需要对操纵系统设计、多线程编程、C语言、表明器设计和CPython表明器的实现有着很是彻底的领略。单是这些所需筹备的就故障了许多开拓者去更彻底的研究GIL。固然如此，并没有迹象表白GIL在不久今后的任何一段时间内会远离我们。今朝，它将继承给那些新打仗Python，而且与此同时又对办理很是坚苦的技能问题感乐趣的人带来狐疑和惊喜。
以上内容是基于我今朝对Python表明器所做出的研究而写。固然我还但愿写一些有关表明器的其它方面内容，可是没有任何一个比全局表明器锁（GIL）更为人所知。固然我认为这里有些内容是禁绝确的，可是这些技能上的细节与CPython的许多资源条目是差异的。
