为什么在Python里介绍经常使用多进程而不是多线程 (为什么在pycharm中安装不了模块)
本文目录导航：
为什么在Python里介绍经常使用多进程而不是多线程
首先强调背景：
1. GIL是什么？
2. 每个CPU在同一时期只能口头一个线程
在单核CPU下的多线程其实都只是并发，不是并行，并发和并行从微观过去讲都是同时处置多路恳求的概念。
但并发和并行又有区别，并行是指两个或许多个事情在同一时辰出现；而并发是指两个或多个事情在同一时时期隔内出现。
在Python多线程下，每个线程的口头形式：
python多进程为什么必定要
前面讲了为什么Python里介绍用多进程而不是多线程，然而多进程也有其自己的限度：相比线程愈加轻便、切换耗时更长，并且在python的多进程下，进程数量不介绍超越CPU外围数（一个进程只要一个GIL，所以一个进程只能跑满一个CPU），由于一个进程占用一个CPU时能充沛应用机器的功能，然而进程多了就会出现频繁的进程切换，反而得失相当。
不过不凡状况（特指IO密集型义务）下，多线程是比多进程好用的。
举个例子：给你200W条url，须要你把每个url对应的页面抓取保管起来，这种时刻，单单经常使用多进程，成果必需是很差的。
为什么呢看例如每次恳求的期待时期是2秒，那么如下（疏忽cpu计算时期）：1、单进程+复线程：须要2秒*200W=400W秒==1111.11个小时==46.3天，这个速度显著是不能接受的2、单进程+多线程：例如咱们在这个进程中开了10个多线程，比1中能够优化10倍速度，也就是大概4.63天能够成功200W条抓取，请留意，这里的实践口头是：线程1遇见了阻塞，CPU切换到线程2去口头，遇见阻塞又切换到线程3等等，10个线程都阻塞后，这个进程就阻塞了，而直到某个线程阻塞成功后，这个进程能力继续口头，所以速度上优化大概能到10倍（这里疏忽了线程切换带来的开支，实践上的优化应该是不能到达10倍的），然而须要思考的是线程的切换也是有开支的，所以不能有限的启动多线程（开200W个线程必需是不靠谱的）3、多进程+多线程：这里就凶猛了，普通来说也有很多人用这个方法，多进程下，每个进程都能占一个cpu，而多线程从必定水平上绕过了阻塞的期待，所以比单进程下的多线程又更好使了，例如咱们开10个进程，每个进程里开20W个线程，口头的速度实践上是比单进程开200W个线程快10倍以上的（为什么是10倍以上而不是10倍，重要是cpu切换200W个线程的消耗必需比切换20W个进程大得多，思考到这部分开支，所以是10倍以上）。
还有更好的方法吗看答案是必需的，它就是：4、协程，经常使用它之前咱们先讲讲what/why/how（它是什么/为什么用它/怎样经常使用它）what：协程是一种用户级的轻量级线程。
协程领有自己的寄存器高低文和栈。
协程调度切换时，将寄存器高低文和栈保管到其余中央，在切回来的时刻，复原先前保管的寄存器高低文和栈。
因此：协程能保管上一次性调用时的形态（即一切部分形态的一个特定组合），每次环节重入时，就相当于进入上一次性调用的形态，换种说法：进入上一次性分开时所处逻辑流的位置。
在并发编程中，协程与线程相似，每个协程示意一个口头单元，有自己的本地数据，与其它协程共享全局数据和其它资源。
why：目前支谣言语基本上都选用了多线程作为并发设备，与线程关系的概念是抢占式多义务（Preemptive multitasking），而与协程关系的是单干式多义务。
不论是进程还是线程，每次阻塞、切换都须要堕入系统调用(system call)，先让CPU跑操作系统的调度程序，而后再由调度程序选择该跑哪一个进程(线程)。
而且由于抢占式调度口头顺序不可确定的特点，经常使用线程时须要十分小心肠处置同步疑问，而协程齐全不存在这个疑问（事情驱动和异步程序也有雷同的好处）。
由于协程是用户自己来编写调度逻辑的，对CPU来说，协程其实是复线程，所以CPU不用去思考怎样调度、切换高低文，这就省去了CPU的切换开支，所以协程在必定水平上又好于多线程。
how:python外面怎样经常使用协程看答案是经常使用gevent，经常使用方法：看这里经常使用协程，可以不受线程开支的限度，我尝试过一次性把20W条url放在单进程的协程里口头，齐全没疑问。
所以最介绍的方法，是多进程+协程（可以看作是每个进程里都是复线程，而这个复线程是协程化的）多进程+协程下，避开了CPU切换的开支，又能把多个CPU充沛应用起来，这种形式关于数据量较大的爬虫还有文件读写之类的效率优化是渺小的。
小例子：#-*- coding=utf-8 -*-import requestsfrom multiprocessing import Processimport geventfrom gevent import monkey; _all()import sysreload(sys)(utf8)def fetch(url):try:s = ()r = (url,timeout=1)#在这里抓取页面except Exception,e:print ereturn def process_start(tasks)(tasks)#经常使用协程来口头def task_start(filepath,flag = ):#每10W条url启动一个进程with open(filepath,r) as reader:#从给定的文件中读取urlurl = ()()task_list = []#这个list用于寄存协程义务i = 0 #计数器，记载参与了多少个url到协程队列while url!=:i += 1task_((fetch,url,queue))#每次读取出url，将义务参与到协程队列if i == flag:#必定数量的url就启动一个进程并口头p = Process(target=process_start,args=(task_list,))()task_list = [] #重置协程队列i = 0 #重置计数器url = ()()if task_list not []:#若分开循环后义务队列里还有url残余p = Process(target=process_start,args=(task_list,))#把残余的url全都放到最后这个进程来口头()if __name__ == __main__:task_start(./)#读取指定文件认真的同窗会发现：下面的例子中暗藏了一个疑问：进程的数量会随着url数量的参与而始终参与，咱们在这里不经常使用进程池来控制进程数量的要素是和gevent有抵触不能同时经常使用，然而有兴味的同窗可以钻研一下这个协程池。
另外还有一个疑问：每个进程处置的url是累积的而不是独立的，例如第一个进程会处置10W个，第二个进程会变成20W个，以此类推。
最后定位到疑问是()造成的疑问，有兴味的同窗可以钻研一下为什么会这样。
不过这个疑问的处置打算是：主进程只担任读取url而后写入到list中，在创立子进程的时刻间接把list传给子进程，由子进程自己去构建协程。
这样就不会出现累加的疑问
有没有好友们出去聊聊python的多线程和多进程
python的多线程和多进程差不多是这样子。
多线程目前仅用于网络多线程采集， 以及功能测试。
其它的言语也有相似的状况，线程自身的特点造成线程的实用范畴是受限的。
只要CPU过剩，而其它的义务很慢，此时用线程才是有益的，可以很好平衡期待时期，提高并发功能。
线程的疑问重要是线程的安保稳固性。
线程不可强迫停止，同时线程与主进程共享内存，或许会影响主进程的内存治理。
在python里线程出疑问，或许会造成主进程解体。
只管python里的线程是操作系统的实在线程。
那么怎样处置呢？经过咱们用进程形式。
子进程解体后，会齐全的监禁一切的内存和失误形态。
所以进程更安保。
另外经过进程，python可以很好的绕过GIL，这个全局锁疑问。
然而进程也是有局限的。
不要建设超越CPU总核数的进程，否则效率也不高。
便捷的总结一下。
当咱们想成功多义务处置时，首先要想到经常使用multiprocessing， 然而假设觉着进程太轻便，那么就要思考经常使用线程。
假设多义务处置中须要处置的太多了，可以思考多进程，每个进程再驳回多线程。
假设还处置不要，就要经常使用轮询形式，比如经常使用poll event, twisted等形式。
假设是GUI形式，则要经过事情机制，或许是信息机制处置，GUI经常使用复线程。
所以在python里线程不要自觉用， 也不要滥用。
然而线程不安保是理想。
假设仅仅是做几个后盾义务，则可以思考经常使用守护线程做。
假设须要做一些风险操作，或许会解体的，就用子进程去做。
假设须要高度稳固性，同时并发数又不高的服务。
则剧烈倡导用多进程的multiprocessing模块成功。
在linux或许是unix里，进程的经常使用代价没有windows高。
还是可以接受的。
phper