这个问题我之前也帮人排查过，本质是macOS系统特性和Python多进程队列底层实现的“小冲突”，咱们一步步拆解原因：

1. 先搞懂multiprocessing.Queue的底层逻辑 #

Python的multiprocessing.Queue在类Unix系统里，靠的是**管道（pipe）**加锁来实现进程间传数据：

• 你调用put()时，数据会先被pickle序列化，然后塞进管道的缓冲区；
• 消费进程调用get()时，再从管道里读出来反序列化。

你设置maxsize=0，Python层面确实会取消自己的容量限制，但它管不了操作系统给管道本身设的物理缓冲区大小——这才是卡死你的关键。

2. macOS的管道有个硬上限 #

macOS默认给管道的缓冲区大小是64KB，而且这个值是固定死的（早年是4KB，后来才升到64KB），没法像Linux那样动态扩容。

你测试的是整数，pickle序列化小整数（比如0到32767）大概占2字节左右，32768个刚好凑够32768*2=64KB——直接把管道缓冲区填满了！这时候再调用put()，操作系统就会让写入操作阻塞，必须等消费进程把数据取走、腾出空间才能继续。

3. 为什么Linux上就没问题？ #

Linux的管道缓冲区默认也是64KB，但它支持动态扩容（只要系统内存够，最大能扩到1MB甚至更大，取决于内核配置）。当缓冲区快满时，内核会自动给它加空间，所以你能一次性塞80万个元素也不卡。

4. 怎么验证和解决？ #

先验证一下 #

打开macOS终端，输入这个命令看管道缓冲区大小：

sysctl kern.pipe.buffer_size

输出肯定是kern.pipe.buffer_size: 65536（也就是64KB），实锤了。

解决思路给你几个 #

• 边写边消费：别一次性把所有元素都塞进Queue，先启动消费进程，再慢慢写，这样消费进程会不断取数据腾空间，就不会堵了；
• 换用共享内存版队列：用multiprocessing.Manager().Queue()，它是基于共享内存实现的，不受管道缓冲区限制，就是性能比原生Queue稍差一点；
• 临时改系统参数（不推荐）：用root权限把管道缓冲区调大，比如设成1MB，但可能影响其他系统进程的行为，谨慎用：

  sudo sysctl -w kern.pipe.buffer_size=1048576
  

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