为何Python中多进程读取multiprocessing.Queue比主进程读取更快？

你观察到的主进程读取multiprocessing.Queue耗时更长的现象，核心原因在于multiprocessing.Queue的底层实现机制，以及主进程与子进程在资源调度、同步开销上的差异：

1. multiprocessing.Queue的底层逻辑 #

在Unix-like系统中，multiprocessing.Queue基于管道（pipe）+后台线程（feeder thread）+同步锁实现：

• 调用put()时，数据先存入用户态缓冲区，由feeder线程异步写入管道；
• 调用get()时，从管道读取数据到用户态缓冲区，再返回给调用者。

2. 主进程读取的额外开销 #

当主进程自己执行读取操作时：

• 线程级资源竞争：主进程的读取逻辑与feeder线程同属一个进程空间，二者会竞争进程内的同步锁（比如维护队列状态的锁）。即使put()操作已完成，feeder线程的残留同步逻辑或线程调度延迟，会导致posix.read（管道读取的系统调用）需要等待线程切换，拉长了系统调用的执行时间。
• 进程内IO的额外同步：同一个进程内的管道读写会触发操作系统的缓存同步逻辑，相比跨进程的管道读写，posix.read需要处理更多的进程内资源协调，进一步增加了耗时。

3. 子进程读取的优势 #

子进程作为独立的进程空间：

• 与主进程的feeder线程不存在线程级的资源竞争，跨进程的管道读写由操作系统直接调度，避免了进程内线程切换的开销；
• 操作系统对跨进程管道IO的调度更高效，posix.read的执行延迟更低。

代码中的额外问题 #

你的代码里用while queue.qsize() > 0作为循环条件，再配合get(block=False)+异常捕获的方式，会放大性能差异：

• qsize()在多线程/多进程环境下不是原子操作，结果不可靠，可能导致空轮询或提前退出；
• 空轮询会产生大量无效的系统调用，主进程内的线程竞争会让这些无效调用的开销更明显。

优化建议 #

• 替换循环逻辑：导入queue.Empty，改用try-except捕获Empty异常的方式读取，避免依赖qsize()：

  from queue import Empty
  # ...
  def get_queue(queue):
      pr = cProfile.Profile()
      pr.enable()
      count = 0
      try:
          while True:
              queue.get(block=True, timeout=0.1)
              count +=1
      except Empty:
          pass
      print(f"读取了{count}个元素")
      # ... 后续profile逻辑
  

• 单进程读写场景可改用multiprocessing.SimpleQueue：它没有feeder线程，实现更轻量化，单进程读写时性能更优。

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