说明
进程：是操作系统进行资源分配的最小单元，资源包括CPU、内存、磁盘等IO设备等等
线程：是CPU调度的基本单位。
进程：系统分配资源的载体，是程序运行的实例；
线程：程序执行的最小单元，是进程中的一个实体用来执行程序，一个进程中有多个线程。
为什么有人说 Python 多线程是鸡肋？
在我们常识中，多进程、多线程都是通过并发的方式充分利用硬件资源提高程序的运行效率，怎么在 Python 中反而成了鸡肋？
因为 Python 中臭名昭著的 GIL。
那么 GIL 是什么？为什么会有 GIL？多线程真的是鸡肋吗？ GIL 可以去掉吗？
多线程是不是鸡肋：
做个实验：
将数字 “1亿” 递减，减到 0 程序就终止，这个任务如果我们使用单线程来执行，完成时间会是多少？
单线程，4核 CPU 计算机中，单线程所花的时间是 6.5 秒。
多线程创建两个子线程 t1、t2，每个线程各执行 5 千万次减操作，两个线程以合作的方式执行是 6.8 秒，反而变慢了。
按理来说，两个线程同时并行地运行，时间应该不减反增。原因就在于 GIL ，
在Python多线程下，每个线程的执行方式：
1.获取GIL
2.执行代码直到sleep或者是python虚拟机将其挂起。
3.释放GIL
可见，某个线程想要执行，必须先拿到GIL，我们可以把GIL看作是“通行证”，并且在一个python进程中，GIL只有一个。拿不到通行证的线程，就不允许进入CPU执行。
在 Cpython 解释器（Python语言的主流解释器）中，有一把全局解释锁（Global Interpreter Lock），在解释器解释执行 Python 代码时，先要得到这把锁，意味着，任何时候只可能有一个线程在执行代码，其它线程要想获得 CPU 执行代码指令，就必须先获得这把锁，如果锁被其它线程占用了，那么该线程就只能等待，直到占有该锁的线程释放锁才有执行代码指令的可能。
同一时刻，只有一个线程在运行，其它线程只能等待，即使是多核CPU，也没办法让多个线程「并行」地同时执行代码，只能是交替执行，因为多线程涉及到上线文切换、锁机制处理（获取锁，释放锁等），所以，多线程执行不快反慢。
什么时候 GIL 被释放呢？
当一个线程遇到 I/O 任务时，将释放GIL。计算密集型（CPU-bound）线程执行 100 次解释器的计步（ticks）时（计步可粗略看作 Python 虚拟机的指令），也会释放 GIL。
可以通过设置计步长度，查看计步长度。相比单线程，这些多是多线程带来的额外开销。
CPython 解释器为什么要这样设计？多线程有个问题，怎么解决共享数据的同步、一致性问题，因为，对于多个线程访问共享数据时，可能有两个线程同时修改一个数据情况，如果没有合适的机制保证数据的一致性，那么程序最终导致异常，所以，Python之父就搞了个全局的线程锁，不管你数据有没有同步问题，反正一刀切，上个全局锁，保证数据安全。这也就是多线程鸡肋的原因，因为它没有细粒度的控制数据的安全，而是用一种简单粗暴的方式来解决。
这种解决办法放在90年代，其实是没什么问题的，毕竟，那时候的硬件配置还很简陋，单核 CPU 还是主流，多线程的应用场景也不多，大部分时候还是以单线程的方式运行，单线程不要涉及线程的上下文切换，效率反而比多线程更高（在多核环境下，不适用此规则）。
所以，采用 GIL 的方式来保证数据的一致性和安全，未必不可取，至少在当时是一种成本很低的实现方式。那么把 GIL 去掉可行吗？还真有人这么干多，但是结果令人失望，在1999年Greg Stein 和Mark Hammond 两位哥们就创建了一个去掉 GIL 的 Python 分支，在所有可变数据结构上把 GIL 替换为更为细粒度的锁。然而，做过了基准测试之后，去掉GIL的 Python 在单线程条件下执行效率将近慢了2倍。
Python之父表示：基于以上的考虑，去掉GIL没有太大的价值而不必花太多精力。小结CPython解释器提供 GIL 保证线程数据同步，那么有了 GIL，我们还需要线程同步吗？多线程在 IO 密集型任务中，表现又是怎样呢？欢迎大家留言。
python的多线程到底有没有用？
1、CPU密集型代码(各种循环处理、计数等等)，在这种情况下，ticks计数很快就会达到阈值，然后触发GIL的释放与再竞争（多个线程来回切换当然是需要消耗资源的），所以python下的多线程对CPU密集型代码并不友好。
2、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而言)。
所以在这里说结论：多核下，想做并行提升效率，比较通用的方法是使用多进程，能够有效提高执行效率
话说回来，CPU密集型的程序用python来做，本身就不合适。跟C，Go，Java的速度比，实在性能差到没法说。你当然可以写个C扩展来实现真正的多线程，用python来调用，那样速度是快。我们之所以用python来做，只是因为开发效率超高，可以快速实现。
最后补充几点：
- python中要想利用好CPU，还是用多进程来做吧。或者，可以使用协程。multiprocessing和gevent在召唤你。
- GIL不是bug，Guido也不是水平有限才留下这么个东西。龟叔曾经说过，尝试不用GIL而用其他的方式来做线程安全，结果python语言整体效率又下降了一倍，权衡利弊，GIL是最好的选择——不是去不掉，而是故意留着的。
- 想让python计算速度快起来，又不想写C？用pypy吧，这才是真正的大杀器。
不适合用多线程的情况下用多进程还是协程提高并发能力？
一、多进程能够更好的利用多核CPU。
但是多进程也有其自己的限制：相比线程更加笨重、切换耗时更长，并且在python的多进程下，进程数量不推荐超过CPU核心数（一个进程只有一个GIL，所以一个进程只能跑满一个CPU），因为一个进程占用一个CPU时能充分利用机器的性能，但是进程多了就会出现频繁的进程切换，反而得不偿失。
所以多核的情况下，考虑线程数与 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 requests
from multiprocessing import Process
import gevent
from gevent import monkey; monkey.patch_all()
import sys
reload(sys)
sys.setdefaultencoding('utf8')
def fetch(url):
try:
s = requests.Session()
r = s.get(url,timeout=1)#在这里抓取页面
except Exception,e:
print e
return ''
def process_start(url_list):
tasks = []
for url in url_list:
tasks.append(gevent.spawn(fetch,url))
gevent.joinall(tasks)#使用协程来执行
def task_start(filepath,flag = 100000):#每10W条url启动一个进程
with open(filepath,'r') as reader:#从给定的文件中读取url
url = reader.readline().strip()
url_list = []#这个list用于存放协程任务
i = 0 #计数器，记录添加了多少个url到协程队列
while url!='':
i += 1
url_list.append(url)#每次读取出url，将url添加到队列
if i == flag:#一定数量的url就启动一个进程并执行
p = Process(target=process_start,args=(url_list,))
p.start()
url_list = [] #重置url队列
i = 0 #重置计数器
url = reader.readline().strip()
if url_list not []:#若退出循环后任务队列里还有url剩余
p = Process(target=process_start,args=(url_list,))#把剩余的url全都放到最后这个进程来执行
p.start()
if __name__ == '__main__':
task_start('./testData.txt')#读取指定文件
细心的同学会发现：上面的例子中隐藏了一个问题：进程的数量会随着url数量的增加而不断增加，我们在这里不使用进程池multiprocessing.Pool来控制进程数量的原因是multiprocessing.Pool和gevent有冲突不能同时使用，但是有兴趣的同学可以研究一下gevent.pool这个协程池。