GIL全局解释器锁

杂谈 GIL

1. gil 啥？
   
   • 顾名思义，这是解释器内部的一把锁，确切一点说是CPython解释器内部的一把锁，所以要注意区分 这和我们在Python代码中使用Lock不是一个层面的概念。

2. 他是如何产生的？
   — GIL产生的背景 在CPython解释内部运行多个线程的时候，每个线程都需要解释器内部申请相应的全局资源，由于C语言本身比较底层造成CPython在管理所有全局资源的时候并不能应对所有线程同时的资源请求，因此为了防止资源竞争而发生错误，对所有线程申请全局资源增加了限制-全局解释器锁。

   言外之意，就是全局解释器就是为了锁定整个解释器内部的全局资源，每个线程想要运行首先获取GIL，而GIL本身又是一把互斥锁，造成所有线程只能一个一个one-by-one-并发-交替的执行。

3. git 什么时候释放？

   • 在当前线程执行超时后会自动释放
   • 在当前线程执行阻塞操作时会自动释放
   • 当前执行完成时

4. 错误的想法

   • Python语言和GIL没有半毛钱关系。仅仅是由于历史原因在Cpython虚拟机(解释器)，难以移除GIL。
   • GIL：全局解释器锁。每个线程在执行的过程都需要先获取GIL，保证同一时刻只有一个线程可以执行代码。
   • 线程释放GIL锁的情况：
     — 在IO操作等可能会引起阻塞的system call之前,可以暂时释放GIL,但在执行完毕后,必须重新获 取GIL
     — Python 3.x使用计时器（执行时间达到阈值后，当前线程释放GIL）或Python 2.x，tickets计数达到100
   • Python使用多进程是可以利用多核的CPU资源的
   • 对于在爬虫中多线程爬取比单线程性能有提升，因为遇到IO阻塞会自动释放GIL锁

严重问题: 既然CPython解释存在GIL是否意味每个线程在全局变量就不用加Lock互斥锁了呢？ 这是一个严重错误的想法，为什么用户操作全局数据还需要加Lock，因为GIL的释放时机我们无法控制-操作非常可能并没有完成，而不像Lock那样我们用完才释放(操作完整)。

例如：
–线程1 取出全局变量 g_number == 0 一直加到20000，但是还没有来得及将20000写入g_number中，就超时了自动释放GIL 而线程2 取出g_number==19999 加到39999由于超时自动释放GIL 此时线程2获取到GIL继续着未完成的事业将20000写入g_number…… 这就是我们之前的多线程案例没有加互斥锁的情况最终结果是140w左右的原因。