HikariTish

1. 空间预分配（Space Preallocation）#

• 作用：优化字符串的**增长（拼接）**操作。
• 机制：当对 SDS 进行扩容时，Redis 不仅仅分配刚好够用的空间，还会多分配一些额外的备用空间，从而极大地提升后续拼接短字符串的性能。

2. 惰性空间释放（Lazy Freeing）#

• 作用：优化字符串的**缩短（截断）**操作。
• 机制：当缩短 SDS 时，Redis 不会立即回收多出来的内存，而是将其保留在 alloc 中。若将来再次追加内容，可直接复用这部分闲置内存，防止频繁回收和分配。

5.1 痛点：Redis 3.2 之前的”一刀切”设计#

在 Redis 3.2 之前，SDS 只有一个通用的结构体。我们假设在 64 位系统下，它大概长这样（简化版）：

1
struct sdshdr {
2
    unsigned int len;  // 已用长度，占用 4 字节
3
    unsigned int free; // 剩余可用长度，占用 4 字节
4
    char buf[];        // 字符数组
5
};

问题在哪里？

如果你仅仅想存一个非常短的字符串，比如 "OK"（2 个字节），Redis 依然需要为你分配 4 + 4 = 8 个字节的元数据（len 和 free）。这就造成了元数据的开销比实际数据还要大的尴尬局面，对于 Redis 这种极其依赖内存的数据库来说，这是不可接受的浪费。

5.2 破局：Redis 3.2 的”按需分配”（sdshdr5 到 sdshdr64）#

为了解决这个问题，Redis 3.2 的作者决定：根据字符串的实际长度，使用不同大小的整数类型来记录长度属性。

Redis 将 SDS 细分为了 5 种类型。核心变化在于 len（已用长度）和 alloc（分配长度）的数据类型变化：

优化效果显著：

现在，如果你再存一个 "OK"，Redis 会自动选择 sdshdr8（实际上 sdshdr5 因为没有预分配空间的能力，在实际更新字符串时容易引发重新分配，因此 Redis 目前对短字符串默认直接使用 sdshdr8）。使用 sdshdr8 后，元数据从原本的 8 字节压缩到了 3 字节（len 1 字节 + alloc 1 字节 + flags 1 字节），大大节省了小对象的内存占用。

5.3 绝杀考点：C 语言的内存对齐与 __attribute__ ((__packed__))#

如果你只是背出了上面的几种类型，只能算及格。想要拿高分，必须提到”取消编译器的内存对齐”。

在 C/C++ 中，编译器为了让 CPU 读取内存更高效，默认会进行内存对齐（Memory Alignment）。比如一个结构体里有 char（1 字节）和 int（4 字节），编译器可能会在 char 后面填充 3 个字节的空白，让它凑够 4 的倍数。

如果在 SDS 中发生这种填充，我们好不容易通过缩小 len 数据类型省下来的内存，又被编译器填补的空白吃回去了！

因此，Redis 在定义这几个新的 SDS 结构体时，使用了一个特殊的编译器指令：__attribute__ ((__packed__))。

它的作用有两个：

1. 极致省空间：告诉编译器，绝对不要进行任何内存对齐填充，结构体里的字段必须严丝合缝地挨在一起。
2. 指针偏移的妙用：在 SDS 中，每次函数传递的其实是真正指向数据的 buf 指针（为了兼容 C 标准库函数）。因为取消了内存对齐，Redis 确切地知道，buf 指针往前退刚好 1 个字节（buf[-1]），就必定是 flags 字段。通过读取 flags 的低 3 位，Redis 就能立刻知道当前是哪种 sdshdr 类型，进而推算出 len 和 alloc 的位置。

💡 结合 Go 后端的思考：

在你熟悉的 Go 语言中，字符串的底层实现 StringHeader 包含一个 Data uintptr（指针）和一个 Len int（长度）。在 64 位系统下，一个 Go 字符串本身的结构体开销固定就是 16 字节。

对比之下，你会发现 Redis 为了在 C 语言层面抠这几个字节的内存，可谓是将底层优化做到了极致。这种对比思维在面试中非常加分。