虚拟内存和物理内存映射，多级页表和MMU简单认知理解不足小伙伴帮忙指正对每个人而言，真正的职责只有一个：找到自我。然后在心中坚守其一生，全心全意，永不停息。所有其它的路都是不完整的，是人的逃避方式，是对大众理想的懦弱回归，是随波逐流，是对内心的恐惧 ——赫尔曼·黑塞《德米安》
认识 Linux 内存构成：虚拟内存与物理内存计算机中的进程小伙伴一定不陌生，一般情况下一个应用会启动一个主进程，若干个子进程或者线程，每个进程都有一个内存地址空间用于存放当进程的一些共享数据,所以在进程启动时会请求一定大小的内存，这里的内存不是实际的物理内存地址，不直接定位物理内存。相反，是一块虚拟内存空间，内核会在进程地址空间中的虚拟地址空间和物理地址做一个映射来达到访问物理内存的目的。
比如在 Java 启动参数中，-Xms（Initial Heap Size）指定的 JVM 堆的初始大小是虚拟内存（Virtual Memory）的大小，而非直接对应物理内存的分配
<code class="javascript">java -jar -Xms1G -Xmx4G arthas-boot.jar</code>
JVM 向操作系统申请 1GB 的虚拟地址空间（对应 VIRT 的一部分）。物理内存占用可能仅为 100MB（取决于 JVM 初始化时的实际内存需求）。
那么这里的虚拟地址空间到物理内存地址的映射是什么？
首先这里的虚拟空间地址大小由`处理器架构位数决定
在x86_64的 64 位系统上面，理论的内存地址就是 16EiB（2^64） 的大小。但实际实现中受硬件架构和操作系统设计的限制，仅部分地址位被有效利用，硬件层面通过符号扩展机制仅支持 48 位虚拟地址（低 48 位），高 16 位（48-63）需填充为第 47 位的值，形成规范地址（Canonical Address）,实际可寻址空间为 256 TB（2^48 字节），分为两部分:
用户空间：0x0000000000000000 至 0x00007FFFFFFFFFFF（128 TB）内核空间：0xFFFF800000000000 至 0xFFFFFFFFFFFFFFFF（128 TB）Linux 系统默认使用完整的 48 位地址，但用户进程实际可用空间通常更小（如通过 TASK_SIZE_MAX 限制为 128 TB 减去保护页）
在 Linux 系统中查看 /proc/cpuinfo 时，address sizes 字段描述了 CPU 的物理地址和虚拟地址的寻址能力
<code class="javascript">┌──[root@liruilongs.github.io]-[~]└─$cat /proc/cpuinfo | grep addressaddress sizes : 45 bits physical, 48 bits virtualaddress sizes : 45 bits physical, 48 bits virtual┌──[root@liruilongs.github.io]-[~]└─$</code>
45 bits physical：表示 CPU 可以寻址的物理内存空间大小,决定了 CPU 能直接访问的最大物理内存, 2^45 字节，CPU 理论上最多支持 32 TiB 的物理内存
48 bits virtual：表示 CPU 的虚拟地址空间大小。决定了单个进程能使用的最大虚拟内存空间,2^48 字节，每个进程的虚拟地址空间上限为 256 TiB（操作系统通过虚拟内存机制将虚拟地址映射到物理地址或磁盘交换空间）。
所以进程虚拟地址空间的大小不取决于安装的物理内存大小 RAM，而是取决于处理器架构，单个进程通常不使用其整个地址空间。其中大部分是未分配的，并且没有映射到任何实际的物理内存。
其次进程在通过虚拟地址空间访问物理内存时
通过多级页表实现虚拟→物理地址转换,通过内存管理单元（MMU）执行实时地址转换与访问权限校验,同时支持按需分页（Demand Paging）机制延迟物理页帧分配.
<code class="javascript">进程访问虚拟地址 → MMU 查询 TLB → [命中 → 直接获取物理地址] │ └→ [未命中 → 查询页表 → 权限检查 → 缺页处理（可选）→ 生成物理地址 → 更新 TLB] │ └→ 访问物理内存</code>
这里的多级页表和MMU是什么？
多级页表和MMU处理器架构定义的标准内存单元为页面（Page），在x86_64架构中采用固定大小4 KiB（4096字节）,计算机系统将内存组织为固定大小的块，这里的块就是页面,或者叫页帧。页表用来存储虚拟页到物理页帧的映射,由操作系统 MMU 维护的数据结构。MMU(Memory Management Unit)内存管理单元.
多级页表：现代系统使用多级页表（如 x86-64 的 四级页表），逐步缩小搜索范围。
虚拟地址拆分：虚拟地址被分割为多个索引字段，逐级查询页表项（PTE）,48 位虚拟地址可能拆分为：PGD索引(9位) → PUD索引(9位) → PMD索引(9位) → PTE索引(9位) → 页内偏移(12位)
进程通过页表查询虚拟地址和物理地址的映射关系, 首先会检查 TLB 缓存，TLB（Translation Lookaside Buffer）高速缓存页表项的硬件缓存
命中（TLB Hit）：若 TLB 中存在该虚拟地址对应的物理地址，直接使用缓存结果，跳过页表查询。 未命中（TLB Miss）：若 TLB 中无缓存，需查询页表。在实际的查询之前，还有一个验证页表项的步骤，主要进行权限检查,MMU 检查页表项的权限（如读/写/执行、用户/内核模式权限）
虚拟地址分页号和偏移量，页面定位页表中的对应索引位置，根据页面查询到物理地址的起始位置，然后再通过偏移量找到具体的数据, 如果权限违规，会触发 段错误（Segmentation Fault）（例如尝试写入只读页，栈溢出，虚拟内存溢出之类）。
看一个Demo，通过 ulimit 模块设置单个进程栈大小为 16
<code class="javascript">┌──[root@liruilongs.github.io]-[~]└─$ulimit -s 16┌──[root@liruilongs.github.io]-[~]└─$ulimit -a | grep stackstack size (kbytes, -s) 16</code>
运行 ls /etc/ 命令时，发生了段错误，这里实际会生成了一个核心转储文件。
<code class="javascript">┌──[root@liruilongs.github.io]-[~]└─$ls /etc/Segmentation fault (core dumped)</code>
上面设置了 栈的大小，所以执行的命令存在栈溢出的情况，也可以通过 ulimit 配置虚拟内存大小，进程在初始化阶段（如加载自身代码或动态链接器）就耗尽虚拟地址空间。 动态链接器无法完成基础的内存分配（如栈、堆、代码段），导致进程崩溃。
代码语言：javascript代码运行次数：0运行复制<code class="javascript">┌──[root@liruilongs.github.io]-[~]└─$ulimit -v 1024┌──[root@liruilongs.github.io]-[~]└─$lsSegmentation fault</code>
当启动一个程序时，先给程序分配合适的虚拟地址空间，但是不需要把所有虚拟地址空间都映射到物理内存，而是把程序在运行中需要的数据，映射到物理内存，需要时可以再动态映射分配物理内存
因为每个进程都维护着自己的虚拟地址空间，每个进程都有一个页表来定位虚拟内存到物理内存的映射，每个虚拟内存也在表中都有一个对应的条目，
当进程访问虚拟地址，但是在页面中查不到时，内核就会产生一个缺页异常(Page Fault)内核此时会重新分配物理内存，更新页表。
所以在验证页表项通过之后，查询页表数据标记为不存在，会促发缺页中断，会重新分配物理页帧（从空闲内存或通过页面置换算法如 LRU 淘汰旧页），或者磁盘（如交换分区或文件）加载数据到物理页帧，更新页表项，标记为有效，重新执行触发缺页的指令。
通过页表项获得物理页帧基地址，加上虚拟地址中的页内偏移，得到最终物理地址。MMU 将物理地址发送到内存总线，CPU 读取或写入物理内存。
© 文中涉及参考链接内容版权归原作者所有，如有侵权请告知:)
《 Red Hat Performance Tuning 442 》
《性能之巅 系统、企业与云可观测性（第2版）》
© 2018-至今 liruilonger@gmail.com, All rights reserved. 保持署名-非商用-相同方式共享(CC BY-NC-SA 4.0)
