multiprocessing.Pipe 看起来像“进程间直接传对象”，但它本质上依赖 pickle 序列化。

一旦传输复杂对象，就会出现很多容易忽略的问题。

下面是几个最常见、最坑的陷阱。

1. 以为传的是“共享对象”

很多人第一次用 Pipe 时，会误以为子进程修改对象会影响父进程。

实际上：

Pipe.send(obj)

会先 pickle

子进程收到的是“反序列化后的副本”

例如：

from multiprocessing import Process, Pipe

def worker(conn):

data = conn.recv()

data["count"] += 1

print("子进程:", data)

parent_conn, child_conn = Pipe()

p = Process(target=worker, args=(child_conn,))

p.start()

obj = {"count": 1}

parent_conn.send(obj)

p.join()

print("父进程:", obj)

输出：

子进程: {'count': 2}

父进程: {'count': 1}

因为根本不是同一个对象。

2. 巨大对象导致性能灾难

Pipe 发送大型对象时：

要 pickle

要复制内存

要 IPC 传输

接收端再 unpickle

比如发送：

超大 list

numpy 大数组

pandas DataFrame

图片数据

会非常慢。

例如：

big = list(range(10_000_000))

conn.send(big)

这里会：

序列化千万整数

拷贝数据

管道发送

再次构建对象

CPU 和内存直接暴涨。

3. 某些对象根本不能传

很多复杂对象无法 pickle：

线程锁

文件句柄

socket

数据库连接

Selenium driver

lambda

generator

例如：

import threading

from multiprocessing import Pipe

lock = threading.Lock()

parent, child = Pipe()

parent.send(lock)

直接报错：

TypeError: cannot pickle '_thread.lock' object

4. 类实例“看起来能传”，实际状态丢失

很多类对象虽然能 pickle。

但：

动态属性

C扩展状态

缓存

打开的资源

可能全部丢失。

例如：

class Test:

def __init__(self):

self.func = lambda x: x + 1

obj = Test()

发送：

conn.send(obj)

会报：

AttributeError: Can't pickle local object

因为 lambda 无法序列化。

5. Windows 下的“无限递归创建进程”

Windows 的 multiprocessing 默认是 spawn。

如果你忘记：

if __name__ == "__main__":

复杂对象初始化时会反复创建子进程。

例如：

from multiprocessing import Process

def worker():

print("hello")

p = Process(target=worker)

p.start()

Windows 下可能疯狂递归启动。

正确写法：

if __name__ == "__main__":

p = Process(target=worker)

p.start()

6. Pipe 不是无限缓冲区

很多人以为：

conn.send(big_data)

一定立即返回。

实际上：

Pipe 底层有缓冲区

缓冲区满了会阻塞

如果另一端不 recv()：

进程可能直接卡死。

典型死锁：

parent.send(huge_data)

parent.send(huge_data2)

但子进程没及时接收。

7. 双向 Pipe 容易互锁

默认：

parent, child = Pipe()

是双向的。

如果双方都：

send()

recv()

可能同时阻塞。

例如：

父进程：

conn.send("A")

conn.recv()

子进程：

conn.send("B")

conn.recv()

大对象时特别容易卡。

8. Queue 和 Pipe 的行为差异

很多人以为：

Queue == Pipe

实际上差别很大。

Queue：

内部有 feeder thread

更安全

多生产者友好

Pipe：

更底层

更快

但更容易死锁

复杂对象大量传输时：

Queue 往往更稳定。

9. pickle 版本兼容问题

如果：

不同 Python 版本

不同协议

自定义类路径变化

可能无法反序列化。

例如：

ModuleNotFoundError

特别是：

热更新

动态导入

Jupyter

临时脚本

里非常常见。

10. “看起来没问题”但内存翻倍

例如：

big = [0] * 100_000_000

conn.send(big)

很多人以为只占一次内存。

实际上：

原对象一份

pickle buffer 一份

子进程解包后一份

可能瞬间 3 倍内存。

大型数据会直接 OOM。

更安全的替代方案

如果数据很大：

推荐：

multiprocessing.shared_memory

Array

Value

mmap

Redis

ZeroMQ

PyArrow Plasma

而不是疯狂 Pipe.send() 大对象。

一个经典误区

很多人这样写：

driver = webdriver.Chrome()

Process(target=worker, args=(driver,))

这是错的。

Selenium driver：

包含 socket

包含线程

包含系统句柄

根本不能安全 pickle。

正确做法：

子进程内部自己创建 driver。

总结

multiprocessing.Pipe 最大的问题：

它让人误以为：

“进程之间在直接传对象”

实际上：

传的是 pickle 后的数据副本。

复杂对象一多：

性能问题

内存问题

死锁问题

pickle 崩溃

状态丢失

都会开始出现。

multiprocessing 管道传输复杂对象的陷阱