某天我盯着火焰图发愣，一个日请求量很大的内部接口，光取模运算就占了将近两成的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 里，如果除数是编译期常量 16，JVM 的 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^4，15的二进制是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 的取模自动折叠成& 1，Java 的 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 的二进制全是 0，0 & (0 - 1)也等于 0，不排除 0 就会误判。这个函数在哈希表扩容、内存池 size class 判断、位图管理里都有实际用途，是系统程序员必须背下来的经典。
3. 实操过程：从定位热点到安全上线
3.1 第一步永远是 profile，不是猜
那几行被评价为“效率起飞”的代码，不是某天拍脑袋改出来的。过程是：先压测、抓火焰图、看热点函数，发现一处高频分发逻辑里连续出现多个除法相关指令，样本占比非常高。再切面确认，全是同一类操作：对运行期变量做取模。
给新手的建议是：没上 profiler 之前，先别谈优化。Java 可以用 async-profiler 或 JFR，C/C++ 用 perf，Go 直接 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 语言可以用assert，Go 在配置加载时检查。这样即使将来有人把容量配置改成 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 定位、改位运算、加断言、对照测试、压测验证”的完整闭环。让大家看到流程，比让大家看到结果有效得多。这也是我后来所有代码优化分享的固定模式。
