shared_memory 创建后进程退出不会自动销毁，必须显式调用 close() 和 unlink() 清理，否则残留；它不提供同步机制，需配合 Lock 等使用；相比 multiprocessing.Array，它更底层、跨语言、高性能但需手动管理。
shared_memory 创建后进程退出就自动销毁吗
不销毁，但必须手动清理，否则变成系统级残留。Python 的 shared_memory.SharedMemory 底层绑定的是 POSIX 共享内存对象（Linux/macOS）或 Windows 内存映射文件，操作系统不会因为创建它的 Python 进程退出就自动释放——尤其当其他进程还在 attach 时。
常见错误现象：OSError: [Errno 17] File exists，反复运行脚本失败；df -h /dev/shm 显示占用持续增长；用 ipcs -m 能查到大量“dest”状态的段。
- 必须显式调用
shm.close()+shm.unlink()，且unlink()只能由创建者调用一次 - 子进程不能调用
unlink()，否则主进程再访问会报FileNotFoundError - 程序异常退出时，
unlink()很可能没执行，建议用atexit.register()或try/finally包裹
多个进程怎么安全读写同一块 shared_memory
shared_memory 本身不提供任何同步机制，读写冲突完全靠你自己控制。它只是把一块内存地址暴露出来，像裸指针一样危险。
使用场景：高频小数据交换（如图像帧、传感器采样），且你已有明确的读写节奏（比如生产者-消费者模型中，写完才通知读）。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 不要直接对
shm.buf做并发赋值，例如shm.buf[:4] = b''在多线程/多进程下非原子 - 推荐搭配
multiprocessing.Semaphore或multiprocessing.Lock使用，锁对象也得用shared_memory外的方式传递（比如父进程创建后传给子进程） - 如果只是单写多读，且写操作是整块覆盖（不是部分更新），可以靠约定顺序规避锁，但需确保写入完成后再更新一个标志位（该标志位也得在共享内存里，且用
struct.pack写入）
shared_memory 和 multiprocessing.Array / Value 有什么区别
shared_memory 是底层裸内存，Array 和 Value 是带类型封装的高层接口。前者灵活但易错，后者省心但有额外开销和限制。
参数差异明显：Array('i', 100) 固定为 C 类型数组，长度写死；SharedMemory 创建时只指定字节数，后续怎么解释全由你决定（可用 numpy.frombuffer(shm.buf, dtype=np.int32)）。
-
Array自动管理生命周期，进程退出时由 multiprocessing 模块尝试清理；SharedMemory完全不托管 -
Array不支持跨语言（比如 Go 进程读取），SharedMemory的名字（name参数）是 OS 级字符串，C/Go 都能打开 - 性能上，
SharedMemory避开了Array的代理对象和类型检查，大数据量（>1MB）时 memcpy 开销更可控
Windows 下 shared_memory 报 FileNotFoundError 怎么办
Windows 对共享内存名有严格限制：不能含反斜杠、不能以空格开头、长度上限 260 字符，且必须全局唯一。最常踩的坑是名字用了路径风格（如 "myapp/data"）或随机数没做字符过滤。
错误信息典型是：FileNotFoundError: No such file or directory: 'psm_abc123'（注意前缀 psm_ 是 Python 自动加的）。
- 名字只能用 ASCII 字母、数字、下划线，且必须以字母或下划线开头
- 避免用
uuid.uuid4().hex直接当 name，因为 hex 可能以数字开头，Windows 拒绝；改成"shm_" + uuid.uuid4().hex - 调试时先用固定名字（如
"test123"），确认逻辑通了再换动态生成 - 用
dir \.Global??（管理员权限）或 Process Explorer 查看已存在的共享内存对象
