• GIL并不是Python的特性，Python完全可以不依赖于GIL
    • 为了更有效的利用多核处理器的性能，就出现了多线程的编程方式，而随之带来的就是线程间数据一致性和状态同步的困难。为了有效解决多份缓存之间的数据同步时各厂商花费了不少心思,就有了GIL,也不可避免的带来了一定的性能损失。
    • Python当然也逃不开，为了利用多核，Python开始支持多线程。而解决多线程之间数据完整性和状态同步的最简单方法自然就是加锁。 于是有了GIL这把超级大锁
    • GIL无疑就是一把全局排他锁。毫无疑问全局锁的存在会对多线程的效率有不小影响。甚至就几乎等于Python是个单线程的程序。 那么读者就会说了，全局锁只要释放的勤快效率也不会差啊。只要在进行耗时的IO操作的时候，能释放GIL，这样也还是可以提升运行效率的嘛。或者说再差也不会比单线程的效率差吧。理论上是这样，而实际上呢？Python比你想的更糟。
    • 但当CPU有多个核心的时候，问题就来了。从release GIL到acquire GIL之间几乎是没有间隙的。所以当其他在其他核心上的线程被唤醒时，大部分情况下主线程已经又再一次获取到GIL了。这个时候被唤醒执行的线程只能白白的浪费CPU时间，看着另一个线程拿着GIL欢快的执行着。然后达到切换时间后进入待调度状态，再被唤醒，再等待，以此往复恶性循环。GIL的存在导致多线程无法很好的利用多核CPU的并发处理能力。

    Python语言并没有GIL。
    CPython（以及试图与CPython完全兼容的）实现中有GIL。PyPy的主线中也有GIL。
    Jython、IronPython都没有GIL。
    Java语言并没有GIL。JVM规范也没有GIL。
    目前JVM最主要的实现HotSpot VM中没有使用GIL，而是在VM内使用了一系列细粒度锁来实现VM内各种功能分别的同步需求。但其实HotSpot VM源自一个名为Strongtalk的Smalltalk VM，在Stongtalk VM以及最早期的HotSpot VM中是有GIL的，通过多年的努力研发才把它替换为细粒度锁。
    C++语言没有GIL。C++的语言功能中也没有什么需要用一把全局大锁来总控的功能，所以实现中也没有C++ runtime library用“GIL”的（虽然有通过解释器实现的C++，所以这个“I”在这些实现里也算是成立把，但没有GIL）。

    1. GIL全称Global Interpreter Lock，每个线程在执行的过程都需要先获取GIL，保证同一时刻只有一个线程可以执行代码。
      2.GIL的缺点
      GIL使Python不能充分利用多核心CPU资源
      GIL会使Python代码 不管CPU有多少个核，也不管开了多个线程，但是同一时刻只能在一个核上面执行一个线程
      3.Python为什么要有GIL全局解释器锁？
      锁的机制： 保证对某一个变量j进行相关的操作的时候，同一时刻只有一个线程来执行
      只有拿到锁的线程,才能对变量进行相关的操作
      锁从语言上区分：
      细粒度的锁： 在代码中主动加的锁
      粗粒度的锁： 在整个Python的解释器(cpython)的层面加的锁，所以粗粒度的解释器的锁就是GIL,多核CPU，同一时刻只能执行一个线程 ，在一定程度上保证线程的安全
      4. 什么样的程序该使用进程，什么样的程序该使用线程？
      计算密集型程序(非常严重的依赖CPU计算)： 使用进程
      IO密集型程序(查询数据库、请求网络资源、读写文件)： 线程、协程

    文章看看：
    https://www.cnblogs.com/SuKiWX/p/8804974.html

    好文一篇：
    https://zhuanlan.zhihu.com/p/75780308