shared_memory 怎样共享进程间数组

用 Python 的 shared_memory 共享进程间数组，关键不是把一个 Python 列表“传过去”，而是让两个进程打开同一块字节缓冲区，再用一致的 shape 和 dtype 把它解释成数组。创建者负责写入共享块，接入者根据名称附加；双方还要自己约定谁能写、什么时候释放。

官方文档：https://docs.python.org/3/library/multiprocessing.shared_memory.html

共享数组的关键不是传数组，而是传名称与布局

SharedMemory.buf 暴露的是 memoryview。它没有数组的维度和元素类型，所以接入进程至少要拿到共享块名称、数组形状和 dtype。下面的创建者把 NumPy 数组拷贝到共享块，真正跨进程传递的只是名称和布局元数据。

import numpy as np
from multiprocessing import shared_memory

def create_array():
    source = np.array([10, 20, 30, 40], dtype=np.int64)
    # nbytes 按真实 dtype 计算容量，避免只按元素个数分配。
    shm = shared_memory.SharedMemory(create=True, size=source.nbytes)
    # 用同一块缓冲区创建数组视图，不再复制到另一块内存。
    view = np.ndarray(source.shape, dtype=source.dtype, buffer=shm.buf)
    view[:] = source
    # 生产者把 name、shape、dtype 交给接入进程；这里用返回值表示这组元数据。
    return shm, {"name": shm.name, "shape": source.shape, "dtype": str(source.dtype)}

接入方不能只记住“这是一个 int 数组”。如果形状或 dtype 不一致，同一串字节可能被解释成错误的数值，轻则结果异常，重则访问越界。生产环境通常把这三个字段放进消息、配置或约定好的共享目录中。

接入进程只按同一布局重新映射

拿到元数据后，第二个进程用同名块附加，再创建自己的 NumPy 视图。这个视图和创建者看到的是同一片内存，因此一方写入后，另一方可以看到变化；但“能看到”不等于“写入过程天然安全”。

import numpy as np
from multiprocessing import shared_memory

def attach_array(meta):
    # create=False 表示打开已有共享块，而不是重新申请一块。
    shm = shared_memory.SharedMemory(name=meta["name"])
    # shape 和 dtype 必须来自创建者的约定，不能凭感觉重建。
    view = np.ndarray(tuple(meta["shape"]), dtype=np.dtype(meta["dtype"]), buffer=shm.buf)
    # 这里的 view 直接指向共享缓冲区；不要在未同步时同时改写同一元素。
    return shm, view

# 使用完成后关闭当前进程的句柄；删除共享块由唯一责任方执行 unlink。

如果一个进程负责写、另一个进程只读，可以用“写完再通知”的协议降低冲突；若双方都会写同一片区域，就要按区间分工，或配合进程锁、事件等同步手段。队列只适合传递小型控制消息，数组本体仍留在共享块里。

close、unlink 和 track 不是同一件事

close() 只影响当前句柄，不能替代 unlink()；unlink() 也不应被每个进程重复调用。使用 multiprocessing 派生的进程通常共享同一个资源跟踪器，而用多个独立 Python 进程接入时，要特别留意 Python 3.13 引入的 track 行为，避免第一个退出的进程把仍在使用的共享块提前清掉。

相关问题

shared_memory 能直接保存 Python 列表吗？

不能按普通列表语义直接共享。应把固定布局的数值数组映射到缓冲区，或者使用标准库提供的 ShareableList，但它有元素类型和长度限制。

为什么接入进程读到的数组数值不对？

优先检查 dtype、shape、字节数和元素对齐是否完全一致，再确认创建者是否已经写完并发出通知。

只调用 close 能释放共享内存吗？

不能把两者混为一谈。所有进程都应关闭自己的句柄，底层共享块则由约定的单一责任方在最后阶段调用 unlink。