python不支持多线程

1. 为什么有人说 python 的多线程是鸡肋

Python多线程最多占用一个逻辑核心。
如果你每个线程都是io密集型（阻塞多于计算），也就是说单独一个线程几乎大段时间没事儿干，不能充分利用cpu，那可能多线程跑在一个核心上还有意义；
如果每个线程都是计算密集型（几乎都是计算任务），那一般情况1个线程就可以充分利用一个逻辑核心，多个线程反而增加了切换开销。从这个角度上说Python的多线程确实鸡肋。
多进程可以解决这个问题，因为进程不是由Python管理的，而是由系统管理的，系统会合理分配CPU资源。

2. 为什么有人说 Python 的多线程是鸡肋

简单地说就是作为可能是仅有的支持多线程的解释型语言（perl的多线程是残疾，PHP没有多线程），Python的多线程是有compromise的，在任意时间只有一个Python解释器在解释Python bytecode。

UPDATE：如评论指出，Ruby也是有thread支持的，而且至少Ruby MRI是有GIL的。

如果你的代码是CPU密集型，多个线程的代码很有可能是线性执行的。所以这种情况下多线程是鸡肋，效率可能还不如单线程因为有context switch

但是：如果你的代码是IO密集型，多线程可以明显提高效率。例如制作爬虫（我就不明白为什么Python总和爬虫联系在一起…不过也只想起来这个例子…），绝大多数时间爬虫是在等待socket返回数据。这个时候C代码里是有release GIL的，最终结果是某个线程等待IO的时候其他线程可以继续执行。

反过来讲：你就不应该用Python写CPU密集型的代码…效率摆在那里…

如果确实需要在CPU密集型的代码里用concurrent，就去用multiprocessing库。这个库是基于multi process实现了类multi thread的API接口，并且用pickle部分地实现了变量共享。

再加一条，如果你不知道你的代码到底算CPU密集型还是IO密集型，教你个方法：

multiprocessing这个mole有一个mmy的sub mole，它是基于multithread实现了multiprocessing的API。

假设你使用的是multiprocessing的Pool，是使用多进程实现了concurrency

from multiprocessing import Pool

如果把这个代码改成下面这样，就变成多线程实现concurrency

from multiprocessing.mmy import Pool

两种方式都跑一下，哪个速度快用哪个就行了。

UPDATE:
刚刚才发现concurrent.futures这个东西，包含ThreadPoolExecutor和ProcessPoolExecutor，可能比multiprocessing更简单

3. 为什么有人说 Python 的多线程是鸡肋呢

由于python是一种解释性脚本语言，因此运行过程中始终存在全局线程锁。
简单的来说就是在实际的运行过程中，python只能利用一个线程，因此python的多线程并不达到C语言多线程的性能。

建议使用多进程来代替多线程，但需要注意的是多进程最好不要涉及到例如文件操作的频繁操作IO的功能。

4. 为什么有人说 Python 的多线程是鸡肋

因为 Python 中臭名昭着的 GIL。

那么 GIL 是什么？为什么会有 GIL？多线程真的是鸡肋吗？ GIL 可以去掉吗？带着这些问题，我们一起往下看，同时需要你有一点点耐心。

多线程是不是鸡肋，我们先做个实验，实验非常简单，就是将数字 “1亿” 递减，减到 0 程序就终止，这个任务如果我们使用单线程来执行，完成时间会是多少？使用多线程又会是多少？show me the code

那么把 GIL 去掉可行吗？

还真有人这么干多，但是结果令人失望，在1999年Greg Stein 和Mark Hammond 两位哥们就创建了一个去掉 GIL 的 Python 分支，在所有可变数据结构上把 GIL 替换为更为细粒度的锁。然而，做过了基准测试之后，去掉GIL的 Python 在单线程条件下执行效率将近慢了2倍。

Python之父表示：基于以上的考虑，去掉GIL没有太大的价值而不必花太多精力。

5. 为什么有人说 Python 的多线程是鸡肋

多线程还是有用的，多进程有多进程的好处，多线程有多线程的好处。
多进程稳定，启动时开销大点，但如果你的运行时间远大于多进程的时间，用多进程比较方便，如postgresql用多进程，chrome 多进程。
如果你只是想做个定时器样的简单东西，对稳定性要求低些，如vb,c#类似的定时器，用多线程吧，但线程的同步要注意了。python的线程更加类似定时器，python的线程不是真线程，但有的场合用这种定时器也能解决很多问题，因为开销小，开启也方便。
进程和线程，一个是重量级的，一个轻量级的，重量级的进程有保护区，进程上下文都是操作系统保护的，而线程是自己管理，需要一定的技术，不能保证在并发时的稳定性（多进程也不稳定，但很容易看出来，因为多出了进程容易发现），而python的更像是定时器，定时器有时也可以模拟线程，定时器多时的开销比线程的开销要小，真线程有下上文开销，一个操作系统启动多进程和多线程会达到切换饱和是有数量的，真线程或进程太多都会导致cpu占用率居高不下，而定时器可以开n多。
很多东西不是一种比另外一种先进，而是一种互补的关系，计算机的计算单位切换有优点必有缺点，关键在找到合适的使用方式扬长避短。

6. 为什么我的python多线程不能交替运行

不会,python目前不适应运行在多核上的多线程。仅能使用单核,如果需要多核你可以考虑多进程方式。

7. 为什么说Python没有真正意义上的多线程

因为python解释器同一个时间只能使用一个cpu，所以再多的线程还是使用同一个cpu
真正的多线程是充分利用多个cpu的计算能力的

8. pyhon多线程无效，不知问题出现在哪里

在python里线程出问题，可能会导致主进程崩溃。 虽然python里的线程是操作系统的真实线程。
那么怎么解决呢？通过我们用进程方式。子进程崩溃后，会完全的释放所有的内存和错误状态。所以进程更安全。 另外通过进程，python可以很好的绕过GIL，这个全局锁问题。
但是进程也是有局限的。不要建立超过CPU总核数的进程，否则效率也不高。
简单的总结一下。
当我们想实现多任务处理时，首先要想到使用multiprocessing， 但是如果觉着进程太笨重，那么就要考虑使用线程。 如果多任务处理中需要处理的太多了，可以考虑多进程，每个进程再采用多线程。如果还处理不要，就要使用轮询模式，比如使用poll event, twisted等方式。如果是GUI方式，则要通过事件机制，或者是消息机制处理，GUI使用单线程。
所以在python里线程不要盲目用， 也不要滥用。 但是线程不安全是事实。如果仅仅是做几个后台任务，则可以考虑使用守护线程做。如果需要做一些危险操作，可能会崩溃的，就用子进程去做。 如果需要高度稳定性，同时并发数又不高的服务。则强烈建议用多进程的multiprocessing模块实现。
在linux或者是unix里，进程的使用代价没有windows高。还是可以接受的。

9. 为什么有人说 Python 的多线程是鸡肋呢

首先，我并不认同这个观点，我觉得觉得Python 的多线程是鸡肋多余的人，应该还没有完全使用过Python 的多线程功能，并没有发掘它的潜在能力。

• 什么是Python多线程

Python多线程最大的优点就是使用方便，很多时候我们并不需要做大量的密集型数据的处理运算，这时候用Python多线程是最方便快捷的，可以大大减少工作量、提高工作效率。

• 总结

从以上几点我们就可以看出，Python多线程并不鸡肋，只是有时候使用者在不巧当的地方使用，它自然不是那么顺手，我们加深熟悉了解Python多线程的适用范围。

10. 为什么有人说 Python 的多线程是鸡肋

说这句话的人一定是在网上看到一些资料说，python的多线程不支持多核计算的，几乎不会提高运行效率。其实这句话只是对于CPython。因为CPython中存在GIL锁，每次只能有一个线程可以访问字节码。这样，即便线程再多，即便多核，线程都不可能同时执行，因为字节码一个时刻只能由一个线程访问。

参考官方资料：
Global interpreter lock
The mechanism used by the CPython interpreter to assure that only one thread executes Python bytecode at a time. This simplifies the CPython implementation by making the object model (including critical built-in types such as dict) implicitly safe against concurrent access. Locking the entire interpreter makes it easier for the interpreter to be multi-threaded, at the expense of much of the parallelism afforded by multi-processor machines.
However, some extension moles, either standard or third-party, are designed so as to release the GIL when doing computationally-intensive tasks such as compression or hashing. Also, the GIL is always released when doing I/O.
Past efforts to create a “free-threaded” interpreter (one which locks shared data at a much finer granularity) have not been successful because performance suffered in the common single-processor case. It is believed that overcoming this performance issue would make the implementation much more complicated and therefore costlier to maintain.