Python 第一次发布是在 1991 年，当时的 CPU 都是单核，单核中，多线程主要为了一边做IO，一边做 CPU 计算而设计的，Python 编译器是由 C 语言编写的，因此也叫 CPython，那时候很多编程语言没有自动内存管理的功能，为了实现自动垃圾回收，Python 为每一个对象进行了引用计数，当引用计数为 0 的时候说明该对象可以回收，从而释放内存了，比如：
- >>> import sys
- >>> data = { 'gzh': 'Python七号'}
- >>> var1 = data
- >>> sys.getrefcount(data)
- 3
- >>>
这里 data 对象就有 3 个引用， 一个是本身，一个是变量 var1，一个是 getrefcount 函数的参数，如果此时又有一个线程引用了 data，那么引用计数再增加 1，如果某个线程使用了 data 后运行结束，那么引用计数就减少 1，多线程对同一个变量「引用计数」进行修改，就会遇到 race conditions(竞争)，为了避免 race conditions，最简单有效的办法就是加一个互斥锁。
如果对每一个对象都加锁，有可能引发另一个问题，就是死锁，而且频繁的获取和释放会导致性能下降，最简单有效的方法就是加一个解释器锁，线程在执行任何字节码时都先获取解释器锁，这就避免了死锁，而且不会有太多的性能消耗。当时 CPU 都是单核，而且这种 GIL 设计简单，并不会影响性能，因此一直沿用至今天。GIL 存在最主要的原因，就是因为 Python 的内存管理不是线程安全的，这就是 GIL 产生并存在的主要缘由。
尝试消除 GIL
CPU 进入多核时代后，可以同时做多个计算任务, GIL 才真正变成问题。在 1999 年，有个叫 Greg Stein 的大佬基于 Python 1.5 版本消除了 GIL，取代代之的是在可变数据结构上加上更细粒度的锁，也提交了补丁用于去除对全局可变对象的依赖，然后在标准测试时表明去除 GIL 后单线程比不去除时慢了近 2 倍，测试的机器还是当时性能最好 Windows 机器。也就是说除去了 GIL 后，你使用 2 个 CPU 才能获取比原来 1 个 CPU 稍微好一点的性能，这种提升明显得不偿失，Greg Stein 的尝试也就失败告终。
Python 之父 Guido van Rossum 也欢迎社区的志愿者去尝试去除 GIL，只要不降低单线程的性能，但他也提到，去掉 GIL 不是一件容易的事。
Python 开发者邮件列表中也偶尔会有去除 GIL 的议题，但是以下需求必须满足：
- 简单。从长远来看该方案必须是可实施、可维护的。
- 并发。去除 GIL 必须能提升多线程的性能。
- 速度。去除 GIL 不能降低单线程的性能。
- 满足 CPython 的特性。该方案必须支持 CPython 的功能，比如 __del__ 和弱引用。
- API 的兼容性。该方案应与所有现有CPython扩展使用的宏在源方面兼容。
- 及时销毁不可达对象，回收内存。
- 有序销毁，比如不可达对象 X 引用了 A，那么应该在销毁 A 之前先销毁 X(有些垃圾回收算法并不能做到这一点)。
有些需求不容易被满足，比如 4，5，7，目前，还没有人满足以上需求的同时去除 GIL 成功的。
