Python ShareableList 固定长度共享列表的类型与容量边界

Python 的 ShareableList 适合“槽位数量已知、多个进程需要读写同一组简单值”的场景。它不是可以随意扩容的普通 list：创建后长度固定，值也只能落在有限的内置类型和容量范围内。先把这几个边界确认清楚，再决定是否用共享列表，通常比遇到 ValueError 或资源警告后再改结构更省时间。

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

先按类型和长度边界选数据模型

ShareableList 的每个槽位都存放在共享内存块中，官方支持的值类型是有范围的：整数为有符号 64 位 int，还包括 float、bool、str、bytes 和 None。字符串按 UTF-8 编码后、字节串按字节数计算，都不能超过单项的容量限制。

创建列表时把槽位设计成稳定接口

下面的示例把共享列表当成一个固定字段表：第 0 位是状态，第 1 位是计数，第 2 位是备注。注释说明了关键边界，真正的跨进程同步仍需要锁或其他协调方式；共享内存只解决“看见同一份数据”，不自动保证复合读改写操作的原子性。

from multiprocessing import shared_memory

# 先确定槽位数量，避免后续把 ShareableList 当成动态 list 使用
shared = shared_memory.ShareableList(["ready", 0, "worker-a"])
try:
    # 共享名称是另一个进程连接同一列表的入口
    print(shared.shm.name)
    shared[1] += 1
finally:
    # 当前进程释放映射；创建方在所有连接方退出后解除名称
    shared.shm.close()
    shared.shm.unlink()

这里的 shared[1] += 1 只是示例性的槽位写入。多个进程同时执行读、改、写时，应把临界区放进 multiprocessing.Lock，否则看到的结果不能简单归因于共享列表本身。

按名称连接时区分 close 和 unlink

另一个进程不需要拿到原对象，只要拿到共享内存名称，就能用 ShareableList(name=...) 连接同一组槽位。连接方在自己的使用范围结束后调用 close()；unlink() 是删除共享内存名称的动作，通常由创建方在确认没有后续连接时执行。

from multiprocessing import shared_memory

# name 应通过受控的进程参数或 IPC 传递，不要把它当成数据内容复制
name = "psm_example"
attached = shared_memory.ShareableList(name=name)
try:
    # 按下标读写已经存在的固定槽位
    attached[0] = "done"
finally:
    # 连接方只解除自己的映射，不负责删除共享内存名称
    attached.shm.close()

生产代码通常会让创建方持有最终清理责任，并用 try/finally 覆盖异常路径。若多个进程都随意 unlink()，后启动的连接方可能在找到名称前就失去入口；若只 close() 而没有最终解除链接，则可能留下资源跟踪告警。

这几个现象应该怎样排查

• 写入时报容量错误：先检查该槽位原来分配的字符串或字节空间，不能因为新值类型相同就认为一定放得下。
• 想追加元素：这是数据模型选错的信号。ShareableList 长度固定，追加需求应换成队列、管理器对象或重新创建一组列表。
• 尾部零字节消失：官方文档记录了 str/bytes 尾部 NUL 可能被去除的已知问题；对必须保留的值使用额外非零字节作哨兵。
• 多进程结果偶尔少加一次：检查是否存在无锁的复合更新，而不是先怀疑共享内存没有生效。

延伸问答

ShareableList 能不能保存字典或自定义对象？

不能直接按普通槽位保存。应把对象转换为支持的基础值，或选择队列、管道、Manager 等更适合对象传输的进程间通信方式。

连接方是否必须调用 unlink？

通常不需要。连接方负责 close() 释放自己的句柄，创建方在确认共享内存不再被使用后负责 unlink()。

列表长度需要变化时还能用 ShareableList 吗？

不建议。固定槽位适合状态表和小型字段集合；动态生产消费场景应该使用具备队列语义的结构。