循环数组（也叫环形缓冲区、环形队列）是编程中非常常见的数据结构，广泛应用于网络收发包队列、音频缓冲、日志环形写入等场景。它的核心问题只有一个：当索引越过数组末尾时，如何正确地绕回到数组开头。绝大多数人的第一反应是用取模运算 i % n，这个写法确实正确，但在性能敏感的热路径上，取模可能成为隐藏的性能瓶颈。本文围绕索引相对偏移量的计算，详细分析几种优化思路及其适用条件。
为什么取模运算会成为性能瓶颈
从功能上看，(i + offset) % n 完全正确：索引加上偏移量后对数组长度取模，结果必然落在 0 到 n-1 之间。问题出在硬件层面。在现代CPU上，加减法和位运算只需要1个甚至半个时钟周期，而整数除法指令（取模通常依赖除法实现）在x86-64架构上需要20到40个时钟周期不等，两者差距可能达到20倍以上。
编译器并非不作为。如果除数是编译期常量，比如 x % 16，现代编译器会自动把它改写为位运算 x & 15，代价极低。但如果数组长度是运行时变量（比如环形缓冲区按配置动态分配），编译器无法做这个变换，每次取模都会生成真实的除法指令。更糟糕的是，除法指令是完全串行的流水线阻塞点，它不能与其他指令良好地并行，在每秒调用百万次的入队出队循环里，这个开销会被急剧放大。
此外还有一个容易被忽视的正确性坑：在C、C++、Java等语言中，负数取模的结果可能为负。例如 -1 % 8 在C++中结果是 -1，直接用它做数组下标会越界。写法上需要额外处理，比如 ((i % n) + n) % n 或者判断符号后修正，这又引入了分支和额外运算。
位运算优化：让数组长度保持2的幂
最经典也最有效的优化手段，是把循环数组的长度约束为2的幂（如1024、4096、16384），此时取模可以退化为按位与：
#define BUF_SIZE 4096 // 必须是2的幂 #define BUF_MASK (BUF_SIZE - 1) // 传统写法 size_t idx1 = (head + offset) % BUF_SIZE; // 优化写法：位与替代取模 size_t idx2 = (head + offset) & BUF_MASK;
当n是2的幂时，x % n 与 x & (n-1) 在非负整数上完全等价，因为2的幂的二进制形式是1后面跟若干个0，减1之后低位全为1，按位与正好保留x的低几位，丢弃高位，效果就是绕回。这个变换只需1个时钟周期，还不需要访问内存中的除数。
使用这个方案要注意两点。第一，索引变量建议用无符号类型（C/C++中用 size_t 或 uint32_t），这样即使 head + offset 发生回绕，无符号溢出在C标准中是良定义的，按位与的结果依然正确，这比有符号数的溢出未定义行为安全得多。第二，如果长度不能强制为2的幂（比如协议规定缓冲区必须是1500字节），可以采用向上取2的幂并浪费少量空间的折中方案，很多高性能网络库正是这么做的。
递增索引加延迟取模：根本不做绕回计算
另一种思路更彻底：索引自始至终不取模，让它一直单调递增，只在真正访问内存的那一刻才做一次按位与。这是Linux内核环形缓冲区（如KFIFO）和无锁队列的常见设计：
struct ring {
uint32_t in; // 只增不减的逻辑写指针
uint32_t out; // 只增不减的逻辑读指针
uint8_t data[4096];
};
void ring_put(struct ring *r, uint8_t v) {
// 先用逻辑指针算出物理下标，再写入，指针本身永不回绕
r->data[r->in & 4095] = v;
r->in++;
}
uint8_t ring_get(struct ring *r) {
uint8_t v = r->data[r->out & 4095];
r->out++;
return v;
}
这种设计的精妙之处在于把“位置”和“下标”分离了。in 和 out 是逻辑位置，单调递增永不回绕，判断队列是否为满只需比较 in - out == 4096，判断是否为空只需比较 in == out，完全不需要区分“满”和“空”这两种状态的传统难题（传统写法中head等于tail既可能是空也可能是满，必须额外留一个空位或维护计数器）。
只要用32位无符号整数，按每秒千万次操作计算，回绕一次也需要大约7分钟，而且回绕本身也不影响正确性，因为差值和按位与的运算对回绕是封闭的。唯一的前提是 in 和 out 的差值不能超过缓冲区容量，这在正常使用中天然满足。
条件判断替代取模：适用于长度任意的场景
当数组长度既不能改成2的幂，又想避免除法时，可以用比较和减法来模拟绕回。思路是：先加上偏移量，如果结果超出范围就减去一个n：
// 前提：0 <= offset < n
size_t advance(size_t i, size_t offset, size_t n) {
size_t j = i + offset;
if (j >= n) {
j -= n; // offset < n 时最多减一次即可
}
return j;
}
这个写法的前提是 offset < n，此时最多只需要减一次。一次比较加一次减法的开销远低于除法，而且现代CPU的分支预测器在这种规律性极强的循环中命中率非常高，误预测代价几乎可以忽略。如果偏移量范围不可控，可以先用 offset %= n 归一化一次，再进入循环内的快速路径。
还有一种介于两者之间的通用技巧：用减法循环替代取模，虽然复杂度更高，但在某些嵌入式平台（没有硬件除法器的ARM Cortex-M0等）上反而更快。判断标准很简单——如果目标平台有硬件除法器且除数是变量，优先考虑本节的比较法；如果是Cortex-M0这类无除法器的平台，任何能避开除法的方案都值得。
不同方案的对比与选型建议
把上述方案整理成表格，方便对照选择：
| 方案 | 适用条件 | 相对开销 | 正确性风险 |
|---|---|---|---|
| 直接取模 % | 任意长度 | 高（除法指令） | 负数结果需修正 |
| 位与 & | 长度为2的幂 | 极低 | 长度约束需静态保证 |
| 递增索引延迟掩码 | 长度为2的幂 | 极低，且简化满空判断 | 差值不能超过容量 |
| 比较减法 | 长度任意，offset<n | 低 | 需保证offset范围 |
实际选型时建议遵循这样的顺序：首先看长度能否约定为2的幂，能则直接用位与或递增索引方案，这是一劳永逸的做法；其次看偏移量是否可控在长度以内，可控则用比较减法；实在不行才保留运行时取模，并且务必使用无符号类型规避负数问题。
最后提醒一点：不要过早优化。取模的开销只有在每秒百万级调用的高频路径上才值得计较，普通业务代码里 % n 的可读性价值更高。优化的正确姿势是先用性能分析工具确认热点确实落在索引计算上，再动手改造，同时用单元测试覆盖边界情况（索引恰好在末尾、偏移量恰好等于长度等），确保优化不引入正确性回归。