我目前正试图了解内存映射文件并可能在我的应用程序中实现它们。
该应用程序使用一系列大型输入文件来查找位置 - 当应用程序在单个线程上使用时，每个文件都按顺序访问，我猜这会进入更随机的访问区域 - 这使得 MMF 看起来很有价值。
但是，我对用法有点困惑-我应该在每个线程中更新一个 MMF 吗？我知道他们可以共享相同的底层文件，所以看起来我想要在所有线程中使用相同的文件，然后只是在每个线程上创建一个视图到该 MMF 中。
如果我应该只为每个文件创建一个，有没有办法测试 MMF 是否已经创建 - 通过它被分配的名称或其他方式，以防止尝试将多个地图打开到同一个文件，或者我需要知道线程中将使用哪些文件并传入已创建的实例以防止重复？
干杯。
如果每个线程专用于一个文件，那么让每个线程为它正在处理的一个文件创建自己的 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 子系统更方便。使用一种技术并没有错，因为它对开发人员来说既简单又方便，只要你承认这一点。
一个进程的线程总是共享相同的地址空间，这意味着每个线程都可以访问整个进程的“全局”对象和资源。
您将需要在您的进程中同步对文件的访问。在每个线程中重新打开文件没有多大意义，尤其是在谈论“更大”数量（几 MB）时。MSDN提供了一篇关于您的主题的文章，希望对您有所帮助。