multiprocessing.Queue适合父-子进程间传小到中等对象，基于pipe+pickle；Pipe更快但仅双端单向；Value/Array用于基础类型共享内存；Event仅作状态通知，不传数据。
用 multiprocessing.Queue 传数据最直接，但别跨进程多次 get()
它底层基于管道（pipe）+ 序列化（pickle），适合在父进程和子进程之间传递小到中等体积的对象。常见错误是多个子进程都从同一个 Queue 里反复 get() 却没判空，导致阻塞或 Empty 异常。
- 只在创建它的进程及其派生子进程中使用，不能用于任意两个独立进程
-
put()和get()默认阻塞，加timeout=1可防卡死 - 对象必须可被
pickle，lambda、嵌套函数、带绑定方法的实例都不行 - 大量高频小数据（如每毫秒一次）会因序列化开销拖慢性能，此时考虑
multiprocessing.Pipe
multiprocessing.Pipe 更快但只能双端通信
返回一对连接对象（(conn1, conn2)），一端发、另一端收，不经过序列化（仅对内置类型自动处理），比 Queue 轻量。但它天生是单向或半双工的，且不能被 fork 多次后复用 —— 每个子进程得拿到专属的一端。
- 若需多对一通信（比如多个 worker 向主进程上报结果），得让每个 worker 持有自己独占的
conn2，主进程用多个conn1分别接收 - 调用
conn.recv()前建议先用conn.poll(timeout)判断是否有数据，避免死等 - 不可在非创建它的线程中调用
recv()或send()，会报OSError: Bad file descriptor
共享内存用 multiprocessing.Value 和 multiprocessing.Array，但只支持基础类型
它们映射到系统共享内存段，绕过序列化，适合高频读写标量或固定长度数组（如计数器、状态标志、图像 buffer）。但不支持 list、dict、自定义类等动态结构。
-
Value('i', 0)中的'i'是 ctypes 类型码，不是 Python 类型；写错（如用'int'）会静默失败或崩溃 - 多个进程同时写同一
Value时不会自动加锁，必须显式用Lock包裹读写块 -
Array('d', [1.0, 2.0])创建的是只读副本？不对 —— 它是可写的，但初始化值只在创建时拷贝一次，后续修改不自动同步到其他进程的视图里（因为是共享内存，改了就真改了）
跨进程信号用 multiprocessing.Event，但别指望它传数据
本质是包装了系统级事件对象（如 POSIX semaphores），用来做“通知”：一个进程 set()，其他进程 wait() 返回。它不携带任何 payload，纯状态同步。
立即学习“Python免费学习笔记（深入）”；
- 不能用
Event替代Queue来传递消息，有人误以为event.set()后能顺带塞个值进去，实际不行 -
wait()可设超时，返回True/False表示是否等到，别忽略返回值直接假设已触发 - 父子进程间传递
Event对象本身没问题，但不要在子进程里重新Event()一个同名变量覆盖掉传入的那个
Value 做运行标志，Pipe 传关键指令，Queue 塞日志行。没人规定只能选一种。 
