16、调试内存布局：使用offsetof宏、使用sizeof验证、使用GDB查看内存布局
说实话，内存对齐这东西，光看书总觉得懂了，一写代码就露馅。我见过太多人把结构体定义得漂漂亮亮，结果实际占用的内存比预期大了一圈，还死活找不到原因。
今天咱们就来点实在的——怎么把内存布局"看"清楚。三种手段：offsetof宏、sizeof运算符、GDB调试器。各有各的用处，配合起来用，基本没有看不透的结构体。
16.1 offsetof宏：精准定位每个成员
offsetof定义在<stddef.h>里，能告诉你某个成员在结构体中的偏移量（从0开始算）。说白了，就是"这个成员离结构体开头有多远"。
#include <stdio.h>
#include <stddef.h>
typedef struct {
char a; // 1字节
int b; // 4字节
short c; // 2字节
} MyStruct;
int main() {
printf("offsetof(a) = %zu\n", offsetof(MyStruct, a));
printf("offsetof(b) = %zu\n", offsetof(MyStruct, b));
printf("offsetof(c) = %zu\n", offsetof(MyStruct, c));
printf("sizeof(MyStruct) = %zu\n", sizeof(MyStruct));
return 0;
}
猜猜输出是什么？
offsetof(a) = 0
offsetof(b) = 4
offsetof(c) = 8
sizeof(MyStruct) = 12
嗯，a在偏移0，没问题。b在偏移4——为什么不是1？因为int要4字节对齐，编译器在a后面塞了3个填充字节。c在偏移8，紧跟着b，但整个结构体大小是12，不是10。为什么？因为结构体末尾也要对齐到最大成员（int的4字节）的整数倍，所以又补了2个字节。
关键点：offsetof返回的是编译器实际布局中的偏移量，不是你以为的"累加大小"。填充字节全算进去了。
16.2 sizeof验证：看整体大小
sizeof能告诉你结构体总共占多少字节。配合offsetof，就能反推出填充字节的位置和数量。
我个人习惯这样验证：
typedef struct {
char a;
int b;
short c;
} MyStruct;
// 手动计算：a(1) + 填充(3) + b(4) + c(2) + 填充(2) = 12
// sizeof 验证：12 ✓
我在项目中遇到过一个问题：一个结构体里塞了各种类型的成员，sizeof出来是64字节，但我觉得应该只有48。一查，原来是成员顺序没排好，填充字节占了16个字节。重新排了顺序后，直接降到52字节。在嵌入式系统里，这12字节可能就是压死骆驼的最后一根稻草。
小技巧：把大的成员（如double、long long）放在前面，小的成员（如char、short）放在后面，能减少填充字节。但要注意，这可能会影响可读性，自己权衡。
16.3 GDB查看内存布局：眼见为实
代码跑起来之后，GDB能让你直接看内存里的"原始模样"。这比任何理论分析都直观。
假设我们有这段代码：
#include <stdio.h>
typedef struct {
char a;
int b;
short c;
} MyStruct;
int main() {
MyStruct s = {'A', 0x12345678, 0xABCD};
printf("sizeof = %zu\n", sizeof(s));
return 0;
}
用GDB调试：
$ gcc -g -o test test.c
$ gdb ./test
(gdb) break main
(gdb) run
(gdb) next
(gdb) print s
$1 = {a = 65 'A', b = 305419896, c = -21555}
(gdb) print &s
$2 = (MyStruct *) 0x7fffffffe4a0
(gdb) x/12bx 0x7fffffffe4a0
0x7fffffffe4a0: 0x41 0x00 0x00 0x00 0x78 0x56 0x34 0x12
0x7fffffffe4a8: 0xcd 0xab 0x00 0x00
看到了吗？
- 地址0x7fffffffe4a0：
0x41（'A'的ASCII码） - 地址0x7fffffffe4a1~0x7fffffffe4a3：三个
0x00（填充字节） - 地址0x7fffffffe4a4~0x7fffffffe4a7：
0x78 0x56 0x34 0x12（b的值，小端序） - 地址0x7fffffffe4a8~0x7fffffffe4a9：
0xcd 0xab（c的值，小端序） - 地址0x7fffffffe4aa~0x7fffffffe4ab：两个
0x00（末尾填充）
一共12字节，跟sizeof和offsetof算出来的一模一样。
注意：GDB的x/12bx命令表示"以16进制格式显示12个字节"。如果你用的是大端序机器，字节顺序会反过来。不过现在x86和ARM基本都是小端序，问题不大。
16.4 三种手段配合使用
这三种方法各有侧重：
| 方法 | 能看什么 | 什么时候用 |
|---|---|---|
offsetof |
每个成员的偏移量 | 写代码时验证布局是否符合预期 |
sizeof |
结构体总大小 | 快速判断有没有"浪费"空间 |
| GDB | 内存中的原始字节 | 调试时确认实际存储情况 |
我曾经在一个网络协议栈的项目里，用这三种方法抓到了一个隐蔽的bug。结构体里有个位域成员，理论上应该只占3位，但sizeof显示整个结构体比预期大了4字节。用offsetof一查，发现位域后面的成员偏移量不对。再用GDB一看内存——好家伙，编译器把位域和后面的成员之间塞了3个填充字节，因为位域的类型是int，对齐要求是4字节。改成型unsigned char后，问题解决。
我的建议：写结构体时，先用offsetof和sizeof验证一遍布局。如果发现不对劲，再用GDB看内存。别等到运行时出问题了再回头查，那时候定位成本就高了。
16.5 知识体系图
下面这张图总结了本章的核心逻辑：
嗯，到这里你应该已经掌握了三种调试内存布局的方法。下次再遇到结构体大小不对、成员偏移量奇怪的问题，别急着怀疑编译器——先用offsetof看看偏移，用sizeof算算大小，再用GDB看看内存。三步走完，问题基本就水落石出了。
公众号:蓝海资料掘金营，微信deep3321