1. 计算机内存基础：内存分层结构

大家好，我是你们的老朋友。今天咱们来聊聊内存——这个看似基础，却让无数程序员栽过跟头的话题。

说实话，我见过太多人写代码时只关心逻辑，不关心内存。结果呢？指针越界、段错误、内存泄漏，一个接一个。我自己刚入行那会儿，也吃过不少亏。有一次调试一个诡异的崩溃问题，整整三天没睡好，最后发现是栈溢出——嗯，从那以后，我再也不敢小看内存了。

1.1 内存分层结构

计算机的内存不是铁板一块。它是一套分层体系，从快到慢、从贵到便宜、从小到大的排列。我习惯把它想象成一个金字塔：

你想想看，CPU每秒能执行几十亿条指令，如果每次都要去磁盘拿数据，那得等到猴年马月？所以，硬件工程师们设计了这套分层结构，让最常用的数据待在最快的地方。

寄存器

寄存器是CPU内部的存储单元，速度最快，没有之一。但数量极少，一般就几十到几百个字节。我写汇编时经常跟它们打交道——嗯，现在的高级语言基本不让你直接碰了，但编译器会帮你安排。

缓存（L1/L2/L3）

缓存是寄存器和主存之间的缓冲地带。L1最快，但容量最小；L3慢一些，但容量更大。我记得有一次优化一个图像处理算法，把数据访问模式改成缓存友好的，性能直接提升了5倍。这就是所谓的「缓存局部性」——说白了，就是尽量让CPU在缓存里找到它想要的数据。

RAM（主存）

这就是我们常说的「内存条」。程序运行时的代码和数据都在这里。速度比缓存慢两个数量级，但容量大得多。我见过不少新手以为内存是无限的，结果malloc到内存耗尽——嗯，操作系统会出手，但你的程序可能已经被OOM killer干掉了。

磁盘

磁盘是持久化存储，速度最慢。SSD比HDD快很多，但跟RAM比还是差了几个数量级。所以，频繁读写磁盘的程序，性能瓶颈往往就在这里。

1.2 虚拟内存与物理内存

物理内存就是实实在在的RAM芯片。但操作系统给每个进程看到的，是一个「虚拟」的地址空间。为什么要这么搞？

原因有三：

• 隔离性：每个进程有自己的虚拟地址空间，互不干扰。A进程的地址0x1000和B进程的地址0x1000，映射到不同的物理地址。
• 安全性：进程不能随便访问别人的内存。操作系统通过页表来控制权限。
• 简化编程：程序员不用关心物理内存的布局，只管用虚拟地址就行。

虚拟内存通过「页表」映射到物理内存。页表是操作系统维护的一张表，记录了虚拟页到物理页的映射关系。当CPU访问一个虚拟地址时，MMU（内存管理单元）会查页表，找到对应的物理地址。

如果访问的虚拟页不在物理内存中，就会触发「缺页中断」。操作系统从磁盘把数据加载到内存，然后继续执行。这个过程对程序是透明的，但代价很高——一次缺页中断可能要几毫秒，比正常内存访问慢几万倍。

1.3 进程地址空间

每个进程的虚拟地址空间，从低地址到高地址，通常分为以下几个区域：

区域	地址范围（32位示例）	用途	特点
代码段（.text）	0x08048000 - 0x08049000	存放程序指令	只读，不可写
数据段（.data/.bss）	0x08049000 - 0x0804a000	存放全局变量、静态变量	可读写，生命周期与进程相同
堆（heap）	0x0804a000 - 0x40000000	动态分配的内存（malloc/new）	向高地址增长，需手动管理
栈（stack）	0xbffff000 - 0xc0000000	局部变量、函数调用信息	向低地址增长，自动管理

代码段

代码段存放的是程序的机器指令。它是只读的，防止程序意外修改自己的代码。我见过有人试图通过指针修改代码段——结果就是段错误。嗯，这在早期病毒中倒是常见手法，但现在操作系统早就防住了。

数据段

数据段存放全局变量和静态变量。它分为初始化数据段（.data）和未初始化数据段（.bss）。.bss在程序加载时会被清零，所以全局变量默认是0。

堆

堆是动态内存分配的区域。你用malloc、new、calloc分配的内存都在这里。堆向高地址增长，由程序员手动管理——分配了就要释放，否则就是内存泄漏。

栈

栈是函数调用的核心。每次调用函数，都会在栈上分配一个「栈帧」，存放局部变量、参数、返回地址等。栈向低地址增长，函数返回时自动释放。

栈的大小是有限的——Linux下默认8MB，Windows下默认1MB。如果你在函数里定义一个大数组，比如int arr[1000000]，很可能导致栈溢出。我见过一个新手写递归函数，没有终止条件，结果栈溢出——程序直接崩溃。

1.4 内存对齐与填充

内存对齐是个容易被忽视，但影响巨大的话题。说白了，就是数据在内存中的存放地址，要满足一定的对齐要求。

为什么需要对齐？因为CPU访问内存时，不是按字节来的，而是按「字」来的。32位CPU一次读4字节，64位CPU一次读8字节。如果数据没有对齐，CPU可能需要两次内存访问才能读完，性能下降。

举个例子：

struct Example {
    char a;    // 1字节
    int b;     // 4字节
    short c;   // 2字节
};

如果不考虑对齐，这个结构体的大小是1+4+2=7字节。但实际上，编译器会在a后面填充3个字节，让b对齐到4字节边界。最终结构体大小是12字节。

为什么会这样？因为int b需要4字节对齐，而a只占了1字节，所以编译器在a后面塞了3个「填充字节」，让b的起始地址是4的倍数。

我习惯在定义结构体时，把大的成员放在前面，小的放在后面，这样可以减少填充，节省内存。比如：

// 优化前：12字节
struct Bad {
    char a;
    int b;
    short c;
};

// 优化后：8字节
struct Good {
    int b;
    short c;
    char a;
};

你看，只是调整了成员的顺序，大小就从12字节降到了8字节。在嵌入式系统中，内存很宝贵，这种优化很有意义。

嗯，内存对齐还有一个坑：如果你用指针强制转换类型，可能会破坏对齐要求。比如：

char buffer[10];
int *p = (int *)&buffer[1];  // 地址不是4的倍数
*p = 12345;  // 可能崩溃！

这段代码在x86上可能还能运行（只是慢），但在ARM上直接崩溃——ARM要求严格对齐。所以，写跨平台代码时一定要注意。

好了，这一章的内容就到这里。内存是程序的基石，理解它，你才能写出安全、高效的代码。下一章我们聊聊指针本身——嗯，到时候见。