Python中concurrent.futures与multiprocessing.dummy线程池有何区别

核心结论 #

两者不存在“一个把任务分发到多系统线程、另一个把所有任务塞到单线程串行执行”的本质区别：无论使用哪一种实现，提交的任务最终都会被投递到多个独立的系统工作线程上，由操作系统完成跨CPU核心的调度，完全不存在你担心的concurrent.futures.ThreadPoolExecutor将所有提交任务调度到单个CPU线程串行运行的情况。
你提到的公开技术文章中描述的“ThreadPool将任务分发到不同系统线程执行”的逻辑，和concurrent.futures.ThreadPoolExecutor的核心调度方向是完全一致的。

两类实现的具体差异 #

• 设计定位差异
  • multiprocessing.dummy模块提供的ThreadPool，本质是multiprocessing模块为了降低多线程、多进程代码切换成本做的兼容封装，API完全对标同模块下的多进程池ProcessPool，提供apply、apply_async、map、imap等经典方法，设计初衷是让用户可以仅通过修改导入语句，就能把原本基于多进程的IO密集型任务快速切换为多线程实现，减少进程创建和跨进程通信的开销。
  • concurrent.futures.ThreadPoolExecutor是Python3.2版本开始引入的统一执行器抽象的组成部分，配套submit、map、shutdown等方法，通过返回的Future对象封装所有任务的执行状态、返回值、异常信息，支持灵活的任务回调绑定、超时控制、状态查询，是Python官方当前主推的线程池实现。
• 调度细节差异
  • multiprocessing.dummy的ThreadPool会在实例初始化时就按照指定的工作线程数一次性创建所有工作线程，任务分发采用固定轮询的方式把待执行任务投递到对应线程的专属队列，没有全局负载均衡机制，容易出现单个线程积压大量任务、其余线程空闲的负载倾斜问题。
  • concurrent.futures.ThreadPoolExecutor同样会按照max_workers参数创建对应数量的工作线程，但所有工作线程共享同一个全局任务队列，空闲线程会主动从队列拉取待执行任务执行，不存在固定分发的倾斜问题，任务调度的负载均衡能力更强。

常见认知误区澄清 #

很多人会把GIL对Python多线程的限制和“单线程调度”混淆：

Python解释器的全局解释锁（GIL）会限制同一时刻只有一个线程能执行Python字节码，导致CPU密集型任务无法通过多线程实现真正的多核并行。但这个限制是解释器层面的行为，和线程池的调度逻辑无关：不管用哪一种线程池实现，都会创建多个独立的系统线程，只是在执行纯Python计算逻辑时，这些线程会通过竞争GIL串行执行；在执行网络请求、文件读写等IO操作时，线程会主动释放GIL，实现真正的并行IO执行。

内容的提问来源于stack exchange，提问作者maximilian machiavelli