GetSystemInfo的lpMaximumApplicationAddress字段返回当前进程用户态虚拟地址空间上限，如32位程序为0x7FFFFFFF、64位程序通常为0x7FFFFFFFFFFF，该值由系统架构和PE头标志决定，非实时可用量。
Windows下用 GetSystemInfo 查看用户态地址空间上限
Windows默认为每个进程保留约2GB或4GB的用户态虚拟地址空间（取决于是否启用/LARGEADDRESSAWARE），这个值不是动态变化的，而是由系统架构和PE头标志共同决定。直接调用GetSystemInfo拿到的lpMaximumApplicationAddress字段，就是当前进程能用到的最高合法地址——它比实际“上限”更实用，因为它是进程视角的真实边界。
常见错误是误以为这个值反映空闲空间，其实它只是地址范围终点（比如0x7FFFFFFF或0x100000000），不随内存分配实时变动。若需判断剩余可用量，必须结合VirtualQueryEx遍历区域并累加MEM_FREE状态的块大小，但开销大、精度低、且受地址碎片影响严重。
- 必须链接
kernel32.lib，头文件包含<windows.h> - 32位程序即使运行在64位系统上，
lpMaximumApplicationAddress仍可能为0x7FFFFFFF，除非编译时加/LARGEADDRESSAWARE - 64位程序该字段通常为
0x7FFFFFFFFFFF（用户空间上限），但实际可用连续块远小于此
Linux下读取 /proc/sys/vm/max_map_count 和 ulimit -v 的区别
/proc/sys/vm/max_map_count 控制的是进程最多能创建多少个独立的内存映射区域（mmap区域），和单次可申请的最大虚拟地址空间无关；真正限制单个进程虚拟内存总量的是ulimit -v（virtual memory limit），单位KB。但注意：该限制默认为unlimited，此时进程理论上可占满整个用户空间（x86_64约为128TB，ARM64依配置而定）。
容易踩的坑是把max_map_count当成“最大内存”，其实它只影响mmap调用次数上限，比如JVM堆+多个直接内存缓冲区+共享库加载都算作独立mapping。当该值不足时，mmap会返回ENOMEM，错误信息不是“out of memory”而是“Cannot allocate memory”——但malloc仍可能成功，因它内部可能复用已有mapping或走brk路径。
立即学习“C++免费学习笔记（深入）”；
-
cat /proc/self/limits可查当前进程的Max address space行，比ulimit -v更准确（含shell继承关系） -
cat /proc/sys/vm/overcommit_memory设为2时，malloc会严格检查剩余虚拟空间，此时/proc/sys/vm/overcommit_ratio才起作用 - ASLR开启后，实际可用连续地址段远小于理论上限，
malloc失败未必是总量耗尽，更可能是找不到足够大的空洞
C++跨平台获取地址空间硬上限的可行做法
没有标准C++接口能直接返回“当前系统支持的最大虚拟地址空间”，因为这依赖于CPU模式（IA32/AMD64/ARM64）、内核配置（如Linux的CONFIG_ARM64_VA_BITS）、甚至启动参数（如Windows的/3GB）。最接近通用的做法是：先判明指针宽度，再结合平台特征常量估算。
例如sizeof(void*) == 8仅说明是64位程序，不代表能用满全部48位（x86_64）或57位（ARM64）地址空间——Linux 5.15+ x86_64默认只使用低47位，上限约128TB；而Windows x64用户空间固定为前128TB（0x00007FFFFFFFFFFF）。硬编码这些值风险高，应优先通过系统API获取运行时实际值。
- Windows：用
GetNativeSystemInfo代替GetSystemInfo，避免Wow64层误导（32位进程调用后者返回32位信息） - Linux：解析
/proc/cpuinfo中va_bits字段（若存在），或查getconf AVPHYS_PAGES（物理页数）与getconf PAGE_SIZE推算理论上限，但虚拟空间≠物理内存 - 不要依赖
std::numeric_limits<uintptr_t>::max()，它只是指针能表示的最大整数，不是OS允许的地址上限
为什么“当前可用虚拟地址空间”本身是个伪命题
虚拟地址空间不是池子，而是线性地址集合。所谓“可用”，必须限定在“连续且未被占用”的前提下才有意义。一个刚启动的进程看似有TB级空间，但加载几十个so/dll后，地址空间已被分割成数百个碎片，最大的空闲块可能只有几MB——VirtualAlloc或mmap(MAP_ANONYMOUS)失败往往就卡在这里，而非总量不足。
真正需要监控的，其实是关键分配点（如大块buffer、JIT代码生成区）附近是否存在足够连续空间。这时候应该用VirtualQuery（Win）或mincore（Linux）扫描特定地址区间，而不是全局统计。
- 频繁调用
VirtualQueryEx遍历全地址空间会导致显著性能下降（尤其在64位下），慎用于高频路径 - Linux下
/proc/[pid]/maps文本解析比系统调用更快，但需注意并发修改导致的readlink不一致 - 多数内存泄漏检测工具（如Valgrind、AddressSanitizer）不跟踪虚拟地址碎片，它们只关心实际提交的物理页
