不能直接用np.array()创建共享内存数组，因为它总会拷贝数据而非共享；必须用np.ndarray(shape,dtype,buffer=shm.buf)手动绑定，且需确保buffer长度足够、显式指定dtype和shape，并注意shm.buf引用生命周期。
为什么不能直接用 np.array() 创建共享内存数组
因为 np.array() 总是分配私有堆内存，即使你传入一个指向共享内存的 buffer（比如 mmap 对象），它也会拷贝数据——这完全违背共享初衷。真正共享的前提是：多个进程看到的是同一块物理内存页，且 NumPy 数组的 data 指针必须直接指向它，不能中转、不能拷贝。
用 numpy.ndarray() 构造器 + buffer 参数手动绑定
这是最可控的方式，适用于已存在的共享内存对象（如 mmap.mmap 或 shared_memory.SharedMemory）。关键点在于跳过 NumPy 的默认内存管理，强制它把底层 buffer 当作自己的 data 区域。
- 确保 buffer 长度 ≥
dtype.itemsize * size，否则构造时会静默截断或触发ValueError: buffer is too small - 必须显式指定
dtype和shape，NumPy 不会从 buffer 推断这些信息 - 如果 buffer 来自
shared_memory.SharedMemory，需用其buf属性（memoryview类型），而非直接传shm实例
shared_memory.SharedMemory
时的常见陷阱
Python 3.8+ 的 shared_memory 模块封装了 POSIX shm_open 或 Windows CreateFileMapping，但它返回的对象本身不是 buffer，不能直接喂给 np.ndarray()。
- 错误写法：
np.ndarray(..., buffer=shm)→ 报TypeError: buffer object does not have required buffer interface - 正确做法：始终用
shm.buf，它是memoryview，满足 buffer protocol - 注意生命周期：只要还有
np.ndarray持有shm.buf的引用，就不能调用shm.close()或shm.unlink()，否则数组访问会 segfault - 跨平台差异：Windows 上
shm.size可能不准确（尤其小尺寸），建议用len(shm.buf)获取真实可用字节数
替代方案：memmap 适合文件-backed 共享
如果共享场景允许落盘（即通过文件交换数据），np.memmap 更简单、更健壮，且自动处理 dtype/shape/offset 对齐。
- 它本质是
mmap.mmap+ NumPy 封装，支持读写、偏移、多进程并发（需自行加锁） - 不依赖
shared_memory模块，兼容 Python 3.6+ - 但注意：文件路径必须所有进程都可达；删除文件不等于释放内存，需显式
del arr或arr._mmap.close()
# 进程 A
arr = np.memmap('/tmp/shared.dat', dtype='float32', mode='w+', shape=(10000,))
arr[:] = np.random.rand(10000)
进程 B（同一路径、相同 dtype/shape）arr2 = np.memmap('/tmp/shared.dat', dtype='float32', mode='r', shape=(10000,))
print(arr2[0]) # 读到进程 A 写的值
共享内存映射不是“创建完就能用”，核心在于 buffer 生命周期与 NumPy 数组生命周期的严格对齐——稍有错位，就是段错误或静默数据损坏。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
