Linux下虚拟地址空间上限由CPU架构和内核配置静态决定，非动态趋势指标；实际可用上限可通过/proc/self/maps最后一行末尾地址获取，如x86_64默认为0x0000800000000000。
Linux 下用 /proc/self/status 查看当前进程的虚拟地址空间上限
Linux 内核不提供“系统级虚拟地址空间上限趋势”这种动态指标，它本质上由体系结构（如 x86_64 的 48 位或 57 位 VA）和内核配置（CONFIG_ARM64_VA_BITS、CONFIG_X86_PAE 等）静态决定。所谓“当前可用上限”，实际反映的是**当前进程能合法访问的最大虚拟地址**，而非实时变化的趋势值。
最直接的方式是读取 /proc/self/status 中的 MMUPageSize 和 MMUPageSize 并不直接暴露上限；真正关键的是 Seccomp 或 CapEff 也无关——你需要看 VMPeak 和 VmSize，但它们是已用值，不是上限。
真正表示“理论可映射上限”的字段藏在 /proc/self/maps 的最后一行（通常是 [vvar] 或 [vdso] 之后的空洞），但更可靠的是解析 /proc/self/auxv 中的 AT_SYSINFO_EHDR 或直接查 getrlimit(RLIMIT_AS, &rl) ——不过注意：RLIMIT_AS 控制的是 *虚拟内存总量软限*，不是硬件/内核允许的绝对上限。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
cat /proc/self/maps | tail -n 1观察最高地址行（例如7ffffffff000-800000000000 rw-p 00000000 00:00 0 [vvar]），末尾地址800000000000就是该进程用户空间的理论上界（x86_64 默认 48 位：2⁴⁸ = 0x0000800000000000） - 写 C++ 代码时，可调用
sysconf(_SC_PHYS_PAGES)获取物理页数，但这是物理内存，和虚拟地址空间无关；别混淆 - 不要试图从
std::numeric_limits<uintptr_t>::max()推导——那是指针宽度上限，不代表内核实际允许的用户空间布局（比如内核可能保留高位用于 KASLR 或 SMAP）
Windows 上通过 GetSystemInfo 和 GetNativeSystemInfo 获取用户态 VA 范围
Windows 没有“趋势”概念，只有明确的架构依赖上限：x64 默认用户空间为 0x00000000'00000000 – 0x00007fff'ffff0000（128TB），启用 4GB 以上 RAM 支持（EnableLargePage）或开启 57 位 VA（Windows Server 2019+ + WSL2 内核）才可能更高，但应用层无法感知“趋势”，只能查当前生效范围。
关键函数是 GetNativeSystemInfo，它返回 SYSTEM_INFO 结构体，其中 lpMinimumApplicationAddress 和 lpMaximumApplicationAddress 才是真实有效的用户虚拟地址边界。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 必须用
GetNativeSystemInfo，而非GetSystemInfo——后者在 WoW64 进程下返回的是模拟层视图，会严重误导（比如显示 4GB 限制） -
lpMaximumApplicationAddress是含边界值，即程序可mmap或VirtualAlloc到的最高地址（不含），典型值为0x00007fff'ffff0000，不是0xffffffffffffffff - 没有 API 返回“过去一周的 VA 上限变化”，Windows 不记录这类指标；所谓“趋势”只能靠外部监控工具轮询记录
GetNativeSystemInfo结果并比对，但几乎无意义——它只会在系统重启或内核更新后才可能变
跨平台 C++ 封装时为什么不能依赖 sizeof(void*) 或 UINTPTR_MAX
sizeof(void*) == 8 只说明是 64 位指针，完全不能推出可用虚拟地址空间大小。ARM64 Linux 可配 48 位或 52 位 VA；x86_64 Windows 早期只开放 44 位用户空间；某些嵌入式 Linux 甚至用 39 位 PA+VA 混合配置。硬编码假设会导致 mmap(MAP_FIXED) 失败或地址截断。
常见错误现象：
- 在 ARM64 设备上用
0x0000ffffffffffff做地址掩码，结果部分高位地址被内核拒绝（实际只支持 48 位） - 把
UINTPTR_MAX当作mmap的addr参数传入，触发EINVAL（内核要求对齐且在合法范围内） - 用
std::addressof获取某个大数组首地址，再加size判断是否越界——这在 ASLR 启用时毫无意义，因为起始地址每次不同
正确做法是运行时探测，而不是编译期推导。
为什么不存在“虚拟地址空间上限趋势”这个指标
虚拟地址空间上限不是操作系统运行时动态调节的性能指标，而是由 CPU 架构手册定义、内核编译时固化、启动时一次初始化的静态参数。它不会随内存压力、负载、时间推移而“上升”或“下降”。所谓“趋势”需求，往往源于对以下事实的误解：
- 误把
/proc/meminfo中的MemAvailable当成虚拟内存余量（其实它是物理内存预估） - 看到
vm.max_map_area这类 sysctl 可调，以为它改变 VA 上限（其实它只限制单个mmap区域最大尺寸，不影响总地址空间） - 观察到
brk增长或mmap分配成功，以为“上限在提高”（其实是分配器在已有上限内做管理）
如果你真需要长期观测，唯一可行路径是定期采集 /proc/self/maps 最高地址行 + GetNativeSystemInfo 边界值，再配合内核日志确认是否发生过 CONFIG_ARM64_VA_BITS 变更——但这些变更只发生在重装系统或刷内核后，日常运行中不会动。
