Windows下能否从指针获取句柄？实现类POSIX内存管理

首先纠正你对Windows API对应关系的误解：你提到的CreateFileMapping/MapViewOfFile是文件映射机制，和POSIX的mmap（尤其是匿名内存映射）逻辑并不完全对齐。如果你的需求是无需跨进程共享的私有内存管理，Windows原生的VirtualAlloc系列API才是更贴合POSIX逻辑的选择，而且全程不需要句柄，完全用指针操作：

对应POSIX的内存操作实现 #

• 预留内存（对应mmap(..., PROT_NONE, ...)）：

  LPVOID reserved_addr = VirtualAlloc(NULL, reserve_size, MEM_RESERVE, PAGE_NOACCESS);
  

  调用后返回预留内存区域的基地址，此时内存仅被预留，未实际分配物理页。

• 提交内存（对应mprotect(..., PROT_READ|PROT_WRITE)）：
  有两种实现方式：

  1. 直接提交指定区域：

     LPVOID committed_addr = VirtualAlloc(reserved_addr, commit_size, MEM_COMMIT, PAGE_READWRITE);
     

  2. 修改已预留区域的保护属性来提交：

     DWORD old_prot;
     VirtualProtect(reserved_addr, commit_size, PAGE_READWRITE, &old_prot);
     

  两种方式都无需额外句柄，直接通过预留阶段的指针操作即可。

• 释放内存（对应munmap）：

  • 释放整个预留区域（彻底回收）：

    VirtualFree(reserved_addr, 0, MEM_RELEASE);
    

  • 仅释放已提交的物理页（对应mprotect(..., PROT_NONE)或部分释放）：

    VirtualFree(reserved_addr, decommit_size, MEM_DECOMMIT);
    

关于文件映射的句柄问题 #

如果你的场景必须使用文件映射（比如跨进程共享），Windows没有提供从内存指针反向获取对应CreateFileMapping句柄的API，所以无法绕过句柄存储的问题。你提到的“在页基址存储句柄”的方案确实存在弊端：预留阶段的内存是PAGE_NOACCESS属性，无法写入；如果是提交后的内存，会占用额外空间，还可能和业务数据冲突。

结论 #

如果不需要跨进程共享内存，优先使用VirtualAlloc系列API，完全不需要句柄，操作逻辑和POSIX的mmap/mprotect/munmap高度一致，无需额外存储任何状态，只用指针就能完成全流程。

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