(点击上方公众号，可快速关注)英文：nginx译者：伯乐在线 - 乔永琪 译文：/88766/点击“阅读原文”，查看原文网页版NGINX 在网络应用中表现超群，在于其独特的设计。许多网络或应用服务器大都是基于线程或者进程的简单框架，NGINX突出的地方就在于其成熟的事件驱动框架，它能应对现代硬件上成千上万的并发连接。NGINX 内部信息图从进程框架的顶层开始，向下逐步揭示NGINX如何处理单个进程中的多个连接，并进一步探讨其工作机制。场景设置 — NGINX进程模型为了更好地理解这种设计模式，我们需要明白NGINX是如何运行的。NGINX拥有一个主线程，用来处理配置文件的读取、端口的绑定等特权操作，以及一组工作进程、辅助进程。# service nginx restart* Restarting nginx# ps -ef --forest | grep nginxroot
00:00:00 nginx: master process /usr/sbin/nginx
-c /etc/nginx/nginx.confnginx
_ nginx: worker processnginx
_ nginx: worker processnginx
_ nginx: worker processnginx
_ nginx: worker processnginx
_ nginx: cache manager processnginx
_ nginx: cache loader process在这个四核服务器中，主线程创建了四个工作进程和一组缓存辅助进程（cache helper processes），后者用来管理硬盘缓存。为什么框架如此重要？任何Unix应用的基础是线程或者进程-对于Linux操作系统，线程和进程几乎相同；最大的区别在于线程间是内存共享的。一个线程或者进程是一套指令集(self-contained set of instructions )，操作系统调度这些指令在单个CPU内核上运行。许多复杂应用并行地运行在多个线程或者进程，原因有二：应用可以同时使用计算机的多个CPU核线程和进程易于并行操作，比如同时处理多个连接进程和线程消耗资源，比如对内存以及其它操作系统资源的占用、内核切换(wapped on and off the cores)(本操作叫做一次上下文切换(context switch))。如今的服务器需要同时处理成千个小的、活跃线程或者进程，一旦内存耗尽、或者过高的读写负载，这些都会导致大规模的上下文切换，性能会严重退化。通常的设计思路是，网络应用为每个连接分派一个线程或者进程。这类框架简单易于实现，不过在同时应对成千上万个连接时难以扩展。NGINX是如何运作的呢？NGINX利用一个预测进程模型调度可用的硬件资源：主进程处理配置文件读取、端口绑定等特权操作，以及创建一小组子进程(接下来三种类型的进程)启动时缓存加载器进程加载硬盘中缓存到内存中，接着退出。对它的调度是保守的，所以资源开销较低缓存管理进程定时运行，清理来自硬盘缓存的实体到指定的大小工作进程负责所有的工作，处理网络连接、硬盘读写操作、以及上游服务器通信NGINX推荐的配置是，一个工作进程对应一个CPU内核，确保硬件资源的有效利用，在配置文件中设置worker_processes auto：worker_一旦NGINX服务起来，仅有工作进程在忙，每个工作进程采用非阻塞地方式处理多个连接，降低上下文切换的次数。每个工作进程都是单线程且独立运行，负责获取新连接并进行处理。进程之间通过共享内存进行通信，诸如缓存数据，会话持续化数据(ession persistence data),以及其他共享资源。NGINX1.7.11及以后的版本，有一个可选的线程池，工作进程将阻塞操作丢给它们。更多细节，参看《Nginx 引入线程池，提升 9 倍性能》。对于NGINX Plus用户，这些新特性会在今年的发布版7中出现。NGINX内部工作进程每个NGINX工作进程由配置文件对其进行初始化，主进程为其提供一组监听socket。工作进程起始于socket监听事件(accept_mutex 和 kernel socket sharding)，事件由新的连接进行初始化，接着这些连接被派发给某个状态机—HTTP状态机是其中最常用的一种，不过NGINX也实现了基于流的状态机、基于通信协议的状态机(SMTP, IMAP, and POP3)。状态机是一组重要的指令集，它会告诉NGINX怎样处理每个请求。许多网络服务器拥有NGINX的状态机一样的功能—区别就在于它们的实现不同。调度状态机状态机就像下象棋，单个HTTP事务如同一盘棋。棋盘的一端是网络服务器—就像大师级棋手非常快地做出决定，另一端为远程客户端—网络浏览器通过相对较慢的网络访问某个站点或应用。不过游戏规则可能非常复杂，比如网络服务可能需要和第三方、或者某个认证服务器通信，甚至服务器中的第三方模块来扩展游戏规则。阻塞状态机回到前面的描述，进程或者线程作为一套指令集，操作系统调度其运行在某个CPU内核上。大多数网络服务器和网络应用按照一个进程处理一个连接，或者一个线程处理一个连接的模型来玩象棋游戏；每个包含指令的进程或者线程参与游戏的整个过程。在这期间，运行在服务器上进程大多数时间被阻塞掉了，即等待某个客户端去完成下一步棋。网络服务器进程监听socket上的新连接，此游戏新连接由客户端发起。一旦获得新游戏，进入游戏环节，每一次移动都需等待客户端响应，进程就被阻塞了。一旦游戏结束，网络服务器进程就会查看客户端是否想再来一局(对应某个存活的连接)。一旦连接关闭(客户端离开或者超时)，网络服务器进程就会返回监听新的游戏。记住每一个活跃的HTTP连接即每一局象棋游戏，需要象棋大师一般的特定进程或者线程参与其中。这个架构简单易于扩展第三方模型即新的规则。然而，这里存在一个极不平衡的逻辑，对于相关轻量级的HTTP连接，由单个文件描述符和少量的内存表示，此连接会映射到某个线程或进程上，而线程或者进程是一个重量级的操作系统对象。尽管编程时很方便，但浪费却是巨大的。NGINX是一个真正的大师或许你听说过同时展示游戏，一个象棋大师同时对阵十二个棋手。NGINX工作进程也是这么玩”象棋”的，每个工作进程-一个CPU内核上的工作者-即是一个可以同时应对成千上万游戏的大师。工作进程从已连接并开始监听的套接字(socket)那里获取事件；一旦socket接收到事件，工作进程会立即处理此事件：socket上的某个监听事件即客户端开启一个新的象棋游戏，而工作进程创建一个新的socket连接。socket连接上的某个事件即客户端走了一步棋，工作线程做出了恰当地响应。工作进程从来不会阻塞在网络传输上等待它的对手（客户端）回复应答。每走完一步棋后，工作进程会迅速处理其它等待的象棋游戏，或者欢迎新的游戏玩家进入。为何比阻塞、多进程框架快呢？NGINX良好的扩展性在于其支持一个工作线程处理成千上万个连接。每个新连接创建文件描述符，仅消耗工作进程很少一部分额外内存，额外的开销很小。进程能够一直绑定CPU(pinned to CPUs)，这样上下文切换相对没有那么频繁，只有没工作时才会发生。译者注：cpu绑定是指绑定一个或者多个进程到一个或者多个处理器上.使用阻塞方式，即一个连接对应一个进程，每个连接需要大量的额外资源以及开销，上下文切换非常频繁。（更多细节，参看Andrew Alexeev关于NGINX架构的文章。该作者是NGINX联合创始人、公司开发部副总裁。）只要恰当的系统调优，NGINX每个工作进程可以处理成千上万个并发HTTP连接，毫无差错地应对网络高峰，即同时可以玩更多的象棋游戏。更新配置文件升级NGINX进程框架拥有少量工作进程，有利配置文件甚至二进制文件更新。更新NGINX配置是一个简单、轻量级的可靠操作。即只要运行nginx -s reload命令，就会检查磁盘上的配置文件，并给主进程发送一个SIGHUB信号。一旦主进程接受到一个SIGHUB,它会做两件事：重载配置文件、创建一组新的工作进程，新创建的工作进程立即接受连接、处理网络通信( 采用新的配置环境)。通知旧的工作进程优雅地推出，这些工作进程停止接受新连接。一旦当前处理的HTTP请求结束，工作进程会关闭连接。一旦所有连接关闭，工作进程就会退出。重载进程会引起一个小的CPU和内存高峰，不过从活跃连接处加载的资源相比，开销微乎其微。每一秒可以多次重载配置文件。产生诸多等待连接关闭的NGINX工作进程一般很少出问题，不过就算是有问题也可以迅速解决。NGINX二进文件升级获得极佳的高可用性-你可以在线升级文件，而且不会丢失任何连接、服务也不会停机或中断。译者注： on the fly 程序在运行时，工作就可以完成。二进制文件升级进程方式类似优雅的配置文件重载；新的NGINX主进程和原有的主进程并行，分享监听socket。两个进程都处于活跃状态，处理它们各自的网络通信。你可以通知原有的主进程以及它的工作进程优雅地退出。进程详细描述参见NGINX控制最后结语NGINX内部信息图展示了NGINX的高标准功能全景图，简单解释的背后是十多年来不断创新优化，得益于此NGINX被广泛应用于各种硬件平台，并且取得了最优异的性能表现。即便是在现代，网络应用需要对安全和可靠性作出维护，NGINX也表现不凡。倘若你想了解更多关于NGINX优化的知识，下面是一些很不错的资料：NGINX安装、性能调优NGINX性能调优《Nginx 引入线程池，提升 9 倍性能》NGINX——开源应用框架NGINX socket拆分（Socket Sharding）发布版1.9.1请点击最左下方的“阅读原文”，看上述的资料【7月热文精选】（点标题就可以查看）《程序员的困境》《互联网协议入门》评论超多，压倒性拍好的文章《如何摧毁程序员的效率？》《单身数学家如何通过数据挖掘找真爱》《我从腾讯那“偷了”3000万QQ用户数据，出了份很有趣的独家报告！》
（其他爬虫文章：Scrapy 轻松定制网络爬虫、Python爬虫入门、如何入门 Python 爬虫？）《漫画：7 种编程语言的学习曲线》《有哪些实用的 IT 技能，可以在一天内学会？》《机器学习常见算法分类汇总》《数据专家必知必会的 7 款 Python 工具》《YouTube上最火的十个大数据视频》《如何用 PythonP写一个拼写检查器》作者是谷歌大牛 Peter Norvig《我希望看到的Python，Flask作者如是说》《Python 中的进程、线程、协程、同步、异步、回调》《Python并行任务技巧》《一起写一个 Web 服务器（1）》超赞的系列文章《一起写一个 Web 服务器（2）》超赞的系列文章《一起写一个 Web 服务器（3）》 第三篇下半部分《Spark入门（Python版）》《Python的 GIL 是什么鬼，多线程性能究竟如何》《以 Python 为实例，介绍贝叶斯理论》《自己动手写贝叶斯分类器给图书分类》Python开发者微信号：PythonCoder可能是东半球最好的 Python 微信号--------------------------------------商务合作QQ：招聘和猎头服务QQ：投稿网址：
看过本文的人还看过
人气：51219 更新：
人气：36791 更新：
人气：35633 更新：
人气：27467 更新：
程序员的那些事的更多文章
大家在看 ^+^
推荐阅读 ^o^
多维时代，还在用传统思想管理企业？微软就是这么落后的！
什么！白巧克力不是巧克力？不可能，我不信！
初创企业挖不到高端人才？它可以帮你「租」到BAT的人才
就是这些东西，让姑娘们每月“那几天”里心烦气躁想打人！
猜你喜欢 ^_^
24小时热门文章
微信扫一扫
分享到朋友圈o &nbsp,&nbsp
前言：博主在刚接触Python的时候时常听到GIL这个词，并且发现这个词经常和Python无法高效的实现多线程划上等号。本着不光要知其然，还要知其所以然的研究态度，博主搜集了各方面的资料，花了一周内几个小时的闲暇时间深入理解了下GIL，并归纳成此文，也希望读者能通过次本文更好且客观的理解GIL
48 小时热门
关于伯乐头条
伯乐头条是目前 IT 互联网行业中，最热门的头条之一。专注于IT互联网，分享和发现有价值的内容与观点。
新浪微博：
推荐微信号
（加好友请注明来意）
- 好的话题、有启发的回复、值得信赖的圈子
- 分享和发现有价值的内容与观点
- 为IT单身男女服务的征婚传播平台
- 优秀的工具资源导航
- 翻译传播优秀的外文文章
- 国内外的精选博客文章
- UI,网页，交互和用户体验
- 专注iOS技术分享
- 专注Android技术分享
- JavaScript, HTML5, CSS
- 专注Java技术分享
- 专注Python技术分享
& 2016 伯乐在线Python的GIL是什么鬼，多线程性能究竟如何
文章欢迎转载，但转载时请保留本段文字，并置于文章的顶部
作者：卢钧轶(cenalulu)
本文原文地址：
前言：博主在刚接触Python的时候时常听到GIL这个词，并且发现这个词经常和Python无法高效的实现多线程划上等号。本着不光要知其然，还要知其所以然的研究态度，博主搜集了各方面的资料，花了一周内几个小时的闲暇时间深入理解了下GIL，并归纳成此文，也希望读者能通过次本文更好且客观的理解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厂商在核心频率上的比赛已经被多核所取代。为了更有效的利用多核处理器的性能，就出现了多线程的编程方式，而随之带来的就是线程间数据一致性和状态同步的困难。，为了有效解决多份缓存之间的数据同步时各厂商花费了不少心思，也不可避免的带来了一定的性能损失。
Python当然也逃不开，为了利用多核，Python开始支持多线程。而解决多线程之间数据完整性和状态同步的最简单方法自然就是加锁。 于是有了GIL这把超级大锁，而当越来越多的代码库开发者接受了这种设定后，他们开始大量依赖这种特性（即默认python内部对象是thread-safe的，无需在实现时考虑额外的内存锁和同步操作）。
慢慢的这种实现方式被发现是蛋疼且低效的。但当大家试图去拆分和去除GIL的时候，发现大量库代码开发者已经重度依赖GIL而非常难以去除了。有多难？做个类比，像MySQL这样的“小项目”为了把Buffer Pool Mutex这把大锁拆分成各个小锁也花了从5.5到5.6再到5.7多个大版为期近5年的时间，本且仍在继续。MySQL这个背后有公司支持且有固定开发团队的产品走的如此艰难，那又更何况Python这样核心开发和代码贡献者高度社区化的团队呢？
所以简单的说GIL的存在更多的是历史原因。如果推到重来，多线程的问题依然还是要面对，但是至少会比目前GIL这种方式会更优雅。
从上文的介绍和官方的定义来看，GIL无疑就是一把全局排他锁。毫无疑问全局锁的存在会对多线程的效率有不小影响。甚至就几乎等于Python是个单线程的程序。
那么读者就会说了，全局锁只要释放的勤快效率也不会差啊。只要在进行耗时的IO操作的时候，能释放GIL，这样也还是可以提升运行效率的嘛。或者说再差也不会比单线程的效率差吧。理论上是这样，而实际上呢？Python比你想的更糟。
下面我们就对比下Python在多线程和单线程下得效率对比。测试方法很简单，一个循环1亿次的计数器函数。一个通过单线程执行两次，一个多线程执行。最后比较执行总时间。测试环境为双核的Mac pro。注：为了减少线程库本身性能损耗对测试结果带来的影响，这里单线程的代码同样使用了线程。只是顺序的执行两次，模拟单线程。
顺序执行的单线程(single_thread.py)
Python的GIL是什么鬼，多线程性能究竟如何
文章欢迎转载，但转载时请保留本段文字，并置于文章的顶部
作者：卢钧轶(cenalulu)
本文原文地址：http://cenalulu.github.io/python/gil-in-python/
前言：博主在刚接触Python的时候时常听到GIL这个词，并且发现这个词经常和Python无法高效的实现多线程划上等号。本着不光要知其然，还要知其所以然的研究态度，博主搜集了各方面的资料，花了一周内几个小时的闲暇时间深入理解了下GIL，并归纳成此文，也希望读者能通过次本文更好且客观的理解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无疑就是一把全局排他锁。毫无疑问全局锁的存在会对多线程的效率有不小影响。甚至就几乎等于Python是个单线程的程序。
那么读者就会说了，全局锁只要释放的勤快效率也不会差啊。只要在进行耗时的IO操作的时候，能释放GIL，这样也还是可以提升运行效率的嘛。或者说再差也不会比单线程的效率差吧。理论上是这样，而实际上呢？Python比你想的更糟。
下面我们就对比下Python在多线程和单线程下得效率对比。测试方法很简单，一个循环1亿次的计数器函数。一个通过单线程执行两次，一个多线程执行。最后比较执行总时间。测试环境为双核的Mac pro。注：为了减少线程库本身性能损耗对测试结果带来的影响，这里单线程的代码同样使用了线程。只是顺序的执行两次，模拟单线程。
顺序执行的单线程(single_thread.py)
#! /usr/bin/python
from threading import Thread
import time
def my_counter():
for _ in range():
return True
def main():
thread_array = {}
start_time = time.time()
for tid in range(2):
t = Thread(target=my_counter)
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__':
同时执行的两个并发线程(multi_thread.py)
#! /usr/bin/python
from threading import Thread
import time
def my_counter():
for _ in range():
return True
def main():
thread_array = {}
start_time = time.time()
for tid in range(2):
t = Thread(target=my_counter)
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__':
下图就是测试结果
可以看到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对于多线程带来的性能影响，这里直接借用的一张测试结果图（见下图）。图中表示的是两个线程在双核CPU上得执行情况。两个线程均为CPU密集型运算线程。绿色部分表示该线程在运行，且在执行有用的计算，红色部分为线程被调度唤醒，但是无法获取GIL导致无法进行有效运算等待的时间。
由图可见，GIL的存在导致多线程无法很好的立即多核CPU的并发处理能力。
那么Python的IO密集型线程能否从多线程中受益呢？我们来看下面这张测试结果。颜色代表的含义和上图一致。白色部分表示IO线程处于等待。可见，当IO线程收到数据包引起终端切换后，仍然由于一个CPU密集型线程的存在，导致无法获取GIL锁，从而进行无尽的循环等待。
简单的总结下就是：Python的多线程在多核CPU上，只对于IO密集型计算产生正面效果；而当有至少有一个CPU密集型线程存在，那么多线程效率会由于GIL而大幅下降。
如何避免受到GIL的影响
说了那么多，如果不说解决方案就仅仅是个科普帖，然并卵。GIL这么烂，有没有办法绕过呢？我们来看看有哪些现成的方案。
用multiprocess替代Thread
multiprocess库的出现很大程度上是为了弥补thread库因为GIL而低效的缺陷。它完整的复制了一套thread所提供的接口方便迁移。唯一的不同就是它使用了多进程而不是多线程。每个进程有自己的独立的GIL，因此也不会出现进程之间的GIL争抢。
当然multiprocess也不是万能良药。它的引入会增加程序实现时线程间数据通讯和同步的困难。就拿计数器来举例子，如果我们要多个线程累加同一个变量，对于thread来说，申明一个global变量，用thread.Lock的context包裹住三行就搞定了。而 multiprocess由于进程之间无法看到对方的数据，只能通过在主线程申明一个Queue，put再get或者用share memory的方法。这个额外的实现成本使得本来就非常痛苦的多线程程序编码，变得更加痛苦了。具体难点在哪有兴趣的读者可以扩展阅读
用其他解析器
之前也提到了既然GIL只是CPython的产物，那么其他解析器是不是更好呢？没错，像JPython和IronPython这样的解析器由于实现语言的特性，他们不需要GIL的帮助。然而由于用了Java/C#用于解析器实现，他们也失去了利用社区众多C语言模块有用特性的机会。所以这些解析器也因此一直都比较小众。毕竟功能和性能大家在初期都会选择前者，Done is better than perfect。
所以没救了么？
当然Python社区也在非常努力的不断改进GIL，甚至是尝试去除GIL。并在各个小版本中有了不少的进步。有兴趣的读者可以扩展阅读
另一个改进
- 将切换颗粒度从基于opcode计数改成基于时间片计数
- 避免最近一次释放GIL锁的线程再次被立即调度
- 新增线程优先级功能（高优先级线程可以迫使其他线程释放所持有的GIL锁）
Python GIL其实是功能和性能之间权衡后的产物，它尤其存在的合理性，也有较难改变的客观因素。从本分的分析中，我们可以做以下一些简单的总结：
- 因为GIL的存在，只有IO Bound场景下得多线程会得到较好的性能
- 如果对并行计算性能较高的程序可以考虑把核心部分也成C模块，或者索性用其他语言实现
- GIL在较长一段时间内将会继续存在，但是会不断对其进行改进
成都思乐科技有限公司
专注成都网站建设多年的网络公司
QQ: 9024570
Add: 武候区洗面桥30号交投大厦B幢13楼D号
请关注我们，扫一扫