1.认识GIL:
说到GIL一直是代码专家们一直以来想要解决的问题，也是被许多程序员诟病的，下面带领大家看下官方threading模块document中如何去描述对于GIL这个全局解释器锁的：https://docs.python.org/3/library/threading.html
全局解释器锁
所使用的机制的CPython解释器来确保只有一个线程执行的Python 字节码在一个时间。通过使对象模型（包括关键的内置类型，例如dict）隐式安全地防止并发访问，从而简化了CPython的实现。锁定整个解释器可以使解释器更容易进行多线程处理，但会牺牲多处理器机器提供的许多并行性。
但是，某些扩展模块（标准的或第三方的）被设计为在执行诸如压缩或散列之类的计算密集型任务时释放GIL。另外，在执行I / O时，始终释放GIL。
过去创建“自由线程”解释器（一种以更精细的粒度锁定共享数据的解释器）的努力并未成功，因为在常见的单处理器情况下性能会受到影响。相信克服该性能问题将使实施更加复杂，因此维护成本更高。
在这里专门对全局解释器锁的概念引入时说了这么一段话，第一指明了GIL造成了python解释器一次只有一个线程可以获取解释器锁，也就是解释器本身是自带锁的，谁先拿到谁就可以抢占到cpu的资源，
从而导致了python无论一个线程怎么去跑，都只能最多跑满一个cpu核心，就造成了多核cpu资源的无法利用的带来的资源浪费，但是这是否就意味着python一无是处呢，答案肯定No!,虽然GIL对于cpu密集的支持
不是那么的友好，但是，对于IO密集的支持恰恰是其他语言所无法比拟的，就拿asyncio这这个协程库来讲：https://docs.python.org/3/library/asyncio.html
1.第一部分认识多线程创建以及调用，上一节我讲解了源码关于多线程实现方式有两种：第一种通过Thread类传入可调用target对象，第二种继承Thread类并重写run方法：
下面就以target进行举例：
可以看到线程的资源抢占效果；证明GIL锁的的确真实存在的；
先在我们如果更换t.join（）到t1.start()的后面会发现，线程每次不管怎么运行都是先执行完threading1线程，再去执行threading2线程，而这完全得益于joIn()函数：
我们来看源码是怎么解释join()的：
等待直到线程终止。这将阻塞调用线程，直到join()被调用方法的线程终止（正常或通过未处理的异常终止），或者直到发生可选的超时。
讲完join（）:
我们再来认识一个有趣的参数daemon->守护线程：
先看源码：
daemon用‘来指示线程是否是守护线程，必须在线程start()方法调用之前设置，否则会引发RunTimeError，当不存在活动的非守护线程时将退出python程序
演示daemon：
正常默认daemon为False:
可以看到主线程运行结束后退出后子线程继续运行并输出了内容，
但是加入现在有个需求要求我们实现主线程退出后必须kill掉子线程那么，如何实现这个需求，这就用到了daemon，我们只需要设置为True:
主线程运行结束后并没有等待子线程
运行完毕就kill掉了子线程
原文：https://www.cnblogs.com/SunshineKimi/p/12310495.html