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 本身 不带任何同步机制，它就是一块裸内存。
- 纯读场景（1 写 N 读）可完全无锁，性能最优
- 有写操作时，必须配
multiprocessing.Lock或Semaphore，且锁粒度要细：比如按数组行、块加锁，而不是整个shm一把锁 - 锁内禁止做 IO、sleep、复杂计算，否则其他进程阻塞时间不可控
- 忘记调用
shm.close()和shm.unlink()会导致系统级共享内存泄漏，重启前一直占着
真正难的不是创建共享内存，而是让多个进程在不互相破坏的前提下，高效、确定性地读写同一块地址空间。这要求你亲手设计内存布局、显式管理同步、严格校验类型对齐——它把控制权交还给你，也把责任一起交了过来。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
