Python 有GIL保证相关对象的同时操作，那为什么还需要进行线程同步？是不是因为在虚拟机层面之上在多线程工作时还需要提供相关的锁机制、队列机制，这其中的原理是什么？有其他类似的例子吗？ 还是说Python内部的GIL保证了一个变量的引用数量，但是当多线程使用同一资源时，例如sys.stdout，这个时候是需要线程同步来确保资源访问不冲突，GIL不提供类似资源的保护吗？
回复内容：
GIL也只是相当于古时候单核CPU通过不断的分配时间片来模拟多线程的方法而已，为什么那个时候写多线程也要用锁？
这在网上都说烂了. 不过我当初也思考了这个问题一会儿.
你自己想想看这个情景
线程AB同时操作list
list的[0]初始值为0
线程A 操作100次
list[0]+=1
线程B 操作100次
list[0]+=1
在线程A 对于 list[0]进行操作时
list[0]为0, 还没等线程A完成加一操作, 就被切换到线程B了
在线程B 眼里,
list[0]还是为0, 于是执行加一操作.
再切换回线程A, 继续未完成的加一操作
你发现了没!!! 线程AB各对list[0]进行了加一,预期结果是2 但结果还是1
Python的list不是完全线程安全的.所以加个线程锁就完了.
话说为什么, 有了线程锁还需要GIL呢?
因为, 有了GIL, 提供并发就变得很容易. 解释器只要计算每个线程的运行时间就好了
时间一到, 将这个线程冻结, 内存管理很简单.
等等, 你还是没解释, 如果我已经给线程上了锁, 为什么还是要被GIL限制?
一向符合人类直觉的Python, 有个很反直觉的机制.
Py的变量a其实不是C系编译语言的变量.
Python维护着一个字典, 储存着a和对应数值的指针.用某黑Python的大牛的话说, Python企图用字典装下世界..
如果变成真多线程
对于这个字典的维护将会很复杂.
多个线程真正同时操作一个字典, Python引以为傲的字典性能, 估计就没那么强了.
就是说, Python字典的性能强大,是建立在线程不安全的基础上.
而字典在Python中的位置又是如此重要, 一个缓慢的字典, 会严重拖慢Python的解释速度.
多线程操作多个独立字典. 那样还是要同步.
那为什么不采用多进程呢? 这就是社区主流的看法.
虽然理论上线程成本更低, 但是那样代码就改成面目全非了..
GIL 的作用是：对于一个解释器，只能有一个thread在执行bytecode。所以每时每刻只有一条bytecode在被执行一个thread。GIL保证了bytecode 这层面上是thread safe的。
但是如果你有个操作比如 x += 1，这个操作需要多个bytecodes操作，在执行这个操作的多条bytecodes期间的时候可能中途就换thread了，这样就出现了data races的情况了。
比如这小家伙就有很多条bytecodes：
>>> dis.dis(lambda x: x+1)
1 0 LOAD_FAST 0 (x)
3 LOAD_CONST 1 (1)
6 BINARY_ADD
7 RETURN_VALUE
https://www.youtube.com/watch?v=ph374fJqFPE
gil控制的是字节码， 锁控制的是python代码，粒度不一样吧？ 比如用锁控制的代码被编译成101条字节码 那么线程在执行这101条字节码的时候，cpu会被其他线程利用（python调度线程默认是100条字节码 调度一次）
——《Python源码剖析》
GIL是全局解释器锁，GIL保证了在同一时间片下总有一个Python(CPython实现)线程在执行。所以即使是多进程，而是顺序执行的。这样多线程并发就变得没有意义。
- 线程在GIL下是有执行的时间片的
- 在时间片内线程如果没有成功对数据进行操作，那么等到下一个时间片时，数据已经被别的线程修改了，那么得到的数据就不是想要的数据了
- 线程的同步和互斥解决的是线程间数据的访问正确性问题，而GIL是实现当前Python解释器下只有一个线程在执行。两个是不同的概念。
