SharedMemory 比 Queue 快 10 倍的根本原因是零拷贝和无序列化：Queue 需经序列化、管道写入、管道读取、反序列化四步，而 SharedMemory 让进程直接读写同一物理内存，延迟接近本地数组访问。

SharedMemory 为什么比 Queue 快 10 倍？

根本原因不是 SharedMemory “本身快”，而是它绕过了 pickle 序列化和多次内存拷贝。Queue 的每个 put() 都要走「序列化 → 写管道 → 读管道 → 反序列化」四步，数据越大、越频繁，开销越爆炸；SharedMemory 让所有进程直接读写同一块物理内存，零拷贝、无序列化，延迟直逼本地数组访问。

SharedMemory 读写慢的真相：你可能没用对

如果你发现 SharedMemory 读写反而比 Array 还慢，大概率是踩了这些坑：

• 往 shm.buf 里直接塞 dict 或 list —— 这会触发隐式 pickle，和用 Queue 没区别
• 反复调用 np.frombuffer(shm.buf, dtype=...) —— 它可能返回只读副本或非连续视图，导致写入失败或性能抖动
• 没复用 memoryview 或 ndarray 视图，每次读写都重建缓冲区对象
• 在循环里反复 shm.buf[i] 单字节访问 —— 缺少批处理，CPU cache 友好度极差

numpy.ndarray + SharedMemory 初始化报错常见原因

ValueError: buffer size mismatch 或 BufferError: memoryview is not contiguous 几乎都源于 shape/dtype/size 三者没对齐：

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

• 必须确保：shm.size == np.prod(shape) * dtype.itemsize，一个字节都不能差
• 构造视图必须用 np.ndarray(shape=..., dtype=..., buffer=shm.buf)，别用 np.frombuffer()
• 子进程 attach 后，必须用完全相同的 name、shape、dtype 重建 ndarray，否则底层内存解释错位
• Windows 下 name 区分大小写，Linux 不区分；跨平台部署统一用小写，比如 "shm_data"

多进程同时写 SharedMemory 会卡死吗？

不会卡死，但会脏写、覆盖、数据错乱——SharedMemory 本身 不带任何同步机制，它就是一块裸内存。

立即学习“Python免费学习笔记（深入）”；

• 纯读场景（1 写 N 读）可完全无锁，性能最优
• 有写操作时，必须配 multiprocessing.Lock 或 Semaphore，且锁粒度要细：比如按数组行、块加锁，而不是整个 shm 一把锁
• 锁内禁止做 IO、sleep、复杂计算，否则其他进程阻塞时间不可控
• 忘记调用 shm.close() 和 shm.unlink() 会导致系统级共享内存泄漏，重启前一直占着

真正难的不是创建共享内存，而是让多个进程在不互相破坏的前提下，高效、确定性地读写同一块地址空间。这要求你亲手设计内存布局、显式管理同步、严格校验类型对齐——它把控制权交还给你，也把责任一起交了过来。