调用unmapviewoffile前必须确保无线程访问映射内存，否则引发访问违规；需同步等待线程退出或引用计数归零；返回false时须检查getlasterror区分错误原因；closehandle与unmapviewoffile无顺序要求但均不可遗漏；文件大小变化后旧视图不会更新，需手动重建映射。
调用 UnmapViewOfFile 前必须确保没有线程正在访问映射内存
这是最常被忽略的安全前提：只要还有任意线程在读写该视图地址，UnmapViewOfFile 就可能触发访问违规或未定义行为。Windows 不做运行时保护，它只负责解除页表映射——如果此时 CPU 缓存或指令流水线里还拿着旧地址，崩溃就发生了。
- 典型错误现象：
Access violation reading location 0x...出现在UnmapViewOfFile返回后几毫秒内，实际是残留指针被误用 - 使用场景：多线程处理大文件（如日志解析、图像批量加载），主线程准备释放，但工作线程还在遍历
LPVOID视图 - 正确做法不是“快点调”，而是先同步：用
WaitForMultipleObjects等待所有相关线程退出，或用InterlockedDecrement+ 自旋等待引用计数归零 - 别依赖 RAII 自动释放——
std::unique_ptr的自定义 deleter 在析构时仍可能撞上竞态
UnmapViewOfFile 返回 FALSE 时要立刻检查 GetLastError()
很多人只写 if (!UnmapViewOfFile(pView)) { /* log */ } 就完事，但失败原因差异极大，处理方式完全不同。
- 常见错误现象：
UnmapViewOfFile返回FALSE，但GetLastError()是ERROR_INVALID_PARAMETER—— 说明传入的pView根本不是合法映射地址（比如已被释放过、或根本没成功MapViewOfFile） - 另一个高频值：
ERROR_NOT_FOUND，表示该视图已被其他线程抢先释放（Windows 允许多次调用，但只有第一次生效） - 关键参数差异：传入的
pView必须和MapViewOfFile返回值完全一致，不能是计算偏移后的子地址（例如(BYTE*)pView + 4096），否则直接报ERROR_INVALID_PARAMETER - 建议始终捕获错误码并记录，尤其在线上环境——静默忽略会让内存泄漏或双重释放问题难以复现
关闭文件映射句柄 CloseHandle(hMapping) 和释放视图无顺序要求，但必须都做
很多人以为“先关句柄再解映射”或“反过来”有严格顺序，其实 Windows 文档明确说二者独立。但漏掉任何一个，都会导致资源泄漏。
- 典型错误现象：任务管理器里进程私有字节数持续上涨，
VMMap显示大量 “Mapped File” 类型内存未回收 - 使用场景：封装成类时，在析构函数里只调了
UnmapViewOfFile，忘了CloseHandle(hMapping)；或者反过来，先关了句柄，但视图指针还在野指针状态 - 性能影响：不关
hMapping句柄会导致内核对象句柄表持续占用，长期运行服务可能触及系统句柄上限（默认约 16K） - 安全建议：两个操作都加
if (xxx) { ... }判空，且分别检查返回值——CloseHandle失败同样要查GetLastError()（比如句柄已被其他线程关闭）
映射文件大小变化后，旧视图不会自动更新，也不能靠 UnmapViewOfFile + 重映射来“刷新”
这是个隐蔽陷阱：文件被外部进程截断或追加，已映射的视图地址空间不变，越界访问会崩，而 UnmapViewOfFile 本身对此毫无感知。
- 常见错误现象：程序稳定运行数小时后突然崩溃，dump 显示访问地址超出原始文件长度，但代码里没改指针
- 根本原因：
MapViewOfFile锁定的是创建映射时的文件大小，后续文件增长/收缩都不影响已存在视图的长度 - 正确做法：需要感知变化时，必须主动调用
GetFileSize对比，若不同则先UnmapViewOfFile，再CreateFileMapping+MapViewOfFile重建（注意新旧映射不能同时存在，否则可能触发磁盘 I/O 冲突） - 兼容性提醒：Windows 10 1809+ 支持
MAP_NORESERVE类似语义，但 C++ 标准 API 无此选项，仍需手动管理
真正难的从来不是调用那行代码，而是确认“此刻所有线程真的一致认为这块内存可以交还给系统了”。多一次引用计数检查，比多十次 UnmapViewOfFile 调用更接近安全。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
