SharedMemory仅提供裸内存区域，不支持Python对象直接赋值，需用numpy等转为字节流；必须手动管理生命周期（close/unlink），否则内存泄漏；读写需自行加锁，且子进程须用相同shape/dtype重建ndarray视图。
共享内存不是万能的，SharedMemory 只负责分配一块可跨进程访问的裸内存区域，不带任何数据结构或同步机制——你得自己序列化、自己加锁、自己管理生命周期。
为什么直接传 list 或 dict 会报错？
因为 multiprocessing.shared_memory.SharedMemory 不理解 Python 对象，它只认字节流。试图把一个 list 直接赋给 shm.buf 会触发 TypeError: memoryview: a bytes-like object is required。
- 必须先用
struct、numpy或pickle（不推荐）把数据转成bytes或ndarray - 若用
numpy，需确保数组是 C-contiguous 且 dtype 明确（比如np.int32），否则写入可能静默失败 - 共享内存本身没有类型信息，子进程读取时必须用完全一致的 shape 和 dtype 重建视图
用 numpy + SharedMemory 共享数组最稳妥
这是目前最常用、性能最好、出错最少的方式。核心是让 numpy.ndarray 直接指向共享内存地址。
- 主进程创建
SharedMemory，大小按size = array.nbytes计算 - 用
np.ndarray(shape, dtype, buffer=shm.buf)构造视图，**不要用np.frombuffer(shm.buf, ...)**（后者可能返回只读副本） - 子进程用相同参数调用
SharedMemory(name=...)，再构造同 shape/dtype 的 ndarray 视图 - 修改后无需手动刷新——内存是实时可见的，但读写竞争需额外加
multiprocessing.Lock
示例（主进程）：
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
from multiprocessing import shared_memory, Process import numpy as np <p>shm = shared_memory.SharedMemory(create=True, size=1000 * 4) # int32 × 1000 arr = np.ndarray((1000,), dtype=np.int32, buffer=shm.buf) arr[:] = 42 # 写入</p><p>p = Process(target=worker, args=(shm.name,)) p.start() p.join()</p><p>shm.close() shm.unlink() # 必须显式释放</p>
shm.unlink() 忘了调用就泄露内存
这是最容易被忽略的致命点。unlink() 不是“删除”，而是标记该共享内存段在最后一个 close() 后自动销毁。如果某进程崩溃或提前退出，没调用 close()，那块内存会一直卡在系统里，直到机器重启。
- 务必在主进程用
try/finally包裹shm.close()和shm.unlink() - 子进程只需
shm.close()，绝不能调unlink()（否则主进程还没读完就被删了） - 调试时可用命令行查残留：
ipcs -m（Linux/macOS）或任务管理器→性能→资源共享（Windows） - 名字冲突也危险：
SharedMemory(create=True, name="mydata")若已存在会抛FileExistsError，建议用shared_memory.ShareableList或随机名
真正麻烦的从来不是怎么写进去，而是谁在什么时候关、谁负责清、数据边界有没有越界——这些都得手写逻辑兜住。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
