multiprocessing.Value和Array轻量安全但仅支持固定大小基础类型；真正零拷贝需用shared_memory模块配同步原语，避免越界、脏读与内存泄漏。
直接用 multiprocessing.Value 或 multiprocessing.Array 是最轻量、最安全的起点，但它们只支持基础类型且无法动态扩容；真要避开 IPC 开销，必须绕过序列化和管道，用操作系统原生共享内存机制——比如 shared_memory 模块（Python 3.8+）或 posix_ipc（Linux/macOS），否则你写的“共享”本质上还是在拷贝数据。
用 shared_memory 模块写入/读取原始字节
这是 Python 标准库中唯一真正跨进程映射同一块物理内存的方式，不依赖 pickle，也不走管道。关键点不是“能共享”，而是“怎么保证读写不越界、不覆盖、不读到脏数据”：
-
SharedMemory创建后，必须显式调用.close()和.unlink()，否则内存段会残留，下次运行报FileExistsError - 写入前必须用
struct.pack_into或memoryview明确指定偏移和长度，不能直接buffer[:] = data—— 否则可能覆盖 header 或其他进程正在读的区域 - 读取端必须等写入端明确写完（比如用信号量通知），不能假设“写完就立刻可读”，因为 CPU 缓存和内存屏障可能导致乱序
- 示例：写一个 int32 到共享内存起始位置：
import struct from multiprocessing import shared_memory shm = shared_memory.SharedMemory(create=True, size=1024) struct.pack_into('i', shm.buf, 0, 42) # offset=0, value=42
为什么 Value 和 Array 不够用？
它们底层确实用了共享内存，但封装太死：只能初始化时定死类型和大小，不能存 dict/list/str 等复合结构，也不能在运行时扩展容量。更关键的是，Value.value 赋值时仍会触发一次内部拷贝（虽然比 Queue 少，但仍是整字段复制）：
-
Value('d', 3.14)只能存一个 double，想存带 timestamp 的结构体？不行 -
Array('i', [1,2,3])初始化后长度固定，append 会抛TypeError - 多个进程同时写同一个
Value字段，不加锁会丢更新——它不自动同步，只是共享地址 - 如果你需要传递 NumPy 数组，优先用
shared_memory+np.ndarray构造视图，而不是把数组转成Array
必须配同步原语：光共享内存不等于线程安全
共享内存本身不提供互斥，它只是让多个进程“看得见同一块内存”。所有读-改-写操作（比如计数器自增、追加日志、更新状态位）都必须配锁，否则结果不可预测：
立即学习“Python免费学习笔记（深入）”；
- 用
multiprocessing.Lock最简单，但它基于系统信号量，跨程序通信时不一定可见（尤其 Windows） - 生产环境推荐
posix_ipc.Semaphore（Linux/macOS）或命名事件（Windows），名字需全局唯一，比如/myapp_counter_lock - 别用
threading.Lock，它只在单进程内有效，多进程下完全无效 - 信号量一定要配对使用：
acquire()后必须有release()，最好用with sem:语法，避免异常导致死锁
真正难的从来不是“怎么创建共享内存”，而是“怎么设计内存布局+同步策略+错误恢复”，比如 header 区放版本号和校验和，data 区按固定帧长切分，写满一帧才发信号通知读端——这些细节决定你能不能在高并发下稳定跑一周不崩。
