写点什么

Python 的 GIL

用户头像
yunson
关注
发布于: 2021 年 01 月 05 日
Python的GIL

引言

原文链接:https://yunsonbai.top/2020/08/27/GIL/

聊一个老生长谈的问题: Python 的 GIL。

结合日常工作的总结和前人的经验,聊一聊我自己对此 GIL 的理解。

希望本文对 Python 的初学者有一些帮助。

到底什么是 GIL?

GIL 全称: Global Interpreter Lock。注意这里有个 Interpreter(Cython、Jython),说白了这把锁其实是加在解释器上的,这把锁只允许一个 Python 线程获得解释器控制权,简单说就是某一时刻只能有一个线程运行(单线程)。对 GIL 褒贬不一,对于单线程程序来讲其实没有什么影响,但是对于多线程程序,有的时候就会成为影响性能的瓶颈点。对 GIL 的形容,你可能在网上还会找到类似臭名昭著的形容词,其实我觉着万事都不能这么绝对,它存在既有存在的原因和用处。

GIL 对 Python 到底有什么帮助?

我们知道 Python 使用了计数的方式来管理对象的回收,进而管理内存。简单来说就是每个对象都会有个计数,当这个计数变为 0 的时候,回收机制就会回收这个对象,释放对象占用的内存空间。看一个简单的例子:

>>> import sys>>> a = 4902384823>>> b = a>>> sys.getrefcount(a)3
复制代码

通过 getrefcount 可以拿到某个对象的计数,插个小插曲,为什么我这里用这么大的数(4902384823), 为什么不用 1?细心的读者可以去网上找一下,Python 的小整数池,你就会明白。


我们继续聊 GIL,想一下这个场景,如果解释器允许多线程并发执行,都要对这个 a 做操作,会有什么样的结果产生呢?线程 1 要把 a 赋值给 c,线程 2 呢,要把 a 赋值成别的值(原来的 a 对象技术就会减小 1),线程 3 也要把 a 赋值成别的值,线程 4 更狠,直接释放了 a,线程 5....,试想一下,当出现这么多的进程要操作同一个对象的时候,情况就复杂了,是不是会导致程序的逻辑异常甚至直接崩溃呢?GIL 就派上了用场,在某个时刻只允许一个线程运行,很完美的解决了上述问题。不排除还有其他的垃圾回收机制,比如 golang 就十分复杂,不得不引入 STW 机制,来进行垃圾回收,要知道在 Python 诞生之际,操做系统还没有线程的概念。


有人可能会问,那不能给对象加把锁么?这样不就可以同时运行多个线程了么?那就会需要数量庞大的锁,维护这些锁开销很大,另外很可能会触发死锁(多锁情况下的陷阱)情况。而 GIL 只需要管理一个锁,能提高单个线程的性能。


由于 Python 简单易用,目前越来越多的人开始学习和使用 Python,这其中 GIL 起着很大的作用。C 库的许多扩展,有的需要在 Python 中实现其功能,而 GIL 则提供了线程安全的内存管理,可以防止不一致的更改,GIL 对 Python 的快速发展起着不可估量的作用。


另外 GIL 只需要管理着一个锁,将变得很简单,这在早期的 Python 设计开发中,GIL 是个结合实际情况而做出合适的选择。

有这个 GIL 我该怎么提升我的代码性能呢?

要想提高代码性能,首先得先弄清楚你得代码是面向什么场景的。只有结合了实际,才能选出适合的方案来。咱们抛开业务讲,无非就是两种情况,CPU 计算瓶颈约束和 I/O 瓶颈约束。

CPU 密集计算型

你的程序是极其耗 CPU 的,最简单的,就是下边这个程序,他可能会跑满你某个核心

a = 0while 1:    a += 1
复制代码

你的 CPU 会不停的工作,甚至累趴下,这会程序已经没有优化的余地了,别说 Python,就是任何语言也得望而止步,就好比是你开的车,你已经把挡挂到最高,把油门踩到底了,你还怎么加速,只有这个速度了。比较典型的还有图片计算、视频计算等等也都是耗 CPU 的计算。

I/O 型

什么是 I/O 型呢?网络访问、磁盘读写这都是典型的 I/O 操作,比如你访问 google,你的 I/O 开销可就大多了,我想会有人应看到 TIMEOUT,即便你访问 baidu,嗖的一下打开的网页,那段时间,对于计算机世界来说那也是极为漫长的等待,而这段时间你的 CPU 几乎提前进入了退休生活,一个字,闲。


磁盘访问也是一种 I/O 操作,磁盘如果是老式机械磁盘,那也是慢的出奇,即便后来的 SSD 相对于 CPU 时间片段来讲也漫长的很。

提升思路

  • 计算密集型(以下基于单核)

对于 CPU 密集型来讲,无能为力,如果本身一个 CPU 1 秒只能计算一个结果,你就是换成什么语言,什么架构它也不可能超过一个,最好的情况是等于 1 个,但基本达不到,为什么?


先说 Python,线程维护是有开销的,这个 CPU 得做,所以怎么可能到 1 个呢?有的初学者可能考虑换个语言加多线程,那可能比单线程还惨,多线程来回上下文切换,更耗资源


不说硬件的提升,光说代码,这时候应该考虑算法本身的提升,比如图片计算里,考虑换成矩阵计算会不会好些?或者看是不是有些计算是多余等等。当然如果考虑硬件的提升,那就没有止境了。


  • I/O 型(以下基于单核)

对于 Python, I/O 密集型的应用还是有提升的余地的。如果说 I/O 等待占据了大部分时间,我们这会可以考虑“多线程”(如果已 1 秒为单位,即便是 GIL 存在,那也会有 n 个线程被执行),如果 I/O 等待的时间远远大于获取 GIL(全局大锁)的时间,那多线程势必会提升速度。


多进程,虽然只有一个 CPU,还是要看进程切换的时间和 I/O 等待的时间的对比,如果 I/O 等待时间很长,那多进程之间的切换开销也就微不足道了。


协程,这个是个好东西,在一个线程里边,协程切换是用户态的,开销小的多,这也是提升性能的利剑。


  • 其他

多核情况下,不管计算密集型还是 I/O 型,多进程一定是能提升性能,毕竟一个人干活跟 10 个人干活肯定速度是不一样的。

GIL 依然存在

那能不能去掉 GIL 呢?答案显然是可以的,不然 golang 怎么做的?java 怎么做的?可是为什么不去掉 GIL 呢,我认为还是历史原因,首先很多 C 库是基于 GIL 做的,推翻了重整,你懂得,很难。另外如果真的完全去掉 GIL,那将是从里到外的巨大改进,前后兼容又成了巨大的问题。但是改进肯定有的。

发布于: 2021 年 01 月 05 日阅读数: 1441
用户头像

yunson

关注

还未添加个人签名 2019.07.09 加入

blog: https://yunsonbai.top 公众号: 技术and生活

评论

发布
暂无评论
Python的GIL