GetWriteWatch是否兼容内存映射文件（MMF）？

先给你明确结论：GetWriteWatch 完全不支持内存映射文件（MMF），这就是它返回-1且无法填充结果结构的核心原因。

为什么GetWriteWatch不支持MMF？ #

GetWriteWatch是专门为私有提交内存设计的——也就是进程通过HeapAlloc、VirtualAlloc（带MEM_COMMIT）分配的、完全属于进程私有且不关联磁盘文件的内存区域。这类内存的修改跟踪依赖Windows内存管理器维护的页表"写位"标记。

而内存映射文件的视图属于映射内存，它的物理页是和磁盘文件直接绑定的。系统对MMF页的修改管理逻辑完全不同：当你修改MMF页时，系统会标记该页为"脏页"，但并不会维护GetWriteWatch所需的写跟踪结构，因此调用该API自然会失败。

针对你的场景的替代方案 #

你的核心需求是在低内存时主动识别MMF中已修改的页，将其写回磁盘以释放物理内存，避免系统无差别分页导致的停滞。这里有几个可落地的方案：

• 手动跟踪修改区域
  在代码里维护一个页级别的标记结构（比如位图数组，每个位对应MMF的一页），每次向MMF写入数据时，计算写入区域对应的页号，标记这些页为"已修改"。当需要释放内存时，遍历位图找到所有脏页，调用FlushViewOfFile将其写回磁盘，再用VirtualFree（指定MEM_DECOMMIT）释放对应的物理内存。
  这个方案完全可控，但要确保所有MMF的写入操作都经过你的跟踪逻辑——如果有第三方代码或系统API直接写入MMF，会出现漏标记的情况。

• 按页批量Flush+释放
  如果你不想维护跟踪结构，可以在低内存时直接按系统页粒度遍历整个MMF视图，对每一页调用FlushViewOfFile。虽然会有一些无意义的IO（比如未修改的页也会被刷新），但实现简单，适合快速迭代。可以用GetSystemInfo获取系统页大小（通常是4KB或2MB），按页块批量处理来减少IO次数。

• 精细化管理MMF的内存提交
  初始化MMF时使用SEC_RESERVE属性，只保留虚拟地址空间，不立即提交物理内存。当业务需要访问某个页时，再用VirtualAlloc手动提交该页的物理内存。这种方式可以从根源上减少物理内存的占用，避免一开始就把大量MMF页加载到内存，大幅降低低内存场景的出现概率。

• 结合系统内存监控触发操作
  定期调用GlobalMemoryStatusEx或GetPerformanceInfo获取系统内存状态，当可用物理内存低于设定阈值（比如总内存的10%）时，再触发MMF的刷新和内存释放操作。这样可以避免不必要的性能开销，只在真正需要的时候进行内存回收。

额外注意点 #

• 如果你的MMF是用SEC_IMAGE属性映射的可执行文件/动态库，这类页是只读的，根本不需要跟踪修改；只有可写的SEC_COMMIT类型MMF视图才需要处理。
• 不要依赖SetProcessWorkingSetSize强制回收工作集，这是被动的系统行为，无法精准控制哪些MMF页被释放，效率远不如主动处理脏页。

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