Windows 文件与CreateFile/ReadFile的内存映射

使用内存映射文件来读取（常规大小的文件）比使用CreateFile-ReadFile组合来读取（常规大小的文件）有哪些缺点（如果有的话）？

建立文件映射需要更复杂的代码，而不仅仅是打开和读取。文件映射用于随机访问文件的某个部分。如果您不需要它，只需不用担心文件映射

---

此外，如果需要将代码移植到另一个平台上，如果不使用文件映射，您可以更轻松、更快地完成此操作。

对于ReadFile/WriteFile，您具有确定性错误处理语义。使用内存映射文件时，会通过引发异常返回错误

此外，如果内存映射文件必须命中磁盘（甚至更糟的是，网络），则内存读取可能需要几秒钟（甚至几分钟）才能完成。根据您的应用程序，这可能会导致意外的暂停

如果使用ReadFile/WriteFile，则可以使用API的异步变体来控制此行为

---

如果使用ReadFile，您还可以获得更确定的性能，特别是如果您的I/O模式是可预测的，那么内存映射I/O通常是随机的，而as ReadFile几乎总是串行的（因为ReadFile在当前文件位置读取，并前进到当前文件位置）.

文件映射的一大优点是它不会影响系统缓存。如果您的应用程序通过ReadFile进行过多的I/O，系统缓存将增长，消耗越来越多的物理内存。如果你的操作系统是32位的，并且你有超过1GB的内存，那么你就很幸运了，因为在32位的Windows上，系统缓存的大小受到1GB的限制。否则，系统缓存将消耗所有可用的物理内存，内存管理器将很快开始将其他进程的页面清除到磁盘，从而强化磁盘操作，而不是实际减少它们。这种效果在64位窗口上尤其明显，其中缓存大小仅受可用物理内存的限制。另一方面，文件映射不会导致系统缓存的过度增长，同时也不会降低性能。

您是否有任何来源来了解这种智慧或相关材料，从而更清楚地了解这些现象？我的意思是，这可能是事实，但从我读到的内容来看，“系统缓存”听起来很模糊，我们是在谈论在交换之前积累了文件数据的页面吗？来源是我的团队在密集磁盘I/O方面的经验。在切换到映射文件之前，我们遇到了问题。映射文件提高了性能并降低了内存占用。我无法提供更多细节，那是大约10年前的事了，我简直不记得了