内存管理基础：物理内存与虚拟内存、内存分页与分段机制、MMU的作用
各位同学，咱们今天聊点硬核的——内存管理。说实话，我做了十几年运动控制，见过太多因为内存问题导致的“灵异事件”：电机突然抖一下、轨迹跑偏、甚至直接死机。追根溯源，十有八九跟内存管理脱不了干系。
你想想看，运动控制是实时系统，对时间确定性要求极高。内存访问延迟哪怕多几个微秒，控制周期就可能崩掉。所以，搞懂内存管理，是咱们做实时系统的基本功。
物理内存 vs 虚拟内存
物理内存，就是板子上焊的那几颗DDR颗粒。CPU直接通过地址总线访问它。但问题来了——物理内存是有限的，而且多个任务抢着用，很容易打架。
虚拟内存，说白了就是给每个进程画了个“大饼”。每个进程都以为自己独占4GB（32位系统）或更大空间。实际上，这些地址是假的，需要映射到真实的物理内存上。
核心要点：虚拟内存让每个进程拥有独立的地址空间，互不干扰。这在运动控制中特别重要——你总不希望一个任务把另一个任务的内存踩了吧？
我在一个多轴联动项目中遇到过这种情况：两个控制线程同时访问共享内存，结果一个线程写了一半，另一个线程读到了脏数据，电机直接“抽风”。后来我强制给每个任务分配独立的虚拟地址空间，问题才解决。
内存分页与分段机制
虚拟地址怎么映射到物理地址？两种主流方案：分段和分页。
分段机制
分段，就是把内存分成若干段：代码段、数据段、堆栈段等等。每个段有基址和长度限制。这种机制很直观，但有个致命缺点——容易产生外部碎片。
举个例子：你申请了三个段，分别是4KB、8KB、4KB。释放中间那个8KB后，剩下的两个4KB之间有个8KB的空洞。如果新来的段需要6KB，放不下，只能干瞪眼。
注意：分段机制在现代操作系统中用得少了，但x86架构的段页式管理里还能看到它的影子。做底层开发时，你可能会碰到段描述符、全局描述符表（GDT）这些概念。
分页机制
分页就聪明多了。它把物理内存切成固定大小的“页框”（通常是4KB），虚拟内存也切成同样大小的“页”。映射时，只需要建立页表，把虚拟页号映射到物理页框号。
这样做的好处很明显：
- 没有外部碎片——所有页框大小一样，分配回收都很方便
- 支持按需加载——只有真正用到的页才加载到物理内存
- 方便共享——多个进程可以映射到同一个物理页框
我记得有一次优化一个实时控制程序，发现内存占用居高不下。查了半天，原来是预分配了太多内存。后来改用分页+按需加载，内存占用直接降了60%。嗯，这就是分页的魅力。
MMU的作用
MMU（Memory Management Unit），内存管理单元。它是CPU内部的一个硬件模块，专门负责地址转换。
它的工作流程大致是这样的：
- CPU发出虚拟地址
- MMU查页表，找到对应的物理地址
- 如果页表命中，直接返回物理地址
- 如果缺页，触发缺页异常，操作系统去磁盘加载
实战技巧：在运动控制中，缺页异常是灾难性的。因为它会导致不确定的延迟。我建议你把实时任务的代码和数据锁定在物理内存中，用mlockall()或类似机制，防止被换出。
我曾经在一个伺服驱动项目里，就因为没锁内存，导致控制循环偶尔被缺页中断打断，电机出现周期性抖动。查了三天才找到原因。从那以后，我所有实时任务都强制锁内存。
知识体系结构图
下面这张图，是我自己总结的内存管理核心逻辑。你看一眼就能明白整个脉络：
实际应用中的避坑指南
做运动控制实时系统，内存管理这块有几个坑，我踩过，你们别踩：
- 不要依赖缺页异常——实时任务必须锁内存，用mlockall()或mlock()
- 小心TLB缺失——频繁切换上下文会导致TLB刷新，增加延迟。我建议把实时任务绑定到特定CPU核心
- 大页（Huge Pages）——对于需要大量连续内存的场景（比如DMA缓冲区），用2MB或1GB的大页，减少TLB缺失
- 避免动态内存分配——实时任务里别用malloc/free，用预分配的内存池
曾经有一次：我在一个高速运动控制项目里，用了标准的malloc分配缓冲区。结果运行一段时间后，内存碎片化严重，分配失败，系统直接崩溃。后来改用静态分配+内存池，稳如老狗。
好了，这一章的内容就到这里。记住一句话：在实时系统里，内存管理不是“能用就行”，而是“必须确定”。你想想看，电机每转一圈，控制周期就那么点时间，哪容得下内存访问的不确定性？