GlobalMemoryStatusEx返回的ullAvailPhys不准，因其包含可立即回收的Standby内存，而任务管理器“可用内存”已扣除该部分；需结合GetPerformanceInfo或性能计数器模拟其逻辑。
为什么 GlobalMemoryStatusEx 返回的空闲内存不准？
直接调用 GlobalMemoryStatusEx 获取 ullAvailPhys 字段，常发现数值远高于任务管理器显示的“可用内存”。这不是接口坏了，而是 Windows 对“可用（Available）”的定义和用户直觉不一致：ullAvailPhys 包含已缓存但可立即回收的内存（如 Standby List），而任务管理器的“可用”还扣除了这部分——它更接近 ullAvailPhys - ullStandbyPageCount * 4096 的估算值。实际开发中若用于资源调度判断（比如是否启动新进程），只看 ullAvailPhys 容易误判。
实操建议：
- 不要把
ullAvailPhys当作“还能分配多少 MB 物理内存”的精确上限 - 若需模拟任务管理器逻辑，需额外调用
GetPerformanceInfo或解析\Memory\Standby Cache Reserve Pages性能计数器（后者需PDHAPI） - 对大多数应用，
ullAvailPhys > 512 * 1024 * 1024（512MB）即可认为内存充足；低于 128MB 才真正值得干预
如何正确调用 GlobalMemoryStatusEx 避免崩溃或返回失败？
该函数要求传入的 MEMORYSTATUSEX 结构体必须预先设置 dwLength 字段，否则在旧版 Windows（如 Win7）上会直接返回 FALSE 且 GetLastError() 为 ERROR_INVALID_PARAMETER。这是最常踩的坑。
正确写法（C++）：
立即学习“C++免费学习笔记（深入）”；
MEMORYSTATUSEX memInfo;
memInfo.dwLength = sizeof(MEMORYSTATUSEX); // 必须！不能省略
if (GlobalMemoryStatusEx(&memInfo)) {
ULONGLONG freeBytes = memInfo.ullAvailPhys;
// 使用 freeBytes...
}其他要点：
- 结构体必须用
ZeroMemory或{0}初始化，避免未初始化字段干扰 - 编译时确保定义了
_WIN32_WINNT≥0x0501（即 XP SP2+），否则链接会失败 - 该函数是线程安全的，无需加锁，但频繁调用（如每毫秒）会影响性能——建议缓存 1–2 秒
ullAvailPhys 和 ullAvailVirtual 到底该看哪个？
两者完全不是一回事：ullAvailPhys 是当前可立即分配的物理内存字节数（单位字节），而 ullAvailVirtual 是当前进程可用的虚拟地址空间剩余量（同样单位字节）。32 位进程虚拟地址空间上限约 2GB（用户态），即使物理内存有 16GB，ullAvailVirtual 也可能只剩几 MB——这时 new 或 VirtualAlloc 失败，跟物理内存是否空闲无关。
典型场景判断：
- 担心 OOM 崩溃？优先看
ullAvailPhys，尤其当它持续低于 100MB - 频繁
malloc失败但Task Manager显示内存充足？检查ullAvailVirtual，很可能是地址空间碎片化或泄露 - 64 位程序基本不用管
ullAvailVirtual，除非手动VirtualAlloc大量区域且未释放
有没有比 GlobalMemoryStatusEx 更准的替代方案？
没有“更准”的通用接口，只有“更贴近你需求”的选择。Windows 本身不对外暴露 Standby/Modified 页面的实时精确值，GlobalMemoryStatusEx 已是官方推荐的轻量级方案。若真需要任务管理器级精度：
- 用
PdhOpenQuery+PdhAddCounter读取\Memory\Available MBytes计数器（注意：单位是 MB，非字节，且有 1 秒延迟） - 调用
NtQuerySystemInformation（未公开 API），传入SystemPerformanceInformation，解析StandbyPageCount等字段——但需ntdll.lib链接，且微软不保证兼容性 - 对服务类程序，可考虑 WMI 查询
Win32_OperatingSystem的FreePhysicalMemory属性，但开销大、延迟高
绝大多数桌面或后台应用，老老实实用 GlobalMemoryStatusEx，并接受它的语义边界就够了。硬要抠那几百 MB 的差异，反而容易引入不稳定依赖。
