Python的底层
要理解GIL的含义，我们需要从Python的基础讲起。像C++这样的语言是编译型语言，所谓编译型语言，是指程序输入到编译器，编译器再根据语言的语法进行解析，然后翻译成语言独立的中间表示，最终链接成具有高度优化的机器码的可执行程序。编译器之所以可以深层次的对代码进行优化，是因为它可以看到整个程序（或者一大块独立的部分）。这使得它可以对不同的语言指令之间的交互进行推理，从而给出更有效的优化手段。
意外的事实
现在我们来看一下问题的症结所在。要想利用多核系统，Python必须支持多线程运行。作为解释型语言，Python的解释器必须做到既安全又高效。我们都知道多线程编程会遇到的问题。解释器要留意的是避免在不同的线程操作内部共享的数据。同时它还要保证在管理用户线程时保证总是有最大化的计算资源。
很遗憾，没有任何东西被漏掉。由于Python解释器的设计，使用多线程以提高性能应该算是一个困难的任务。在最坏的情况下，它将会降低（有时很明显）你的程序的运行速度。一个计算机科学与技术专业的大学生新手可能会告诉你当多个线程都在竞争一个共享资源时将会发生什么。结果通常不会非常理想。很多情况下多线程都能很好地工作，可能对于解释器的实现和内核开发人员来说，没有关于Python多线程性能的过多抱怨。
移除GIL非常困难，让我们去购物吧！
（译者注：XXX is hard. Let’s go shopping!在英语中类似于中文的咆哮体。其隐含意思为想成功完成某件事情非常困难，我们去直接寻找第三方的产品替代吧。）
不过，“free threading”这个补丁是有启发性意义的，其证明了一个关于Python解释器的基本要点：移除GIL是非常困难的。由于该补丁发布时所处的年代，解释器变得依赖更多的全局状态，这使得想要移除当今的GIL变得更加困难。值得一提的是，也正是因为这个原因，许多人对于尝试移除GIL变得更加有兴趣。困难的问题往往很有趣。
但是这可能有点被误导了。让我们考虑一下：如果我们有了一个神奇的补丁，其移除了GIL，并且没有对单线程的Python代码产生性能上的下降，那么什么事情将会发生？我们将会获得我们一直想要的：一个线程API可能会同时利用所有的处理器。那么现在，我们已经获得了我们希望的，但这确实是一个好事吗？
然而，这并不是一个完美的改变。对于在各种类型的任务上有效利用GIL这个领域里，最活跃的研究者可能就是David Beazley了。除了对Python 3.2之前的GIL研究最深入，他还研究了这个最新的GIL实现，并且发现了很多有趣的程序方案。对于这些程序，即使是新的GIL实现，其表现也相当糟糕。他目前仍然通过一些实际的研究和发布一些实验结果来引领并推进着有关GIL的讨论。
不管某一个人对Python的GIL感觉如何，它仍然是Python语言里最困难的技术挑战。想要理解它的实现需要对操作系统设计、多线程编程、C语言、解释器设计和CPython解释器的实现有着非常彻底的理解。单是这些所需准备的就妨碍了很多开发者去更彻底的研究GIL。虽然如此，并没有迹象表明GIL在不久以后的任何一段时间内会远离我们。目前，它将继续给那些新接触Python，并且与此同时又对解决非常困难的技术问题感兴趣的人带来困惑和惊喜。
以上内容是基于我目前对Python解释器所做出的研究而写。虽然我还希望写一些有关解释器的其它方面内容，但是没有任何一个比全局解释器锁（GIL）更为人所知。虽然我认为这里有些内容是不准确的，但是这些技术上的细节与CPython的很多资源条目是不同的。如果你发现了不准确的内容，请及时告知我，这样我就会尽快对其进行改正。进群：125240963 即可获取数十套PDF哦！