前言

Python在并行运算方面因为GIL（Global Interpreter Lock，全局解释器锁）而饱受诟病，认为Python的多线程其实是伪的，很鸡肋，这里就大致讲解下吧，
在Python的原始解释器CPython中存在着GIL，因此在解释执行Python代码时，会产生互斥锁来限制线程对共享资源的访问，直到解释器遇到I/O操作或者操作次数达到一定数目时才会释放GIL
所以有GIL效果就是：** 一个进程内同一时间只能允许一个线程进行运算 ** （这尼玛不就是单线程吗？）
至于为什么要有GIL？只能说这是个历史遗留问题了，人家发明Python的时候压根就没想到现在居然有多核CPU，甚至多CPU的电脑啊~
再至于为什么GIL没有被优化掉，总是有人家的考虑的，反正Python3也继续了GIL的优良传统，爱用不用，有兴趣的自行搜索GIL吧
我这里尽量用事实说话，直接黑盒测试下常见的几种并行运算方式

正文

测试环境：
电脑：

我的电脑

Python： 2.7.10

我都是使用 multiprocessing 模块进行对比，对比三种常见的使用情况，我分别取名（非官方）：ThreadPool,DummyPool,ProcessPool

引入方式如下：

from multiprocessing.pool import ThreadPool
from multiprocessing.dummy import Pool as DummyPool
from multiprocessing import Pool as ProcessPool

说明： ThreadPool,DummyPool 都是线程池，ProcessPool 是进程池

测试代码如下：

#!/usr/bin/env python
# -*- coding: utf-8 -*-
# by vellhe 2017/7/1

from multiprocessing.pool import ThreadPool
from multiprocessing.dummy import Pool as DummyPool
from multiprocessing import Pool as ProcessPool

import time

max_range = 10000000


def run(i):
    i = i * i
    # return i # return和不return对进程池运行速度会有比较大影响，不return效率更高


def thread_pool(num):
    p = ThreadPool(num)
    start_time = time.time()
    ret = p.map(run, range(max_range))
    p.close()
    p.join()
    print("thread_pool  %d, costTime: %fs ret.size: %d" % (num, (time.time() - start_time), len(ret)))


def dummy_pool(num):
    p = DummyPool(num)
    start_time = time.time()
    ret = p.map(run, range(max_range))
    p.close()
    p.join()
    print("dummy_pool   %d, costTime: %fs ret.size: %d" % (num, (time.time() - start_time), len(ret)))


def process_pool(num):
    p = ProcessPool(num)
    start_time = time.time()
    ret = p.map(run, range(max_range))
    p.close()
    p.join()
    print("process_pool %d, costTime: %fs ret.size: %d" % (num, (time.time() - start_time), len(ret)))


if __name__ == "__main__":
    for i in range(1, 9):
        thread_pool(i)
        dummy_pool(i)
        process_pool(i)
        print("=====")

测试说明：

通过并行计算max_range次对于i的二次方，没有任何IO操作，纯运算
这里特别说明，由于偶然发现run方法return和不return对ProcessPool会有很大影响，所以前后分别跑了两次

测试结果：

• 没有return:

  
  没有return
  

  从上图很容易得出以下结论：

  • thread_pool和dummy_pool运行速度几乎没有什么区别，因为都是线程池，而且从实现代码分析，其实dummy_pool就是thread_pool，只是套了一层壳而已
    

    DummyPool实现

  • 单线程运行速度比多线程要快，这就是因为python的GIL机制了，一个进程内同一时间只能允许一个线程进行运算，多线程只会让时间白白在线程间切换上了。
    这时有人会说，那python的多线程不就废了，要它何用？
    其实不然，这里只是做了纯运算的实验，没有任何IO，如果是高IO的话情况就不一样了，因为在等待IO完成时会去处理另外的线程，而IO往往耗时较高，所以在一些高IO情况下（如批量处理文件、网络请求、爬虫等）还是可以合理使用python的多线程的

  • 单进程运行比单线程慢，这个也能理解，毕竟开一个线程比开一个进程要简单得多，没有资源分配等乱七八糟的东西

  • 多进程比单进程运行快，这要是不快就奇怪了，毕竟多进程是分散在不同cpu核上跑的，这里和多线程比优势就很明显了，所以一些科学运算想要提升速度就会用多进程策略了

  • 当多进程数够多情况下会超越多线程的速度，原因很简单，多线程并不会因为线程数增多而变快，而多进程却可以，所以超越是必然的

• 有return:

  
  有return
  

  拿这张图对比上面没有return的那张就会发现一些有意思的事情：

  • 有return后单线程和多线程速度几乎一致了，但多进程还是比单进程要快很多，由于我电脑是4核的，所以还能大致看出，4个进程以后速度并没有提升了
  • 有return后总体运算速度都慢了，特别是进程的速度，慢了一倍，这里原因是进程间通信耗时较大，需要把结果return到主进程中，所以做大量运算时尽量避免进程间通信

测试存在IO操作的情况

上面都是纯运算，没有IO，接下来就看看存在IO操作会是什么样吧，代码如下，在循环计算前增加request请求

#!/usr/bin/env python
# -*- coding: utf-8 -*-
# by vellhe 2017/7/1
import time
from multiprocessing.pool import ThreadPool
from multiprocessing import Pool as ProcessPool
import requests

max_range = 50


def run(i):
    requests.get("http://www.qq.com")
    for x in range(10000):
        i += i * x
    return i


def thread_pool(num):
    p = ThreadPool(num)
    start_time = time.time()
    ret = p.map(run, range(max_range))
    p.close()
    p.join()
    print("thread_pool  %d, costTime: %fs ret.size: %d" % (num, (time.time() - start_time), len(ret)))


def process_pool(num):
    p = ProcessPool(num)
    start_time = time.time()
    ret = p.map(run, range(max_range))
    p.close()
    p.join()
    print("process_pool %d, costTime: %fs ret.size: %d" % (num, (time.time() - start_time), len(ret)))


if __name__ == "__main__":
    for i in range(1, 9):
        thread_pool(i)
        process_pool(i)
        print("=====")

测试结果：

IO操作结果

由上图可知:

• 存在IO操作的话，python的多线程才会有用武之地，有效提升了速度
• 存在IO情况下，多进程效率还是会比多线程高很多
• 进程和线程数都是在4个后速度没有再提升了，因为我电脑是4核的

继续追加实验，看看多进程和多线程下CPU使用情况

分别做了好几次实验，惊奇的发现个很神奇的事情，不管开多少个进程或者线程，每次cpu核占用情况都是大致如下：

cpu使用情况

结果并没有出现我想像中的，单进程是一个核占用暴涨，其它核都是休息状，我也解释不了为什么了，难道是multiprocessing有优化？还是系统层做了优化？所以再做了一个实验，没有用任何进程池，直接for循环计算：

#!/usr/bin/env python
# -*- coding: utf-8 -*-
# by vellhe 2017/7/1
import time

max_range = 100000000


def run(i):
    i = i * i
    return i


if __name__ == "__main__":
    start_time = time.time()
    for i in range(max_range):
        run(i)
    print("costTime: %fs" % (time.time() - start_time))

结果居然还是各个核的占用情况几乎是均匀的，所以几乎可以断定，这是系统层的优化了，所以先告一段落吧，以后再继续深究

后语

来个大致总结吧，针对python而言：

• 纯运算情况下单线程比多线程更快
• 多线程在IO操作较多情况下才能很好的发挥作用，但效率还是低于多进程
• 单进程运行比单线程慢，但当多进程数够多情况下会超越单线程的速度
• 多进程比单进程运行快
• 对于多进程而言，有return会比没有return慢很多很多，对于多线程却只会慢一点点
• 【疑惑】不管开多少个进程或者线程，各个核占用情况几乎是均匀的，猜测是系统底层有优化

ps：关于我的疑惑，知道明确结论的大侠们请给我留言，多谢