我们已经听说过全局解释器锁（GIL），担心会影响到多线程的性能。尽管Python完全支持多线程编程，但是在解释器的C语言实现中，有一部分并不是线程安全的，因此不能完全支持并发执行。
事实上，解释器被一个称为全局解释器锁的东西保护着，在任意时刻只允许一个Python线程投入执行。GIL带来的最明显的影响就是多线程的python程序无法充分利用多个CPU核心带来的优势（即，一个采用多线程技术的计算密集型应用只能在一个CPU上运行）。
在讨论规避GIL的常用方案之前，需要重点强调的是，GIL只会对CPU密集型的程序产生影响（主要完成计算任务的程序）。如果我们的程序主要是在做I/O操作，比如处理网络连接，那么选择多线程技术常常是一个明智的选择。因为他们大部分时间都花在等待对放发起连接上了。实际上可以创建数以千计的Python线程都没问题。在现代的计算机上运行这么多线程是不会有问题的。
在理解这部分的内容的时候，你可以将存在全局解释器锁的Python解释器看作一个加油站。
I/O密集型任务中，你可以理解为有多辆小轿车驶入了加油站进行加油，虽然不知道哪个先加完，但是会比只有一个加油点的加油站顺序很快。如果是计算密集型的任务呢，就是当这辆车驶入加油站的时候，加油站所有的资源都用来服务这一辆车了，别的车只能等待。
当然上述比喻只是为了大家方便理解两种不同类型任务的区别。
对于CPU密集型的程序，我们需要对问题的本质做些研究，例如，仔细选择底层使用的算法，这可能会比尝试将一个没有优化过的算法用多线程来并行处理所带来的性能提升要多得多。同样的，由于Python是解释型语言，往往只需要简单的将性能关键的代码转移到C语言扩展的模块中就可能得到极大的性能提升。类似NumPy这样的扩展模块对于加速涉及数组数据的特定计算也是非常高效的。最后但同样重要的是，还可以尝试使用其他的解释器实现，比如说使用了JIT编译优化技术的PYPY。
同样值得指出的是，使用多线程技术并不是为了获得性能的提升。一个CPU密集型的程序可能会用多线程来管理图形用户界面、网络连接或者其他类型的服务。在这种情况下GIL实际上会带来更多的问题。因为如果某部分代码持有GIL锁的时间过长，那就会导致其他非CPU密集型的线程都阻塞住。实际上，一个写的很糟糕的C扩展模块会让这个问题更加严重，尽管代码中C实现的部分会比之前运行的快。
说这么多，要规避GIL的限制主要有两种常用的策略。
-
如果完全使用Python来编程，可以使用
multiprocessin模块来创建进程池，把它当作协处理器来使用。看看下面的例子：# 大量的计算任务 (CPU bound) def some_work(args): # ... result = args return result # 线程函数 def some_thread(): while True: # ... args = None r = some_work(args) # ...上面是使用线程去处理这个任务，下面我们可以将代码改为进程池的方式：
pool = None # 大量的计算任务 (CPU bound) def some_work(args): # ... result = args return result # 线程函数 def some_thread(): while True: # ... r = pool.apply(some_work, (args)) # ... if __name__ == "__main__": import multiprocessing pool = multiprocessing.Pool()使用进程池的例子通过一个巧妙的办法避开了GIL的限制。每当有线程要执行CPU密集型任务的时候，就把任务提交到进程池中，然后进程池将任务转交给运行在另一个进程中的python解释器。当线程等待结果的时候就会释放GIL。此外，由于计算是在另一个单独的解释器中进行的，这就不再受到GIL的限制了，在多核系统上，将会发现采用这种技术能够轻易利用到所有的CPU核心。
第二种方式是把重点放在C语言的扩展编程上。主要思想就是将计算密集的任务转移到C语言中，使其独立于Python，在C代码中释放GIL，这里由于我也不会C，就不做示例了。
在我们面对多线程程序性能问题的时候，不能去抱怨GIL是所有问题的根源。但是，这么做只是一种短视和幼稚的行为。举个例子，在多线程网络程序中出现神秘的“僵死”现象，这种现象可能是别的原因造成的，和GIL没有一点关系。所以要先认真研究自己的代码，判断GIL是否才是问题的关键。CPU密集型的处理才是需要考虑GIL，I/O密集的处理则不必要考虑。
