我们知道，现在python呢已经成为了一个非常普及的编程语言了，同时呢也已经成为了tiobe统计排名第一的语言，超过了java和C/C++。
TIOBE 2023年9月编程语言排行榜
因为python确实学习门槛低，非常容易上手。现在几乎所有人都会用python写一些简单的代码，实现自己的需求。但是，如果没有深入系统的学习python，也会掉进一些坑里。今天我们就来聊一聊一个有关一个身边985大学生掉进python 多线程GIL锁坑里的故事。
最近部门来了一个刚毕业的985研究生，人很聪明动手能力也很强，在组里负责激光雷达相关的模块开发。突然有一天，小伙找到我，说代码里遇到了性能瓶颈问题，一直解决不了，很困惑。仔细了解后，知道了他在用python里的2个线程分别读取2个激光雷达的数据然后做进一步分析处理，但发现其中一个线程的读取效率特别低始终无法提高。这两个线程是在同一个进程中创建的。显然，精通python的人都知道，这里是由于Python 进程中存在GIL锁（也就是Global Interpreter Lock，即全局解释器锁）而导致的，所以我建议他改用多进程来规避这个问题，他照做之后问题得到解决。
小伙也可能是刚接触python，现学现用，忽略了系统学习，所以导致了对GIL锁缺乏了解，所以掉进了坑里。可见，学习一门编程语言，系统的学习，抓住重点，打牢基础是多么重要，所谓磨刀不误砍柴工。同时，勤学好问，也很重要，遇到问题要多向团队里的人请教，当然，前提是这个团队不内卷，和谐友好。
现在我们说回这个Pyhon中的GIL锁。学习GIL锁，起码要搞清楚5个问题：1，什么是GIL锁；2，为什么Python必须引入GIL锁？3，GIL锁什么时候释放？4，如何解决GIL锁的性能问题？5，有了GIL锁，还需要用额外的锁吗？
第一个问题：什么是GIL锁？
GIL锁和在Python代码中使用线程锁Lock并不是一个层面的概念。GIL是在实现Python解释器(CPython)时所引入的一个概念，每一个Python进程运行时都对应一个CPython解释器进程。在CPython解释器内部运行多个线程的时候，每个线程在解释器内部申请相应的全局资源，为了防止资源竞争而发生错误，对所有线程申请全局资源增加了限制-必须获得全局解释器锁GIL。每个线程想要运行首先获取这个解释器进程中唯一的GIL，因此Python进程中所有线程只能一个一个交替的执行。所以在Python程序里，就算使用多线程，运行在多核CPUS上，其实还是一个线程在工作，这是CPython的一个缺陷，其他语言没有。
第二个问题：为什么Python必须引入GIL？
Python调用的线程都是原生线程，通过C语言提供原生接口，相当于C语言的一个函数，一旦执行Python解释器就再也不能控制它，必须等它返回结果。如果启动n个线程，那么这n个线程独自执行，访问全局资源，会造成资源竞争，结果就会有问题。CPython加入GIL，就可以在同一时间只有拿到GIL锁的一个线程能够工作。虽然这n个线程都启动了，但是同一时间只能让一个线程访问全局数据，其他的几个都只能等待。
第三个问题：GIL什么时候释放？
在当前线程执行超时后会自动释放，python 3.x使用计时器（执行时间达到阈值后，当前线程释放GIL）或Python 2.x，tickets计数达到100
在当前线程执行阻塞操作时会自动释放，比如在IO操作等可能会引起阻塞的system call之前,可以暂时释放GIL,但在执行完毕后,必须重新获取GIL，因此多线程爬取比单线程性能有提升，因为遇到IO阻塞会自动释放GIL锁。
第四个问题：如何解决GIL锁的性能问题？
多线程程序在进行IO等操作时的运行速度还是要比单线程速度快，但是在运行计算密集型的程序时，需要使用CPU进行大量的计算，但由于GIL锁的性质导致程序执行中始终都是一个CPU进行计算，所以计算速度及其缓慢，运行此类的程序不推荐使用线程，有两种方式解决：
1，使用多进程的方式，避免GIL锁的约束；
2，使用其他运行速度较快的语言模块，例如C语言。
第五个问题：既然存在GIL是否意味每个线程访问全局数据就不用加Lock互斥锁了呢？
用户操作全局数据还是必须加Lock，因为GIL的释放时机我们无法控制，此时对全局数据的操作很可能并没有完成，而不像Lock那样我们用完才释放。
当然，python的GIL锁一直被开发者诟病，python官方团队也心知肚明，所以最近Python 团队已经正式接受了删除 GIL 的这个提议，并将其设置为可选模式。
深度学习三巨头之一的 Yann LeCun 发文欢呼：没有了 GIL，现在，Python 代码可以自由的执行多线程了。
深度学习三巨头之一的 Yann LeCun 发文祝贺
CPython 核心开发者 Thomas Wouters 撰文描述了 Python 中的无 GIL 细节，并对未来发展做了展望。短期内，会将 no-GIL 构建作为一种实验性构建模式，大概会在 3.13 版本（也有可能推迟到 3.14 版本，目前官网的python版本是3.12版本）支持，比如允许用户关闭GIL锁，然后在未来某个版本将no-GIL设置为默认方式。长期来看，希望 no-GIL 成为默认方式，并删除 GIL 的所有痕迹（但不会不必要地破坏向后兼容性）。所以，python实现真正多线程的那一天也许不会太遥远了。
好，这次我们就聊到这里，谢谢大家的观看，下次再见
