如果每个线程专用于一个文件,那么让每个线程为它正在处理的一个文件创建自己的 MMF 可能是有意义的。仅由单个线程使用的资源更容易在线程内分配和销毁。
但是,如果所有线程都从同一个文件中读取,那么您就不想创建多个 MMF,因为这只会增加消耗的内存量并产生一致性问题(文件同一部分的多个视图)。
对于在同一个文件上操作的多个线程,您应该创建一次 MMF,并与多个线程共享 MMF 指针。
在多线程情况下按需分配会很快变得复杂,并且通常归结为需要锁定对受保护资源的每次访问。如果它们都必须排队等待对共享资源的访问,则要求锁会很快破坏运行多个独立线程的任何性能优势。
如果您可以在构造/启动线程之前分配共享资源,那么您通常不需要锁定访问资源,因为资源在线程需要它时始终存在。
因此,我会考虑在线程启动之前分配 MMF,并在所有线程之间共享 MMF 指针,而无需锁定。
这也假设文件是严格只读的——多个线程永远不会写回文件或 MMF。多个线程可以共享一个指向公共内存区域/MMF 的指针以进行只读访问,而不会出现任何线程并发问题。
与传统的缓冲文件访问相比,请注意您对 MMF 性能的假设。如果您的整个文件数据可以轻松地放入可用 RAM,那么 MMF 对于随机访问模式的性能可能比缓冲文件 I/O 的性能更高。如果文件数据远大于可用 RAM,则缓冲文件 I/O 对于随机访问的性能可能比使用 MMF 更高。为什么?因为 MMF 对内存使用很敏感。MMF 只能加载 4k 页大小的块中的数据。缓冲文件 I/O 可以根据您的实际数据大小需求和模式进行更精细的调整。如果您的应用从文件中 100 个不同位置加载 512 字节的数据,那么 MMF 将不得不加载 4k * 100 = 400k 字节的数据,即使您只需要 512 * 100 = 50k 的数据。在这个数据访问模式/用例中,
MMF 的主要吸引力更多地是开发人员的便利性,而不是原始性能。对于开发人员来说,从 MMF 支持的指针读取通常比编写和调整面向块的文件 I/O 子系统更方便。使用一种技术并没有错,因为它对开发人员来说既简单又方便,只要你承认这一点。