上周代码评审一位同事提交了个用“与运算”优化的小改动把热点路径里的i % 8换成了i 7顺手把另外几处% 256、% 2也一并改掉。他附的压测数据让我愣住了——同一个批量任务平均耗时从 638ms 掉到 362ms几乎是砍掉四成。我当时第一反应是不信毕竟编译器又不是没有常量折叠这种取模不该早就被优化成位运算了吗可看了火焰图和几轮采样结果之后我开始相信问题出在我自己的认知上。这篇笔记不是让你背下几个等价式就完事而是要和你一起把原理、边界、坑和套路都理清。无论你是写 C、Go、Java 还是前端脚本只要代码里有循环、有取模、有热点这篇文章都值得看完——尤其是最后那个“为什么别人改完起飞我改完反而出了 bug”的部分。1. 一次让我愣住的代码评审只是换了个运算符耗时掉了四成1.1 那位同事到底改了几行代码那个改动本身特别朴素。模块里有一段批量处理逻辑循环要跑几十万次里面做了三件和数学运算相关的事按 8 个桶累计数据取下标要用i % 8按 256 字节切片偏移量要用i % 256每次循环判断当前序号是否为偶数那位同事的 diff 大概是这样的// 优化前 int bucket i % 8; int slice i % 256; bool even (i % 2 0);// 优化后 int bucket i 7; int slice i 255; bool even ((i 1) 0);如果你第一次看到这组替换多半会和我一样困惑%和不是两个完全不同的运算符吗凭什么能直接换别急原理留在下一节细说先把这个评审现场还原完。当时我还注意到一处哈希定位逻辑也被同一套思路改掉了原本是int slot hash % tableSize;改成int slot hash (tableSize - 1);前提是tableSize从 512 被调整成了 512 的等值条件它本来就是 2 的幂。那几处改动拼起来整个 diff 看起来非常小但压测数据一点都不小。1.2 压测数据是怎么得到的可信吗我特意问过那位同事数据来源。他是在一台固定压测机上用同一组数据跑 10 次取中间值并且给 JIT 留了预热轮次。我不能把所有数字照搬出来就列一下我们后来自己复测的相对结果版本平均耗时相对变化原始版本%系列写法638ms基准优化版本系列写法362ms下降约 43%必须说实话这个收益在不同语言、不同编译器下差异非常大。在 C/C 这类编译型语言里有些取模场景编译器自己就优化得不错收益未必这么夸张但在脚本语言或者 JIT 优化不到位的解释型环境里这组数据完全能复现甚至可能更快。这也解释了很多人的困惑为什么别人改完起飞自己在本地试了一处却感觉没变化。很简单你改的那个地方可能不在关键路径上或者编译器早就帮你做掉了。2. 位与为什么能这么快一条指令和一整套除法流程的差距2.1 位运算是 CPU 的“家常便饭”在处理器的世界里加法、位与、位或、移位这些操作本质上是由 ALU 里一堆逻辑门组合完成的输入一到位组合电路直接出结果通常一两个时钟周期就搞定。你可以把它理解成“瞄一眼开关就知道灯亮不亮”——这是硬件上最便宜、最快的操作之一。按位与的逻辑也很直白只有两个二进制位同时为 1结果才是 1。x 7做的事情说穿了就是“把 x 的二进制高位置成 0只留下最低的 3 位”。这个动作对 CPU 来说几乎不花力气。2.2 取模则拐到了“除法”这条慢路上取模运算x % M在数学上是“求 x 除以 M 的余数”但在 CPU 层面它往往要走到整数除法指令那条路上。整数除法是少数几个消耗大量周期的运算一条除法指令动辄消耗几十个周期再加上某些架构下除法单元的延迟和吞吐限制它比位运算贵一个数量级甚至更多。我习惯用一个类比来解释这个问题位运算是“刷卡进闸机”闸机抬杆就是一瞬间取模则是“人工核对订单”要先算出商品总价、再看你给的金额、计算找零。后者并不是不能做只是每一步都要多花时间。热点循环里塞满取模等于让 CPU 反复去“人工核对订单”。2.3 位与等价取模的数学道理为什么x 7能替代x % 8因为当模数是 2 的幂时余数只取决于低 n 位。假设M 2^n那么M - 1的二进制就是低 n 位全 1高位全 0。任意非负整数 x 都可以拆成“高位部分 低位部分”高位部分永远是2^n的倍数除以2^n余 0最后的余数就是低位部分本身。拿53 7举例53 的二进制是1101017 的二进制是000111位与结果是000101也就是 5而53 % 8也等于 5所以对于非负整数x (2^n - 1)与x % 2^n是完全一致的。关键是“非负”和“模数是 2 的幂”这两个前提一个都不能少。2.4 编译器没包办原因是负数你可能会问既然数学上这么简单编译器为什么不自动把常量取模替换成位运算答案藏在负数的语义里。C、C、Java、JavaScript 早期规范里负数取模的结果和数学定义并不完全一致很多语言选择向零截断。比如-7 % 8在 C/Java/JS 里结果是-7而-7 7按二进制算出来是1。想让编译器在取模位置上自动换用位与就必须先证明 x 非负。如果证明不了编译器就得插入符号判断和额外分支指令一多优化反而得不偿失。所以当编译器面对一个普通的x % 8只要它无法确定 x 非负就干脆保守地保留除法流程。人工介入的价值就在这里你比编译器更清楚业务里的 index 永远大于等于 0那层保险不需要位与就是最优解。3. 那几行代码到底换掉了什么五种高频场景的位优化方案3.1 哈希取模改掩码索引定位最经典的一刀哈希表里最常见的操作就是“给 key 找一个桶”hash % tableSize。把容量设为 2 的幂替换成hash (tableSize - 1)就能省掉一次昂贵的取模。int slot hash (tableSize - 1); // 前提tableSize 是 2 的幂为什么很多哈希表实现都偏爱 2 的幂容量其中一个重要原因正是这个用掩码替代取模索引计算路径极短。不少语言标准库的内部实现就是这么干的。如果你接手一个哈希表或缓存池第一件事就可以看它的容量是不是 2 的幂如果是这里大概率有优化空间。有次我接手一个缓存模块tableSize初始是 1000后来被改成 1024配合 1023压测里缓存命中路径的 CPU 占比肉眼可见地降了一截。但要注意如果使用场景依赖素数容量来打散哈希就别为了这点性能改变容量策略取舍要放在更全局的视角去看。3.2 奇偶判断看最低位就能定判断一个整数是奇数还是偶数最常见的写法是x % 2 0。但任何二进制数的最低一位是 1 就是奇数是 0 就是偶数。所以直接看最低位bool isEven ((x 1) 0);这行代码等价、直观还省去了一次取模。不过说实话这类小改动单看收益不大毕竟x % 2 0本身并不算特别贵。但它有个额外好处在某些解释型语言里位与操作不会触发数值类型的一堆隐式转换可以让代码更贴近真实的字节运算减少 JIT 的优化阻力。把它当成顺手就能做的小优化就好真正的大头还是热点里的取模。3.3 2 的幂判断一行位与消掉边界分支判断一个正整数是不是 2 的幂很多人会写循环除以 2。用位运算是这样的bool isPowerOfTwo(int n) { return n 0 ((n (n - 1)) 0); }原理其实很漂亮2 的幂在二进制里只有一个 1。n - 1会把最高位的 1 变成 0把后面的 0 全部变成 1n (n - 1)就等于把最低位的那个 1 消掉。如果结果是 0说明这个数原本只有一个 1。这个技巧特别适合做容量校验、对齐检查和掩码合法性判断。我后来在初始化环形缓冲区时就用它来保证 capacity 一定是 2 的幂一旦传入非法值就向上取整代码剪掉了整整一段循环。3.4 RGB 提取掩码保底的高频操作如果你的代码碰过图像处理大概率写过这种像素提取int r (pixel 16) 0xFF; int g (pixel 8) 0xFF; int b pixel 0xFF;这里 0xFF的作用就是把高位全部清零只保留最低 8 位。它不是为了替代取模而是位掩码的经典应用。这类写法不只是快还能避免一堆边界判断因为你不需要担心右移之后的高位残留一个掩码全部搞定。这个场景也让我真正理解了一点与运算的核心价值不只在“替代取模”更在于它是位掩码的基本工具专门用来“切出”二进制里某一段内容。3.5 状态开关一个整型装下几十个布尔还有一个很多人日常在写、但不一定知道自己用了位运算的场景状态标志位。const uint32_t FLAG_READABLE 1 0; const uint32_t FLAG_WRITABLE 1 1; const uint32_t FLAG_LOCKED 1 2; uint32_t flags 0; flags | FLAG_READABLE; // 打开读权限 bool locked (flags FLAG_LOCKED) ! 0; // 判断是否上锁 flags ~FLAG_LOCKED; // 解除上锁这里面的“判断是否上锁”就是一次与运算“打开/关闭”是或运算和与非运算的组合。一个 32 位整型能管理 32 个独立的开关状态内存占用极小判断速度极快配置项一多的时候尤其划算。这个思路在下一章我会展开聊。4. 我第一次照抄就踩歪了等价替换背后藏着三个硬前提4.1 负数面前与运算和取模根本不对等这是最阴的一个坑。很多语言里int a -7 % 8; // 在 C/Java/JS 里结果是 -7 int b -7 7; // 结果是 1a和b完全不一样。更麻烦的是 Python 这类语言里-7 % 8的结果是 1反而和-7 7一致。不同语言的行为还不统一你在这个语言踩完坑换到另一个语言可能又踩一遍。我见过一个实际案例有位同学优化库存余量计算把(count % slotCount)直接换成(count (slotCount - 1))。正常情况下没问题但业务里 count 偶尔会出现暂态负数结果直接变成错误槽位。排查了大半天最后发现是负数语义作祟。从此我给自己定了个规矩只要操作数可能为负一律不碰位运算等价替换或者先取绝对值、先 clamp 到非负区间再说。4.2 位与不是逻辑与短路逻辑会被弄丢有些同学听说比快就顺手把布尔判断里的改成了。这是完全不同的两回事。if (a ! null a.size 0) { // 错误示范a 为 null 时后半段仍会被求值直接抛异常 }逻辑与是短路运算左边为假右边根本不会执行位与没有短路能力两边的表达式都会被老老实实求值一遍。把换成不是等价替换而是把一个“有保护的条件判断”换成了“无保护的位运算”等于自己把安全网拆了。4.3 模数必须是 2 的幂差一位结果差之千里x (M - 1)想等价于x % MM 必须是 2 的幂。很多人会误以为“只要位数足够就行”比如想把x % 10优化掉随手改成x 9。我们算一下19 对 10 取模是 9但19 9等于10011 01001结果是00001也就是 1。一次错误优化直接改变了业务结果。不要觉得这条很基础实际踩坑的人真不少。有人在做内存池时把容量设成 10想把取模改成位掩码结果数据分布完全错乱。模数不是 2 的幂就老老实实保留取模或者先调整数据结构把容量改为 16 之后再谈优化。4.4 可读性与收益边界不是所有取模都值得动位运算代码最大的“代价”是读起来不直观。i % 8任何人一看就懂“对 8 取模”i 7如果没注释读者得先在脑内补一行“7 是 2^3 - 1”。一个项目里如果到处是这种改写又没有注释后维护者大概率会一脸懵甚至好心帮你“改回正常人写法”。我自己的判断标准是四个条件同时满足才动手热点、模数是 2 的幂、操作数非负、有注释说明前提。缺一个都不改。另外改完之后一定留一个测试用例把优化前后的计算结果各跑一遍确认完全一致。有次我在某模块里优化了三处取模跑完单测发现其中一处在边界条件下结果不同幸好测试兜住了。5. 顺着这条思路我在三个模块里又抠出了三成余量5.1 位掩码管理状态开关离开最初那个案例之后我把位运算用到了状态管理上。以前配置类代码里常见五六个布尔变量每个字段占一个位逻辑判断多还容易漏。后来改成位掩码const uint32_t FLAG_A 1 0; const uint32_t FLAG_B 1 1; const uint32_t FLAG_C 1 2; uint32_t flags FLAG_A | FLAG_C;判断一个特性是否开启一次flags FLAG_B就够了。十几个配置项压缩成一个整型结构体变小了缓存命中率也更好。这个模式在权限系统、功能开关、缓存状态里都适用而且它不挑剔语言C、Go、Java、JavaScript 都能写。5.2 环形缓冲区的读写下标另一个收益明显的地方是环形缓冲区。生产者消费者模型里的常见写法是writePos % capacity如果 capacity 固定为 2 的幂就可以换成int pos writePos (capacity - 1); buffer[pos] item; writePos;writePos一直累加 (capacity - 1)自动把位置约束在 0 到 capacity-1 之间效果和取模完全一样但省掉了每次写入时的除法开销。这里是真正的高频热路径数据包一个接一个地写省一次是一次。我做过一次小实验环形缓冲区写入路径上只改这一处模块整体吞吐就提升了十几个百分点。对比最初那个“耗时砍半”的场景这个收益更接近普通项目的真实水平。5.3 优化方法论先量后改落在热点上回到那位同事的案例他做对的最关键一步不是掌握了位运算技巧而是先做了性能剖析。他是在压测和火焰图上确认那几个取模函数是真正的 CPU 大头之后才动的手。我现在看到代码里的%第一反应也不是急着改成而是先问自己三句话这个操作数可能为负吗模数是 2 的幂吗编译器是否已经知道它非负这三问过完“改”还是“不改”基本就有答案了。如果答案是需要改我还会再加一步在代码旁写清楚前提条件。注释不用长一行就够int idx pos 127; // pos 0 且 buffer 容量为 128等价于 pos % 128真正会拖垮性能的从来不是孤零零的一次取模而是在大规模循环里反复执行的取模。在没有 profile 数据之前谈优化多半是自我感动有了 profile 数据之后位运算才是一把用得准的手术刀。如今我写代码再遇到%心态已经很平稳了。位运算不是什么高深魔法它只是一门我们很少主动使用的“母语”而已。那位同事让我真正学会的也不是那几行 diff而是带着约束去优化先看懂硬件在干什么再去找值得动手的地方。翻过这道坎之后再看那些“运行效率直接起飞”的改动你就会明白它们背后其实全都站着同一句话永远把最贵的运算留给唯一需要它的人。