Python SharedMemory 的 close 和 unlink 有什么区别

Python 的 SharedMemory 清理最容易混淆的地方，是把“当前进程不再使用”和“整个共享内存块不再需要”当成了同一件事。close() 只关闭当前进程持有的文件描述符或句柄；unlink() 才负责删除底层共享内存块，而且同一个共享块通常只应由约定的责任方调用一次。

官方地址：https://docs.python.org/3/library/multiprocessing.shared_memory.html#module-multiprocessing.shared_memory。下面按创建者、连接者和最后责任方拆开说明，目标是让多个进程各自收尾，同时避免连接者提前销毁仍在使用的共享资源。

先分清 close 和 unlink 的对象

一个共享块可以被多个进程通过名称连接。每个进程得到的是自己的 SharedMemory 实例和句柄，但它们指向同一块共享内存。因此，关闭一个实例，并不等于把共享块从系统中删除。

可以把它类比为“退出自己的房间”和“拆掉整栋房子”：创建者和连接者都要退出自己的房间，但拆房子需要等待所有使用者离场。官方文档还特别说明，close() 后底层内存是否立即释放取决于操作系统，想要完成共享块清理仍需要正确安排 unlink()。

按创建者与连接者安排清理

下面的示例用一个创建进程和一个连接进程表达职责。它不依赖具体业务协议，重点是：每个实例都关闭自己；共享块由创建流程或明确的生命周期管理者负责最后销毁。

from multiprocessing import shared_memory


def create_block():
    # 创建者申请共享块，并把名称交给连接者。
    owner = shared_memory.SharedMemory(create=True, size=64)
    try:
        owner.buf[:5] = b"hello"
        return owner.name
    except Exception:
        # 创建成功但交接失败时，创建者必须释放自己的实例和共享块。
        owner.close()
        owner.unlink()
        raise


def attach_and_read(name: str) -> bytes:
    # 连接者只按名称打开现有共享块，不取得销毁所有权。
    reader = shared_memory.SharedMemory(name=name)
    try:
        return bytes(reader.buf[:5])
    finally:
        # 连接者结束使用，只关闭自己的句柄，不调用 unlink。
        reader.close()


def destroy_after_all_users_left(name: str) -> None:
    # 只有生命周期管理者确认没有读写者后，才执行一次 unlink。
    owner = shared_memory.SharedMemory(name=name)
    try:
        pass
    finally:
        owner.close()
        owner.unlink()

这段代码的关键不是函数名，而是所有权协议：连接者得到的是使用权，不是销毁权；创建者不能在读者仍可能访问时立即调用 unlink()。如果创建者本身还持有实例，通常也应先结束自己的读写，再关闭句柄并执行一次最终销毁。

unlink 之后不要继续使用缓冲区

官方文档允许 close() 和 unlink() 以任意顺序调用，但在 unlink() 之后继续访问共享块的数据，可能因平台不同出现内存访问错误。工程上不应把“调用顺序合法”误解为“删除后仍可安全读写”。

更稳妥的收尾顺序是：先停止生产和消费，等待仍在工作的进程退出或确认它们已经不再访问缓冲区；各进程分别关闭自己的实例；最后由唯一责任方调用一次 unlink()。如果某个进程需要把数据带出共享块，应在关闭前复制到普通 bytes、数组或业务对象中。

def read_snapshot(name: str) -> bytes:
    block = shared_memory.SharedMemory(name=name)
    try:
        # 先复制出进程自己的快照，避免返回仍依赖 buf 的对象。
        snapshot = bytes(block.buf[:64])
        return snapshot
    finally:
        # finally 保证本进程的句柄不会因业务异常而长期占用。
        block.close()

在 POSIX 风格共享内存上，名称删除与现有句柄的行为还可能表现为“名称已经不能重新连接，但旧句柄暂时仍可见”。这不是一个适合依赖的业务语义；跨平台代码应把 unlink() 视为资源进入最终销毁阶段的信号。

独立进程要留意 track 的清理边界

较新的 Python 文档为 SharedMemory 提供了 track 参数。使用 multiprocessing 创建的一组相关进程通常共享资源跟踪器；而通过 subprocess 或其他方式启动的独立 Python 进程，可能各自拥有资源跟踪器。此时，如果已经有一个进程负责记账，其他独立进程是否需要 track=False，要结合实际的生命周期设计决定。

track 解决的是资源跟踪范围，不会替代应用层的所有权协议。尤其不要因为开启了自动跟踪，就让每个连接者都调用 unlink()；也不要因为关闭跟踪，就省略由责任方承担的最终清理。Windows 对该参数还有平台特定行为，文档说明其共享内存会在所有句柄关闭后由系统处理，因此部署目标必须纳入设计。

把清理责任写成一张小清单

共享内存问题通常不是读写代码错了，而是交接协议没有写清楚。每次设计一个共享块，可以按下面五项确认：

1. 谁调用 SharedMemory(create=True)，谁记录共享块名称和生命周期。
2. 连接者是否只调用 SharedMemory(name=...)，并在自己的 finally 中调用 close()。
3. 谁能判断“所有读写者都结束”，谁就是唯一的 unlink() 责任方。
4. 调用 unlink() 前，是否已经停止生产、消费并释放仍引用 buf 的对象。
5. 进程是由共同的 multiprocessing 祖先进程创建，还是由独立的 subprocess 启动；这决定是否需要进一步规划 track。

记住一句话就够了：close 管“我这份句柄不用了”，unlink 管“这块共享资源可以被最终销毁了”。只要把两种责任分开，创建者和连接者就不会因为都想负责清理而互相提前拆掉共享块。

多个连接者可以都调用 close 吗？

可以。每个连接者关闭的是自己持有的 SharedMemory 实例，不会因此代替其他进程执行最终销毁。

多个进程可以都调用 unlink 吗？

不应这样设计。官方文档要求每个共享块只调用一次；应通过管理者、父进程或明确的租约协议选出唯一责任方。

close 后共享内存一定已经释放了吗？

不一定。close() 只关闭当前句柄，底层内存是否释放与平台和其他句柄有关。需要最终清理时仍要安排 unlink() 或使用合适的管理器。