为何使用multiprocessing.shared_memory替代/dev/shm下的NamedTemporaryFile

关于你是否遗漏SHM模块路径获取方法 #

你没有遗漏相关接口，multiprocessing.shared_memory 模块的设计初衷是实现Python进程间的内存共享，不需要暴露文件系统路径，因此官方没有提供获取对应文件路径的方法。
你当前默认拼接/dev/shm/前缀的方案仅适用于Linux环境：Linux下shm_open创建的共享内存对象默认挂载在/dev/shm目录下，对象名和文件名直接对应；但该方案不兼容macOS、Windows等其他操作系统，这类系统的共享内存没有通用的文件系统路径映射规则。

两种方案的选型建议 #

1. 继续使用multiprocessing.shared_memory #

如果你仅在Linux环境部署，且数据量较大、对性能要求高，可以继续用该方案，建议做两处优化：

• 拼接路径时处理对象名开头的斜杠，避免生成重复斜杠的非法路径：path = os.path.join('/dev/shm', shm.name.lstrip('/'))
• 用try...finally或者自定义上下文管理器包裹SHM的生命周期，确保unlink一定会被执行，避免资源泄漏：

import os
import subprocess
import multiprocessing.shared_memory

mydata = b"test data"
shm = None
try:
    shm = multiprocessing.shared_memory.SharedMemory(create=True, size=len(mydata))
    shm.buf[:] = mydata
    path = os.path.join('/dev/shm', shm.name.lstrip('/'))
    subprocess.run(('tcpdump', '-r', path))
finally:
    if shm:
        shm.close()
        shm.unlink()

2. 改用tempfile.NamedTemporaryFile方案 #

如果需要更高的API稳定性、不想手动处理资源释放，或者需要兼容多平台，更推荐用该方案：
/dev/shm本身就是tmpfs内存文件系统，存放在这里的临时文件本质也是在内存中，和SHM性能差异极小，同时临时文件会在关闭后自动清理，不需要手动管理生命周期，也不需要自己拼接路径，兼容性更好。
注意你示例中的拼写错误：正确的类名是NamedTemporaryFile，不是NamedTemporarilyFile，修正后的示例：

import subprocess
import tempfile

mydata = b"test data"
with tempfile.NamedTemporaryFile(dir='/dev/shm') as f:
    f.write(mydata)
    f.flush()
    subprocess.run(('tcpdump', '-r', f.name))

总结 #

你的使用场景确实超出了multiprocessing.shared_memory的原生设计范围，如果仅在Linux环境运行，拼接路径的方案是可行的；如果追求稳定性和可维护性，更推荐用tempfile在tmpfs下创建临时文件的方案。

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