某天我盯着火焰图发愣一个日请求量很大的内部接口光取模运算就占了将近两成的CPU采样。同一周某同事在另一个项目里改了几行代码核心手法就是用“与运算”替代取模把一堆%换成耗时几乎减半。这两件事说的其实是同一个道理善用与运算等于把CPU里最便宜的指令放到最热的地方代码没多几行运行效率却直接起飞。按位与在大部分语言里写作它之所以能带来肉眼可见的提速是因为它对应 CPU 的单周期 ALU 指令而取模%在多数架构上要调用除法器甚至走微码。但这里没有玄学有的是明确的适用前提、典型的应用场景和一堆容易踩的边角。这篇会把当时的优化思路、能直接照抄的五个场景、从定位热点到安全上线的完整路径以及后来踩过的坑一次讲透。适合谁看不限定语言写过 Java、C/C、Go、Rust 或者 JavaScript又跟性能较过劲的人应该都能从这里拿走一点能用的东西。1. 先搞明白与运算凭什么让效率起飞1.1 一条指令和一台除法器CPU 执行a b的时候就是把 a、b 两个操作数对应的二进制位逐一比对只有当两个位都是 1 时结果位才是 1。这个过程在现代 CPU 的 ALU 里一个时钟周期就能完成没有隐藏分支、没有微码循环是整个指令集里最便宜的运算之一。a % b是另一回事。以最常见的 x86 为例有符号整数除法走idiv无符号走div这两条指令的延迟通常在 20 到 80 个周期之间比加减乘慢一个数量级。更麻烦的是除法是少数几条会“打断流水线”的重指令之一CPU 很难用乱序执行去掩盖它的延迟。所以哪怕是几条取模出现在循环里对热点函数的伤害也可能被放大好几倍。这里得说句公道话编译器并不蠢。在 Java 里如果除数是编译期常量 16JVM 的 C2 编译器会把%换算成魔数乘法加移位性能差距会被大幅压缩。在 C/C 里开-O2后gcc 和 clang 对常量除法也有类似优化。真正吃亏的是“运行时才知道除数”的场景比如hash % capacity里的 capacity 是业务代码算出来的编译器只能老实生成除法指令。所以优化要瞄准的是热循环里除数不可预测的那些取模。1.2 成立的前提除数是 2 的幂与运算替代取模能用的前提只有一个除数必须是 2 的幂。原因要从二进制说。取模n % b的意思是让结果落在[0, b-1]区间内。当b 2^k时b 的二进制特征是最高位是 1低 k 位全是 0而b-1的二进制特征是低 k 位全是 1高位全是 0。一个数对 b 取模结果恰好就是这个数的低 k 位也就是n (b-1)。举例b 16即2^415的二进制是00001111。任何整数和 15 做按位与留下来的就是低四位的值范围必然是 0 到 15和n % 16在非负整数上完全等价。反过来除数一旦不是 2 的幂比如 10 的二进制是00001010低位不构成一个连续的全 1 掩码此时拿n 9去冒充n % 10就是纯粹的错误。所以口诀就一句话只有除数是 2 的幂 (b-1)才能等价替换% b。1.3 收益有多大从五倍到两成取决于场景我后来在项目里做过一次粗粒度的内联基准测试一亿次% 64和一亿次 63在普通服务器 CPU 上前者耗时大约是后者的 5 到 8 倍。不过这个数字在不同语言下波动剧烈C 语言开-O2之后常量除法会被编译器优化成移位序列差距明显缩小Java 在 JIT 充分预热后同理。反过来如果除数是运行期变量C 和 Java 都只能硬算除法差距往往回到 5 倍以上。所以在实际汇报里我不会说“与运算快十倍”而是说“在能用且确实热点的前提下收益是确定、可观的量级在显著到翻倍之间”。真正的结论要靠压测来定而不是靠某个基准测试的单个数字。这也是下面整个实操流程的起点先量化再动手。2. 能直接落地的五个高频场景2.1 哈希表定位HashMap 早就是这么干的最经典的场景是哈希桶定位。JDK 的 HashMap 源码里就用(n - 1) hash来算桶下标前提是 n 为 2 的幂Java 8 之后 HashMap 在扩容时也刻意把容量对齐到 2 的幂就为这一行位运算。我自己写固定容量的内存索引表时第一版是hash % capacity压测后这行成了热点。改成hash (capacity - 1)之前我先做了一件事确认 capacity 初始化成 2 的幂并加了启动断言。这里有个细节哈希值如果是负数的结果和 Java 取模的语义不同但因为我们只关心桶下标均匀性和合法范围负数经过掩码后落在正确区间即可不需要额外归一化。可如果业务上要求“序号从 0 递增”就必须先处理符号位再入表这点在单元测试里要钉死。2.2 环形缓冲区的下标回绕环形队列、滑动窗口、订阅缓冲里最常见的一句是pos (pos 1) % capacity。当 capacity 是 2 的幂时直接改成pos (pos 1) (capacity - 1)。这个改法的价值不只是省掉除法。很多人写环形缓冲时会在边界上犯错pos 到达 capacity - 1 之后(pos 1) % capacity能不能正确回到 0取决于他们有没有把 capacity 当成变量来用。用掩码之后回绕是自带的语义不需要额外的 if 判断边界错的可能性反而更低。当然前提依然是 capacity 全程保持 2 的幂。如果某个版本有人把它改成了 1000掩码就会完全失效。为了避免这种隐患我在代码里会把常量命名成QUEUE_CAPACITY_POW2这种带约束的名字让后面接手的人一眼看到约束。2.3 奇偶判断循环里最隐蔽的成本i % 2在很多人眼里是零成本其实在热循环里它一样要过除法器。做图像处理、按行分批、红黑交替绘制这类逻辑时循环体动辄执行几十万次if (i % 2 0)改成if ((i 1) 0)是几分钟就能完成的低风险改动。不过要泼一点冷水在 C 语言里编译器通常会把常量 2 的取模自动折叠成 1Java 的 JIT 也有类似处理。所以这个场景真正的收益场景是除数为运行期变量的时候比如if ((i % batchSize) 0)batchSize 是从配置中心读的。这时候编译器没法预知除数位运算才有立足之地。改的时候注意括号(i 1) 0的括号不能省位运算在多数语言里的优先级低于比较运算少一对括号语义就变了。2.4 内存对齐向上取整也能用与运算做内存池、序列化缓冲、缓存行对齐时常用公式(size 63) / 64 * 64做向上取整。与运算版本是size_t aligned (size 63) ~63ULL;~63的二进制是低 6 位全 0、高位全 1 ~63的本质是把低 6 位砍掉。先加 63 再砍就实现了向上取整size ~63ULL则是向下取整。这套写法在 C/C 里非常常见因为内存对齐本身就是二进制世界的概念堆分配器的 size class、消息队列的 slot 大小、序列化缓冲区的写入位置经常就是靠这类掩码算出来的。这里有个细节~63ULL还是~63表面上差别不大但显式写无符号字面量能让意图更清晰也能避免在 32 位平台上整型宽度不同带来的意外。我见过不止一次因为漏了 ULL 后缀导致在不同架构上出现“有时候对、有时候错”的鬼畜问题。2.5 判断 2 的幂一个经典一行实现判断一个数是不是 2 的幂最直观的写法是循环除 2直到除不尽最后看看剩下来的数是不是 1。这个循环没几行但在哈希表扩容、内存池请求 size class 这类高频路径上每跑一次都是一串除法指令而且写得不对还容易漏掉 0 和负数的边界。与运算一行就能把这个过程收敛成常数时间且边界天然干净bool is_power_of_two(uint32_t n) { return n ! 0 (n (n - 1)) 0; }原理很妙2 的幂在二进制里只有一个位是 1减 1 之后这个位变成 0它右边的位全部变成 1两者按位与的结果必为 0。反过来任何不是 2 的幂的数二进制里至少有两个 1减 1 之后仍然至少有一个 1 位与原来的 1 重叠结果就不可能为 0。注意n ! 0这个条件不能省0 的二进制全是 00 (0 - 1)也等于 0不排除 0 就会误判。这个函数在哈希表扩容、内存池 size class 判断、位图管理里都有实际用途是系统程序员必须背下来的经典。3. 实操过程从定位热点到安全上线3.1 第一步永远是 profile不是猜那几行被评价为“效率起飞”的代码不是某天拍脑袋改出来的。过程是先压测、抓火焰图、看热点函数发现一处高频分发逻辑里连续出现多个除法相关指令样本占比非常高。再切面确认全是同一类操作对运行期变量做取模。给新手的建议是没上 profiler 之前先别谈优化。Java 可以用 async-profiler 或 JFRC/C 用 perfGo 直接 pprof先把“时间到底花在哪”变成一张可验证的图。没有这一步再漂亮的位运算都只是在给自己找心理安慰。优化领域的铁律是先量化再动手改完再量化。3.2 改写前的代码长什么样假设场景是一个消息分发器它根据消息序号决定投递到哪个批次、哪个槽位// 改写前 int batchIndex sequence % batchCapacity; // batchCapacity 运行期计算 int slotIndex (sequence / slotSize) % slotCapacity; if (sequence % checkpointInterval 0) { flush(); }这段逻辑本身不复杂问题在于它处在一个每秒调用几十万次的热路径上。三个%全部是运行期变量的除法火焰图上占比非常高。batchCapacity、slotCapacity、checkpointInterval都是从配置中心读出来的编译器根本无法把它们当常量优化只能逐条生成除法指令。3.3 改写后的与运算版本和配置侧对齐之后把几个容量全部收敛成 2 的幂改写如下// 改写后要求 batchCapacity、slotCapacity、checkpointInterval 均为 2 的幂 int batchIndex sequence (batchCapacity - 1); int slotIndex (sequence / slotSize) (slotCapacity - 1); if ((sequence (checkpointInterval - 1)) 0) { flush(); }注意第二行的sequence / slotSize保留了下来因为它不是取模语义不能用与运算替代。如果 slotSize 恰好也是 2 的幂那可以进一步右移sequence log2(slotSize)但那是右移的优化不属于与运算的范畴。这里的原则是不要为了秀操作把不该省的除法也硬改成位运算那样只会引入逻辑错误。最后一行判断 sequence 是否是 checkpointInterval 的整数倍这个约束必须写进配置文档和启动校验。因为一旦有人把检查周期从 64 改成 100这一行就会静默失效而且不会抛任何异常数据层面可能好几个月后才暴露出问题。3.4 参数选择与边界验证把容量收敛到 2 的幂说起来简单做起来有几个点要盯住。容量调整会影响内存占用。比如原来批次容量是 1000对齐到 1024 只多出 2.4%可以接受如果原来是 500对齐到 512 也是 2.4%但原来如果是 300对齐到 512 就凭空多占 70% 以上这时候就不能无脑对齐得重新审视设计。所以“对齐到 2 的幂”不是免费午餐它是在用一点空间换时间空间成本必须算清楚。负数边界要单独验证。位运算和取模在负数上的语义不一致-7 % 8在 Java 里等于-7而(-7) 7等于1。如果数据流里可能出现负数序号要么先归一化要么明确接受“落在一个合法但非预期下标”的行为并且用单元测试把-1、-capacity、capacity - 1这些边界值全部覆盖。最后重构类优化要加随机对照测试。我们当时给这次改写专门加了一组测试同一个输入序列分别跑%版本和版本逐一断言桶下标完全一致。这一步能在上线前把绝大多数语义偏差揪出来成本低、收益极其确定。4. 踩坑实录与运算不是银弹4.1 最大的坑把非 2 的幂硬套位运算我见过一次线上故障起因就是有人把n % 10优化成了n 9还觉得“9 就是 10 减 1逻辑没问题”。这显然不成立10 不是 2 的幂n 9的结果既不均匀也不等价。这种 bug 的可怕之处在于它不一定会崩溃只是概率性地错乱而且错的数据看起来还有规律排查极其痛苦。所以凡是把分母收敛成 2 的幂我都在代码里加启动断言Preconditions.checkArgument((capacity (capacity - 1)) 0, capacity must be power of two);C 语言可以用assertGo 在配置加载时检查。这样即使将来有人把容量配置改成 1000系统会在启动那一刻直接报错而不是在运行几个月后冒出诡异数据。这一条是位运算优化的保险丝。4.2 符号位的陷阱负数取模语义不一样前面已经提过-7 % 8和(-7) 7结果不一致。更麻烦的是在 C/C 里负数取模的结果在不同标准下的定义甚至不一样C99 之前是实现定义C99 之后要求向零取整而位运算的结果始终由二进制补码决定。两条语义的差距靠记忆是记不住的最稳的做法是不要假设“应该一样”而是在代码里显式声明前提。如果处理的是无符号整数比如uint32_t那么n (capacity - 1)和n % capacity在 capacity 为 2 的幂时是严格等价的一点坑都没有。所以我的建议是在 C/C 这种类型敏感的语境下能用无符号就用无符号无符号加 2 的幂容量是最干净的组合。4.3 可读性争议review 时怎么说服别人“优化后的代码看不懂”是位运算面临的最大非技术阻力。hash (capacity - 1)对不熟悉位运算的同事就是天书。我在实操里总结了一套组合拳给常量起带约束语义的名字比如BUCKET_COUNT_POW2名字本身就宣告了“必须是 2 的幂”。在代码旁留一行注释说明x (n - 1) x % n的前提是 n 为 2 的幂。把“容量必须是 2 的幂”写进配置校验和启动断言让约束可执行化。在提交说明里附上前后压测数据用事实回答“为什么值得改”。这套组合拳打下来绝大多数 review 争论都能化解。代码可读性不是靠“少写注释”实现的而是靠“让意图和约束都可见”实现的。4.4 不同语言的差异Java、Python、JavaScript 各有各的坑Java 的 JIT 对常量除法优化得很好但对运行期变量除法无能为力所以位运算的收益集中在“运行期变量除数”的热路径。另外 Java 里的优先级低于比较运算if ((a b) 0)的括号不能省少一对括号就会解析成a (b 0)。Python 的整数是任意精度的位运算底层处理的是大整数性能优势远不如 C 和 Java 明显。在 Python 里为了省一次%而改成通常属于过早优化而且可读性会明显变差。我的建议是Python 里先 profiling确认热点后再考虑而且优先看 NumPy 这类向量化方案而不是逐元素做位运算。JavaScript 有个隐蔽大坑按位与会先把操作数转成 32 位有符号整数。超过 2 的 31 次方的数值经过位运算后可能变成负数尤其是高位标志位的写法0x80000000在 JS 里实际是一个负数直接拿它和 0 做相等比较会被坑超过 2 的 53 次方的大整数做位运算更会直接丢精度。所以在 JS 里用位运算优化之前必须先确认数值范围必要时改用 BigInt 或者干脆避开位运算。4.5 性能测试的迷惑性别拿“感觉”当结论当时压测有个有意思的现象用少量数据测版本和%版本几乎没差别把数据量拉大、把调用次数堆高差距才显现。原因很简单低频调用时除法器根本没有成为瓶颈指令延迟被缓存和分支预测掩盖了。只有压力足够大、跑得足够久除法指令的延迟才真正暴露。所以验证优化是否有效我有三个固定动作一是用接近真实流量的数据比例来压二是对比改前改后的火焰图占比三是同一场景至少跑三轮取平均排除 CPU 频率抖动。另请注意在虚拟机里测出的毫秒数基本不可信虚拟机的时钟和指令调度和物理机差别很大用它来断言“优化无效”是不负责任的做法。4.6 常见问题速查表现象原因处理方式改动后数据偶发错乱除数不是 2 的幂还硬套掩码收敛容量并加启动断言负数输入结果异常取模与掩码语义不一致先归一化边界值写单测压测看不出收益除数是常量已被编译器优化换运行期变量场景再测或放弃JavaScript 大数结果诡异转 32 位有符号整数后截断先行校验数值范围避免越界零被误判为 2 的幂漏写n ! 0条件补上前置判断review 争论激烈可读性受质疑命名带约束 注释 压测数据5. 这次优化之后我沉淀下的几条判断标准5.1 我的判断流程什么时候才值得改现在我遇到取模或者除法不会直接条件反射式地改成位运算而是走一套固定判断先确认这段代码在 profiler 的热点上再看分母能不能收敛成 2 的幂不能就直接放弃能的话在配置层加断言、在代码层加注释然后再动手改改完用随机对照测试保语义用真实压测验证收益。这套流程听起来繁琐但它能拦住 90% 的伪优化。位运算最大的价值不只是省掉几条指令而是把“分母是一个 2 的幂”这个约束写进了代码让编译器和阅读代码的人都受益。反过来如果分母是 3、是 7、是 10那就老老实实用%或者用查表和分支判断效果往往更好。优化的本质是性价比不是把每个符号都换成位运算来显得自己很懂底层。举一个反例。有个场景是对 3 取模做三路轮询分母完全不可能变成 2 的幂。当时我没硬凹位运算而是改成查表或者直接用原子计数器加分支判断代码更直白性能也不差。这个案例后来成了我在评审时经常引用的例子优化的前提是约束可收敛不能收敛的约束就该换思路而不是强上位运算。5.2 团队层面怎么让这类优化不变成隐患“某同事改了这几行代码效率起飞”这类故事很容易在团队里引发一窝蜂式的模仿有人就会在错误的地方使用位运算。我后来在内部代码规范里加了一条与运算替代取模只允许在分母为 2 的幂、且附注释与启动断言的前提下使用。这一条落地之后后续所有按位优化都会自然变得规范而不是靠某个人灵光一现后再去踩一遍坑。另外我建议把位运算相关的常见错误写进测试用例集里比如容量不是 2 的幂时、负数输入时、边界值下应该抛错还是归一化都要钉成用例。代码规范写在文档里没人看但测试用例会随着每次构建自动跑这才是真正能守住约束的手段。最后再分享一个小技巧如果你也想在团队里推广这类优化不要只发一篇文章让大家读而是挑一个真实的热点路径当场示范“profile 定位、改位运算、加断言、对照测试、压测验证”的完整闭环。让大家看到流程比让大家看到结果有效得多。这也是我后来所有代码优化分享的固定模式。