SharedMemory + numpy.ndarray 视图可绕过pickle实现纳秒级IPC，但需严格匹配shape/dtype、显式unlink释放资源，并配合Lock等同步机制避免竞态。
直接用 SharedMemory + numpy.ndarray 视图，能绕过 pickle 序列化，把 IPC 开销从毫秒级压到纳秒级读写——前提是数据结构固定、进程间约定好 shape 和 dtype。
共享内存必须显式 unlink 才会真正释放
很多人以为进程退出就自动清理，其实不会。SharedMemory 对象只是映射，系统级共享内存段（如 Linux 的 /dev/shm/my_shm）一直残留，直到调用 .unlink()。不 unlink 会导致：
- 多次运行脚本后出现
FileExistsError: [Errno 17] File exists -
shm_open失败，或df -h /dev/shm显示空间被占满 - 后续进程连不上同名内存段，报
FileNotFoundError
正确做法：仅创建者调用 .unlink()，且应在 finally 或 atexit 中确保执行；其他进程只调用 .close()。
NumPy 数组视图必须严格匹配 shape/dtype 才能复用内存
shm.buf 是 raw memoryview，本身不含类型信息。如果 writer 写的是 np.float64、shape=(1000,)，但 reader 用 np.int32 + shape=(2000,) 去解释，结果就是内存错位、数值乱码，甚至 segfault。
立即学习“Python免费学习笔记（深入）”；
- 务必在进程启动前，通过参数或配置统一传递
shape和dtype - 推荐用
np.dtype(dtype).itemsize * np.prod(shape)算出size，避免手动算错 - 调试时可用
bytes(shm.buf[:8])查看前 8 字节原始内容，验证写入是否生效
多进程读写同一块内存必须加同步机制
SharedMemory 本身不提供原子性或锁。两个进程同时写 shared_arr[0]，大概率丢失一次更新；reader 在 writer 正拷贝中间读，会拿到半截脏数据。
- 简单场景可用
multiprocessing.Barrier控制阶段同步（如“全部写完再一起读”） - 需要细粒度控制时，搭配
multiprocessing.Semaphore或multiprocessing.Lock，注意 lock 必须也放在共享内存里或单独创建 - 不要依赖“先写后读”的时间顺序——CPU 重排、缓存不一致会让它不可靠
最易被忽略的一点：共享内存只解决数据搬运问题，不解决逻辑竞态。哪怕 memcpy 零开销，没对齐的读写顺序或缺失的同步原语，照样导致结果不可复现。
