python多线程是假的,python多进程和多线程究竟谁更快

python多线程是假的,python多进程和多线程究竟谁更快详细介绍

本文目录一览： 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这个module有一个dummy的sub module，它是基于multithread实现了multiprocessing的API。
假设你使用的是multiprocessing的Pool，是使用多进程实现了concurrency
from multiprocessing import Pool
如果把这个代码改成下面这样，就变成多线程实现concurrency
from multiprocessing.dummy import Pool
两种方式都跑一下，哪个速度快用哪个就行了。
UPDATE:
刚刚才发现concurrent.futures这个东西，包含ThreadPoolExecutor和ProcessPoolExecutor，可能比multiprocessing更简单

python之多线程

进程的概念：以一个整体的形式暴露给操作系统管理，里面包含各种资源的调用。 对各种资源管理的集合就可以称为进程。 线程的概念：是操作系统能够进行运算调度的最小单位。本质上就是一串指令的集合。
进程和线程的区别： 1、线程共享内存空间，进程有独立的内存空间。 2、线程启动速度快，进程启动速度慢。注意：二者的运行速度是无法比较的。 3、线程是执行的指令集，进程是资源的集合 4、两个子进程之间数据不共享，完全独立。同一个进程下的线程共享同一份数据。 5、创建新的线程很简单，创建新的进程需要对他的父进程进行一次克隆。 6、一个线程可以操作（控制）同一进程里的其他线程，但是进程只能操作子进程 7、同一个进程的线程可以直接交流，两个进程想要通信，必须通过一个中间代理来实现。 8、对于线程的修改，可能会影响到其他线程的行为。但是对于父进程的修改不会影响到子进程。
第一个程序，使用循环来创建线程，但是这个程序中一共有51个线程，我们创建了50个线程，但是还有一个程序本身的线程，是主线程。这51个线程是并行的。注意：这个程序中是主线程启动了子线程。
相比上个程序，这个程序多了一步计算时间，但是我们观察结果会发现，程序显示的执行时间只有0.007秒，这是因为最后一个print函数它存在于主线程，而整个程序主线程和所有子线程是并行的，那么可想而知，在子线程还没有执行完毕的时候print函数就已经执行了，总的来说，这个时间只是执行了一个线程也就是主线程所用的时间。
接下来这个程序，吸取了上面这个程序的缺点，创建了一个列表，把所有的线程实例都存进去，然后使用一个for循环依次对线程实例调用join方法，这样就可以使得主线程等待所创建的所有子线程执行完毕才能往下走。 注意实验结果：和两个线程的结果都是两秒多一点
注意观察实验结果，并没有执行打印task has done，并且程序执行时间极其短。 这是因为在主线程启动子线程前把子线程设置为守护线程。 只要主线程执行完毕，不管子线程是否执行完毕，就结束。但是会等待非守护线程执行完毕 主线程退出，守护线程全部强制退出。皇帝死了，仆人也跟着殉葬 应用的场景 ： socket-server
注意：gil只是为了减低程序开发复杂度。但是在2.几的版本上，需要加用户态的锁（gil的缺陷）而在3点几的版本上，加锁不加锁都一样。
下面这个程序是一个典型的生产者消费者模型。 生产者消费者模型是经典的在开发架构中使用的模型 运维中的集群就是生产者消费者模型，生活中很多都是
那么，多线程的使用场景是什么？ python中的多线程实质上是对上下文的不断切换，可以说是假的多线程。而我们知道，io操作不占用cpu，计算占用cpu，那么python的多线程适合io操作密集的任务，比如socket-server，那么cpu密集型的任务，python怎么处理？python可以折中的利用计算机的多核：启动八个进程，每个进程有一个线程。这样就可以利用多进程解决多核问题。

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

差不多是这样子。多线程目前仅用于网络多线程采集， 以及性能测试。
其它的语言也有类似的情况，线程本身的特点导致线程的适用范围是受限的。只有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多线程是不是鸡肋，是，GIL那个东西再那里摆着，就算在多核下面Python也是无法并行的，这个好理解嘛，就相当于做了个分时复用。
Python多线程有没有用，有，你去爬图片站的时候，用单进程单线程这种方式，进程很容易阻塞在获取数据socket函数上，多线程可以缓解这种情况。你说解决没有，要是每个请求都阻塞起了，那多线程也没什么用（当然，这种情况没见过哈）。
Python的优势就在于写起来快，用起来方便。你要做计算密集型的，还想并行化的话，还是用C吧。
因为 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没有太大的价值而不必花太多精力。

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

他有个全局锁。
没法利用多核。
虽然 Python 提供了多线程包 但是 Python 并不支持真正意义上的多线程
Python 中有一个叫 GIL 的东西 它能确保代码中永远只有一个线程在执行
经过 GIL 的处理 会增加执行的开销
这就意味着 如果很关心代码执行效率的话 使用 threading 并不是一个好办法
当然如果代码是 I／O 密集型 那么多线程倒是可以明显提高效率
如果代码是 CPU 密集型的话 多线程大部分就是鸡肋了

python的多线程到底有没有用

很有用，就看你怎么用
线程主要用于异步操作。只要有异步的IO，或者是异步的操作，等待都可以用线程。
但是python的线程不足够安全。同时它还有GIL的问题。线程的退出也不太容易。所以在python里经常用进程代替线程。但是如果并发内容太多，只能用多进程+多线程方式。
总体来讲。只要用法正确。python的线程还是很可靠的。起动和完成几万次线程。一次不出错，也是有可能的。
典型的用法是，在GUI后面，做一些后台操作；多线程网络操作；后台监控某个事件；队列操作等 。

Python 多线程效率不高吗？

Python效率到底高不高？到底是不是鸡肋？Python由于有全锁局的存在（同一时间只能有一个线程执行），并不能利用多核优势。所以，如果你的多线程进程是CPU密集型的，那多线程并不能带来效率上的提升，相反还可能会因为线程的频繁切换，导致效率下降；如果是IO密集型，多线程进程可以利用IO阻塞等待时的空闲时间执行其他线程，提升效率。
多线程，是指从软件或者硬件上实现多个线程并发执行的技术。想要了解不同的线程是怎样运作的，要知道不同线程同时访问资源时，需要使用保护机制，Python中使用GIL（解释器全局锁）。直观上，这是一个加在解释器上的全局（从解释器的角度看）锁。这意味着对于任何Python程序，不管有多少的处理器，任何时候都总是只有一个线程在执行。所以，如果没有IO操作，python中的多线程比单线程效率还低。
根据我同学的说法，如果你只是想做个定时器样的简单东西，对稳定性要求低些，如vb,c#类似的定时器，用多线程吧，但线程的同步要注意了。python的线程更加类似定时器，python的线程不是真线程，但有的场合用这种定时器也能解决很多问题，因为开销小，开启也方便。但是如果你不是这种想法，你可能很难理解。
虽然CPython的线程库直接封装了系统的原生线程，但CPython整体作为一个进程，同一时间只会有一个获得GIL的线程在跑，其他线程则处于等待状态。这就造成了即使在多核CPU中，多线程也只是做着分时切换而已。

为什么在Python里推荐使用多进程而不是多线程

首先强调背景：
1. GIL是什么？
GIL的全称是Global Interpreter Lock(全局解释器锁)，来源是python设计之初的考虑，为了数据安全所做的决定。
2. 每个CPU在同一时间只能执行一个线程
在单核CPU下的多线程其实都只是并发，不是并行，并发和并行从宏观上来讲都是同时处理多路请求的概念。但并发和并行又有区别，并行是指两个或者多个事件在同一时刻发生；而并发是指两个或多个事件在同一时间间隔内发生。
在Python多线程下，每个线程的执行方式：
获取GIL
执行代码直到sleep或者是python虚拟机将其挂起。
释放GIL
可见，某个线程想要执行，必须先拿到GIL，我们可以把GIL看作是“通行证”，并且在一个python进程中，GIL只有一个。拿不到通行证的线程，就不允许进入CPU执行。
在Python2.x里，GIL的释放逻辑是当前线程遇见IO操作或者ticks计数达到100（ticks可以看作是Python自身的一个计数器，专门作用于GIL，每次释放后归零，这个计数可以通过 sys.setcheckinterval 来调整），进行释放。
而每次释放GIL锁，线程进行锁竞争、切换线程，会消耗资源。并且由于GIL锁存在，python里一个进程永远只能同时执行一个线程(拿到GIL的线程才能执行)，这就是为什么在多核CPU上，python的多线程效率并不高。
那么是不是python的多线程就完全没用了呢？
在这里我们进行分类讨论：
CPU密集型代码(各种循环处理、计数等等)，在这种情况下，由于计算工作多，ticks计数很快就会达到阈值，然后触发GIL的释放与再竞争（多个线程来回切换当然是需要消耗资源的），所以python下的多线程对CPU密集型代码并不友好。
IO密集型代码(文件处理、网络爬虫等)，多线程能够有效提升效率(单线程下有IO操作会进行IO等待，造成不必要的时间浪费，而开启多线程能在线程A等待时，自动切换到线程B，可以不浪费CPU的资源，从而能提升程序执行效率)。所以python的多线程对IO密集型代码比较友好。
而在python3.x中，GIL不使用ticks计数，改为使用计时器（执行时间达到阈值后，当前线程释放GIL），这样对CPU密集型程序更加友好，但依然没有解决GIL导致的同一时间只能执行一个线程的问题，所以效率依然不尽如人意。
请注意：多核多线程比单核多线程更差，原因是单核下的多线程，每次释放GIL，唤醒的那个线程都能获取到GIL锁，所以能够无缝执行，但多核下，CPU0释放GIL后，其他CPU上的线程都会进行竞争，但GIL可能会马上又被CPU0拿到，导致其他几个CPU上被唤醒后的线程会醒着等待到切换时间后又进入待调度状态，这样会造成线程颠簸(thrashing)，导致效率更低。
回到最开始的问题：经常我们会听到老手说：“python下想要充分利用多核CPU，就用多进程”，原因是什么呢？
原因是：每个进程有各自独立的GIL，互不干扰，这样就可以真正意义上的并行执行，所以在python中，多进程的执行效率优于多线程(仅仅针对多核CPU而言)。
所以在这里说结论：多核下，想做并行提升效率，比较通用的方法是使用多进程，能够有效提高执行效率

有没有朋友们进来聊聊python的多线程和多进程

python的多线程和多进程
差不多是这样子。多线程目前仅用于网络多线程采集， 以及性能测试。
其它的语言也有类似的情况，线程本身的特点导致线程的适用范围是受限的。只有CPU过剩，而其它的任务很慢，此时用线程才是有益的，可以很好平衡等待时间，提高并发性能。
线程的问题主要是线程的安全稳定性。线程无法强制中止，同时线程与主进程共享内存，可能会影响主进程的内存管理。
在python里线程出问题，可能会导致主进程崩溃。 虽然python里的线程是操作系统的真实线程。
那么怎么解决呢？通过我们用进程方式。子进程崩溃后，会完全的释放所有的内存和错误状态。所以进程更安全。 另外通过进程，python可以很好的绕过GIL，这个全局锁问题。
但是进程也是有局限的。不要建立超过CPU总核数的进程，否则效率也不高。
简单的总结一下。
当我们想实现多任务处理时，首先要想到使用multiprocessing， 但是如果觉着进程太笨重，那么就要考虑使用线程。 如果多任务处理中需要处理的太多了，可以考虑多进程，每个进程再采用多线程。如果还处理不要，就要使用轮询模式，比如使用poll event, twisted等方式。如果是GUI方式，则要通过事件机制，或者是消息机制处理，GUI使用单线程。
所以在python里线程不要盲目用， 也不要滥用。 但是线程不安全是事实。如果仅仅是做几个后台任务，则可以考虑使用守护线程做。如果需要做一些危险操作，可能会崩溃的，就用子进程去做。 如果需要高度稳定性，同时并发数又不高的服务。则强烈建议用多进程的multiprocessing模块实现。
在linux或者是unix里，进程的使用代价没有windows高。还是可以接受的。

python多进程和多线程究竟谁更快

你要知道一点python的多线程是伪多线程，对于io密集型代码，效果还好。
但是python多进程是充分利用cpu的
不存在谁更快，看怎么搭配使用