我遇到了这个问题的一些通用版本，要求对共享内存/tmpfs/mmap/块读取进行一般比较，但我想问这个问题的特定于应用程序的版本，以尝试找出更有效的方法延迟方面。
我有一个图像处理库的绑定，它只提供写入命名文件的选项，而不是提供任何直接到内存的字节数组选项。我将此库用作服务器的一部分，该服务器读取许多不同格式和大小的源图像，应用大小/颜色转换，并将此图像的缩略图版本缓存在 LRU 缓存中的内存中。然后，服务器通过 http 从 LRU 中提供这些缩略图。服务器将拥有有限数量的图像工作者（比如 2-4 个）。源图像的平均大小范围为 100KB-20MB。输出图像大小的平均范围为 20KB-1MB。
我之前使用的图像处理库确实能够将输出图像写入字节数组，我现在正尝试切换到另一个库。因此，我正在评估解决此输出限制的选项。
我一直在调查mmap和tmpfs作为选项，我有一些想法的组合，但根据我的访问模式，我希望听到一些关于开销或并发症的知情回应。
我担心的/dev/shm是可移植性，因为我不想自己为我的应用程序配置/安装它，它可能是固定大小（尽管很可能存在并且很大）。我也不清楚当一个普通的块支持的预分配文件/tmp是 mmap'd 并且图像库写入它时，引擎盖下会发生什么，然后我从中读取。事物的读取大小有什么好处吗？
概括
以下具有 {file,memory} 支持的图像缓冲区的潜在方法是否适合用于 mmap？
- 如果
/dev/shm已挂载，则为每个镜像工作者预分配一个内存支持的文件 - 如果
/dev/shm未挂载，/tmp则为每个镜像工作者预分配一个普通文件 - 在服务器进程的长度内，为每个工作人员打开一个 mmap。输出图像数据将从图像库写入文件路径，然后通过 mmap 字节数组访问以复制到 LRU 缓存中。