结构体与联合体的性能优化：缓存行对齐、减少内存碎片、避免不必要的拷贝

性能优化这事儿，说白了就是跟硬件打交道。你写再漂亮的代码，如果CPU缓存不买账、内存东一块西一块，那跑起来照样慢吞吞。我这些年做嵌入式项目，踩过不少坑，今天就把结构体和联合体相关的优化经验掰开揉碎讲给你听。

一、缓存行对齐：让CPU少跑冤枉路

现代CPU读取内存不是按字节来的，而是按「缓存行」——通常是64字节。你想想看，如果结构体成员刚好跨了两个缓存行，CPU就得读两次。我遇到过最夸张的情况，一个简单的结构体访问，因为对齐问题性能直接腰斩。

1.1 什么是缓存行对齐？

缓存行是CPU和内存之间的最小传输单位。比如你读一个4字节的int，CPU实际上会把它所在的64字节整块搬进缓存。如果结构体里的热点数据（频繁访问的成员）分散在不同缓存行，那就悲剧了——每次访问都可能触发缓存缺失。

// 糟糕的对齐：hot_flag和hot_counter可能跨缓存行
struct BadLayout {
    char padding[60];   // 填充到60字节
    int hot_flag;       // 偏移60，在第一个缓存行末尾
    int hot_counter;    // 偏移64，在第二个缓存行开头
};

// 好的对齐：热点数据紧挨着，放在同一缓存行
struct GoodLayout {
    int hot_flag;       // 偏移0
    int hot_counter;    // 偏移4
    char padding[56];   // 填充到64字节
};

我个人习惯是把频繁访问的成员放在结构体最前面，这样它们大概率落在同一个缓存行里。你想想看，一个循环里反复读写hot_flag和hot_counter，如果它们跨行，每次都要等内存，那性能能好吗？

1.2 使用alignas强制对齐

C11标准提供了alignas关键字，可以指定结构体的对齐边界。我在做网络协议栈时，经常用这个来让结构体对齐到缓存行边界。

#include <stdalign.h>

// 强制结构体按64字节对齐
struct alignas(64) CacheLineAligned {
    int data[16];  // 正好64字节
    // 其他成员...
};

// 检查对齐
_Static_assert(sizeof(CacheLineAligned) == 64, "Must be 64 bytes");

1.3 避免伪共享（False Sharing）

多线程场景下，两个线程各自修改不同变量，但这两个变量恰好在同一个缓存行里——这就是伪共享。每个线程修改自己的变量时，都会导致对方的缓存行失效，性能惨不忍睹。

// 伪共享：thread1_data和thread2_data在同一缓存行
struct SharedData {
    int thread1_data;
    int thread2_data;
};

// 解决方案：用填充隔离
struct alignas(64) IsolatedData {
    int thread1_data;
    char padding1[60];  // 填充到64字节
    int thread2_data;
    char padding2[60];  // 填充到64字节
};

我曾经在一个多线程日志系统里遇到过这个问题。两个线程各自写日志计数器，结果性能比单线程还差。排查了半天，发现就是伪共享搞的鬼。加上填充后，吞吐量直接翻了4倍。

二、减少内存碎片：让malloc不再头疼

嵌入式系统内存有限，碎片多了就容易OOM。结构体和联合体的布局设计，直接影响内存碎片程度。

2.1 按成员大小降序排列

C语言结构体的内存布局有个规律：编译器会按成员的自然对齐要求插入填充。如果你把大成员放前面，小成员放后面，填充最少，内存利用率最高。

// 糟糕的排列：产生大量填充
struct BadOrder {
    char a;      // 偏移0
    double b;    // 偏移8（因为double需要8字节对齐，中间填充7字节）
    int c;       // 偏移16
    char d;      // 偏移20
    // 总大小：24字节（实际只用了13字节）
};

// 好的排列：按大小降序
struct GoodOrder {
    double b;    // 偏移0
    int c;       // 偏移8
    char a;      // 偏移12
    char d;      // 偏移13
    // 总大小：16字节（填充3字节）
};

嗯，这里要注意：不是所有编译器都按这个规则优化。我建议你写完后用sizeof和offsetof检查一下实际布局。

2.2 联合体：共享内存的艺术

联合体可以让多个成员共享同一块内存。这在处理变体数据时特别有用——比如网络协议里的报文类型字段。

// 用联合体减少内存占用
union PacketData {
    struct {
        uint8_t type;
        uint16_t length;
        uint8_t payload[256];
    } data;
    struct {
        uint32_t header;
        uint8_t body[256];
    } raw;
};

// 实际使用时，根据type字段决定访问哪个成员
void process_packet(union PacketData *pkt) {
    if (pkt->data.type == 0x01) {
        // 处理data成员
    } else {
        // 处理raw成员
    }
}

我记得有一次做物联网网关，需要同时处理几十种传感器数据。如果用结构体硬编码，每个传感器类型都要分配独立内存，内存占用直接爆炸。换成联合体后，内存占用减少了70%。

2.3 使用柔性数组成员

C99引入了柔性数组成员，允许结构体最后一个成员是未指定长度的数组。这比用指针动态分配更紧凑，也减少了内存碎片。

// 柔性数组成员：避免额外指针开销
struct FlexibleArray {
    int length;
    char data[];  // 柔性数组，不占结构体大小
};

// 分配时一次性搞定
struct FlexibleArray *fa = malloc(sizeof(struct FlexibleArray) + 100);
fa->length = 100;
// data直接跟在结构体后面，没有额外指针

三、避免不必要的拷贝：能传指针就别传值

结构体拷贝是性能杀手。尤其是大结构体，一次拷贝可能触发几百字节的内存搬运。我见过有人把几百字节的结构体当函数参数传值，每次调用都拷贝一次，循环里调用几万次——那画面太美我不敢看。

3.1 传指针而非传值

// 糟糕：传值拷贝整个结构体
void process_data(struct BigStruct data) {
    // 处理data...
}

// 好：传指针，只拷贝4/8字节
void process_data(const struct BigStruct *data) {
    // 处理data...
}

你想想看，一个64字节的结构体，传值就是64字节的拷贝；传指针只有8字节（64位系统）。这差距不是一点半点。

3.2 使用const引用避免意外修改

传指针虽然快，但有个风险：函数内部可能不小心修改了原始数据。加上const修饰，既保证安全，又让编译器能做更多优化。

// 安全且高效
void print_info(const struct DeviceInfo *info) {
    printf("ID: %d, Name: %s\n", info->id, info->name);
    // info->id = 100;  // 编译错误，防止意外修改
}

3.3 返回结构体时用指针参数

函数返回结构体时，如果直接返回结构体值，编译器可能会生成临时拷贝。更好的做法是用指针参数「带出」结果。

// 不推荐：返回结构体值
struct BigStruct create_data(void) {
    struct BigStruct result;
    // 初始化result...
    return result;  // 可能触发拷贝
}

// 推荐：通过指针参数返回
void create_data(struct BigStruct *result) {
    // 直接操作result指针
    result->id = 1;
    // ...
}

我个人习惯是：小于等于16字节的结构体可以传值，更大的结构体一律传指针。这个阈值是我在实际项目中测出来的——16字节以下，传值和传指针的性能差异可以忽略。

四、知识体系总览

下面这张图总结了结构体与联合体性能优化的核心脉络，你可以对照着检查自己的代码。

五、实战避坑指南

最后分享几个我踩过的坑，希望能帮你少走弯路。

• 别迷信对齐：不是所有场景都需要缓存行对齐。如果你的结构体只在初始化时访问一次，对齐反而浪费内存。我一般只在热路径（hot path）上做对齐优化。
• 小心位域的性能陷阱：位域虽然省内存，但读写位域成员可能涉及多次内存访问。我在一个实时控制项目里用过位域，结果中断响应时间超标——后来改成普通成员，问题解决。
• 联合体的大小陷阱：联合体的大小等于最大成员的大小。如果你把一个大数组和一个小结构体放一起，联合体就会膨胀。我曾经把1024字节的缓冲区和几个int放一个联合体里，白白浪费了900多字节。
• 调试时关闭优化：编译器优化可能会改变结构体的内存布局。调试阶段建议用-O0，等验证通过再开优化。不然你可能会看到结构体成员地址跟你预期的不一样。

好了，关于结构体和联合体的性能优化，核心就是这三板斧：缓存行对齐、减少碎片、避免拷贝。你写代码的时候多想想CPU和内存是怎么工作的，很多优化方案自然就出来了。