Python中ShareableList随读取进程关闭被移除的问题咨询

你的理解是正确的 #

ShareableList和底层的SharedMemory的默认行为确实会导致你遇到的问题：当读取进程调用close()时，由于系统层面的引用计数没有跨独立进程同步，进程会误判自己是最后一个持有共享内存的实例，从而自动触发unlink()，直接删除共享内存块，导致后续进程访问时出现FileNotFoundError，同时触发资源泄漏警告。

该方案不适合你的场景 #

multiprocessing的SharedMemory和ShareableList设计初衷是服务于有父子关系或协作紧密的进程集群（比如由同一个父进程启动的子进程），这类场景中可以由父进程统一管控共享内存的生命周期，或者进程间有明确的退出顺序约定。而你的场景是完全独立的读写进程，没有统一的管控方，这种默认的引用计数逻辑完全不匹配。

适合你场景的替代方案 #

1. 文件存储（最简易） #

直接将ID列表写入本地文件（如JSON、CSV或DBM格式）：

• 写入进程写完后调用flush()确保内容落地；
• 读取进程直接读取文件内容即可。
  优点是实现简单，无需复杂的同步逻辑，适合数据量不大的ID列表场景。

2. 本地键值存储/消息队列（性能更好） #

使用Redis本地实例或者类似的轻量级键值存储：

• 写入进程将ID列表存入指定Key；
• 读取进程直接读取该Key的内容。
  优点是支持高效并发读写，自带同步机制，适合频繁更新或数据量较大的场景。

3. 手动管控共享内存生命周期（不推荐） #

如果一定要用共享内存，必须完全手动管控：

• 写入进程创建共享内存后，仅在确认所有读取进程都已停止使用时才调用unlink()；
• 所有读取进程只能调用close()，绝对不能调用unlink()；
• 额外实现进程间同步机制（如文件锁、系统信号量）来跟踪活跃读取进程的数量，避免写入进程提前触发unlink()。
  这种方式复杂度极高，容易出现隐藏问题，除非有特殊性能需求，否则不建议使用。

内容的提问来源于stack exchange，提问作者Mason McGough