为什么有人说 Python 的多线程是鸡肋
因为 Python 中臭名昭著的 GIL。
那么 GIL 是什么？为什么会有 GIL？多线程真的是鸡肋吗？ GIL 可以去掉吗？带着这些问题，我们一起往下看，同时需要你有一点点耐心。
多线程是不是鸡肋，我们先做个实验，实验非常简单，就是将数字 “1亿” 递减，减到 0 程序就终止，这个任务如果我们使用单线程来执行，完成时间会是多少？使用多线程又会是多少？show me the code
单线程
在我的4核 CPU 计算机中，单线程所花的时间是 6.5 秒。可能有人会问，线程在哪里？其实任何程序运行时，默认都会有一个主线程在执行。（关于线程与进程这里不展开，我会单独开一篇文章）
多线程
创建两个子线程 t1、t2，每个线程各执行 5 千万次减操作，等两个线程都执行完后，主线程终止程序运行。结果，两个线程以合作的方式执行是 6.8 秒，反而变慢了。按理来说，两个线程同时并行地运行在两个 CPU 之上，时间应该减半才对，现在不减反增。
是什么原因导致多线程不快反慢的呢？
原因就在于 GIL ，在 Cpython 解释器（Python语言的主流解释器）中，有一把全局解释锁（Global Interpreter Lock），在解释器解释执行 Python 代码时，先要得到这把锁，意味着，任何时候只可能有一个线程在执行代码，其它线程要想获得 CPU 执行代码指令，就必须先获得这把锁，如果锁被其它线程占用了，那么该线程就只能等待，直到占有该锁的线程释放锁才有执行代码指令的可能。
因此，这也就是为什么两个线程一起执行反而更加慢的原因，因为同一时刻，只有一个线程在运行，其它线程只能等待，即使是多核CPU，也没办法让多个线程「并行」地同时执行代码，只能是交替执行，因为多线程涉及到上线文切换、锁机制处理（获取锁，释放锁等），所以，多线程执行不快反慢。
什么时候 GIL 被释放呢？
当一个线程遇到 I/O 任务时，将释放GIL。计算密集型（CPU-bound）线程执行 100 次解释器的计步（ticks）时（计步可粗略看作 Python 虚拟机的指令），也会释放 GIL。可以通过设置计步长度，查看计步长度。相比单线程，这些多是多线程带来的额外开销
CPython 解释器为什么要这样设计？
多线程是为了适应现代计算机硬件高速发展充分利用多核处理器的产物，通过多线程使得 CPU 资源可以被高效利用起来，Python 诞生于1991年，那时候硬件配置远没有今天这样豪华，现在一台普通服务器32核64G内存都不是什么司空见惯的事
但是多线程有个问题，怎么解决共享数据的同步、一致性问题，因为，对于多个线程访问共享数据时，可能有两个线程同时修改一个数据情况，如果没有合适的机制保证数据的一致性，那么程序最终导致异常，所以，Python之父就搞了个全局的线程锁，不管你数据有没有同步问题，反正一刀切，上个全局锁，保证数据安全。这也就是多线程鸡肋的原因，因为它没有细粒度的控制数据的安全，而是用一种简单粗暴的方式来解决。
这种解决办法放在90年代，其实是没什么问题的，毕竟，那时候的硬件配置还很简陋，单核 CPU 还是主流，多线程的应用场景也不多，大部分时候还是以单线程的方式运行，单线程不要涉及线程的上下文切换，效率反而比多线程更高（在多核环境下，不适用此规则）。所以，采用 GIL 的方式来保证数据的一致性和安全，未必不可取，至少在当时是一种成本很低的实现方式。
那么把 GIL 去掉可行吗？
还真有人这么干多，但是结果令人失望，在1999年Greg Stein 和Mark Hammond 两位哥们就创建了一个去掉 GIL 的 Python 分支，在所有可变数据结构上把 GIL 替换为更为细粒度的锁。然而，做过了基准测试之后，去掉GIL的 Python 在单线程条件下执行效率将近慢了2倍。
Python之父表示：基于以上的考虑，去掉GIL没有太大的价值而不必花太多精力。
2018-07-29 · 百度知道合伙人官方认证企业
育知同创教育
其它的语言也有类似的情况，线程本身的特点导致线程的适用范围是受限的。只有CPU过剩，而其它的任务很慢，此时用线程才是有益的，可以很好平衡等待时间，提高并发性能。
线程的问题主要是线程的安全稳定性。线程无法强制中止，同时线程与主进程共享内存，可能会影响主进程的内存管理。
在python里线程出问题，可能会导致主进程崩溃。 虽然python里的线程是操作系统的真实线程。
那么怎么解决呢？通过我们用进程方式。子进程崩溃后，会完全的释放所有的内存和错误状态。所以进程更安全。 另外通过进程，python可以很好的绕过GIL，这个全局锁问题。
但是进程也是有局限的。不要建立超过CPU总核数的进程，否则效率也不高。
简单的总结一下。
当我们想实现多任务处理时，首先要想到使用multiprocessing， 但是如果觉着进程太笨重，那么就要考虑使用线程。 如果多任务处理中需要处理的太多了，可以考虑多进程，每个进程再采用多线程。如果还处理不要，就要使用轮询模式，比如使用poll event, twisted等方式。如果是GUI方式，则要通过事件机制，或者是消息机制处理，GUI使用单线程。
所以在python里线程不要盲目用， 也不要滥用。 但是线程不安全是事实。如果仅仅是做几个后台任务，则可以考虑使用守护线程做。如果需要做一些危险操作，可能会崩溃的，就用子进程去做。 如果需要高度稳定性，同时并发数又不高的服务。则强烈建议用多进程的multiprocessing模块实现。
在linux或者是unix里，进程的使用代价没有windows高。还是可以接受的。
其它的语言也有类似的情况，线程本身的特点导致线程的适用范围是受限的。只有CPU过剩，而其它的任务很慢，此时用线程才是有益的，可以很好平衡等待时间，提高并发性能。
线程的问题主要是线程的安全稳定性。线程无法强制中止，同时线程与主进程共享内存，可能会影响主进程的内存管理。
在python里线程出问题，可能会导致主进程崩溃。 虽然python里的线程是操作系统的真实线程。
那么怎么解决呢？通过我们用进程方式。子进程崩溃后，会完全的释放所有的内存和错误状态。所以进程更安全。 另外通过进程，python可以很好的绕过GIL，这个全局锁问题。
但是进程也是有局限的。不要建立超过CPU总核数的进程，否则效率也不高。
简单的总结一下。
当我们想实现多任务处理时，首先要想到使用multiprocessing， 但是如果觉着进程太笨重，那么就要考虑使用线程。 如果多任务处理中需要处理的太多了，可以考虑多进程，每个进程再采用多线程。如果还处理不要，就要使用轮询模式，比如使用poll event, twisted等方式。如果是GUI方式，则要通过事件机制，或者是消息机制处理，GUI使用单线程。
所以在python里线程不要盲目用， 也不要滥用。 但是线程不安全是事实。如果仅仅是做几个后台任务，则可以考虑使用守护线程做。如果需要做一些危险操作，可能会崩溃的，就用子进程去做。 如果需要高度稳定性，同时并发数又不高的服务。则强烈建议用多进程的multiprocessing模块实现。
在linux或者是unix里，进程的使用代价没有windows高。还是可以接受的。
Python多线程有没有用，有，你去爬图片站的时候，用单进程单线程这种方式，进程很容易阻塞在获取数据socket函数上，多线程可以缓解这种情况。你说解决没有，要是每个请求都阻塞起了，那多线程也没什么用（当然，这种情况没见过哈）。
Python的优势就在于写起来快，用起来方便。你要做计算密集型的，还想并行化的话，还是用C吧。
