前阵子我在一个高并发推荐服务里做性能优化最关键的改动之一是把若干个boolean状态标记压缩进了一个int。也就是让每个标记只占一个bit——bits计算机世界最小的积木——而不是一个完整的布尔字段。这个改动让核心接口时延降了四分之一也让我动了写这篇笔记的念头。后来我重新翻了一遍这些年跟bits打交道的代码发现它们散落在性能优化、状态管理、图像处理、音视频合成这些看起来毫不相干的领域里但背后解决问题的思路是相通的很多看似复杂的问题回到“一个bit能表达什么、几个bit拼起来能承载什么”这个层面反而会有更简洁优雅的解法。这篇文章不打算讲抽象的信息论也不打算罗列教科书式的位运算定义而是用我实际踩过的坑、调优过的代码、写崩过又重写的工具把bits的实战价值讲透。适合正在做后端开发、嵌入式、游戏客户端、音视频处理的同行也适合那些一直觉得位运算是“底层老古董”、想补一课的同学。1. 为什么我要为一个单词写一整篇从一次线上性能优化说起1.1 一个uint32替换五个bool字段的真实场景那年推荐服务的用户状态对象长这样一开始谁都没觉得有问题public class UserState { private boolean isNewUser; private boolean hasDoneFirstTask; private boolean hasCoupon; private boolean inGrayList; private boolean needPopup; }看起来很直观吧但它在线上暴露了三个问题。第一个是内存。Java里boolean字段实际占用1字节五个字段加上对象头对齐每个用户状态对象凭空多出几十字节。你看单个对象感觉无所谓但当我把一千万用户的状态序列化进Redis时这些字节直接换算成真实的缓存成本。第二个是序列化开销五个字段要写五个键值对或者一段JSON字符串字符串解析在高并发路径上是实打实的CPU消耗。第三个是组合条件难读。判定“是否弹窗”的业务逻辑是“新用户、且在灰度名单里、且没有领过优惠券”如果用五个boolean字段拼这一串代码能看但稍微复杂一点就很容易把括号写错。改完之后的版本大概是这样的public class UserState { public static final int FLAG_NEW_USER 1 0; public static final int FLAG_DONE_FIRST_TASK 1 1; public static final int FLAG_HAS_COUPON 1 2; public static final int FLAG_IN_GRAY_LIST 1 3; public static final int FLAG_NEED_POPUP 1 4; private int state; public boolean isNewUser() { return (state FLAG_NEW_USER) ! 0; } public void setNewUser(boolean flag) { state flag ? (state | FLAG_NEW_USER) : (state ~FLAG_NEW_USER); } public boolean shouldShowPopup() { return (state FLAG_NEW_USER) ! 0 (state FLAG_IN_GRAY_LIST) ! 0 (state FLAG_HAS_COUPON) 0; } }这个改动带来的收益分两层。第一层是内存和速度一个int占4字节替代了5个boolean加paddingRedis里存的是一个整数而不是JSON字符串反序列化从字符串解析变成了整数读取几乎零开销。第二层是状态判断的规整后续运营要加一种新的标记比如“是否已实名认证”只需要新增一个1 5的FLAG常量所有旧代码照常工作不用担心表结构变更或者字段映射遗漏。后来这套状态还被接进了配置中心运营人员可以直接填一个十进制数字由系统转成二进制去看哪些位是1整个功能上线没有改动一行业务判断逻辑。1.2 bit的本体信息的最小单位和CPU的基本食材bit这个词是binary digit的缩写香农在1948年发表的《通信的数学理论》中把它确定为一个基本术语。教科书喜欢说“信息量的最小单位”我更喜欢把它理解为“计算机的原子”。无论你写的是Java还是Python无论跑在服务器还是单片机里CPU、内存、硬盘、网线上流动的一切本质上都是bit流。为什么位运算这么快这和CPU的硬件设计有关。现代CPU的算术逻辑单元对按位与、按位或、按位异或、位移这类操作几乎都是单时钟周期完成的因为它们映射到硅片上就是一组简单的逻辑门电路。相比之下加法需要处理进位链乘除法的硬件开销更大取模运算在底层其实是一条除法指令可能要消耗几十甚至上百个时钟周期。这就是为什么性能敏感的代码里n % 8经常被优化成n 7n / 2被优化成n 1编译器比你更早意识到这些等价关系。但“快”只是bits的表层价值。它真正的魅力在于表达能力一个bit天然表达“开/关”“有/无”这种二元状态n个bit合起来就是一个可以承载2^n种组合的小型状态空间。你可以在一个byte里塞8个独立开关在一个int里塞32个独立开关这种“把许多状态压缩进一个整数”的模型是权限系统、网络协议、文件系统这些老牌领域几十年不换的设计基石。2. 六个位运算符的底层逻辑与高频用法2.1 放一张速查表六个运算符到底干了什么不管你是刚接触还是已经写了很多年代码这张表都值得存一份因为它是所有位操作的地基。运算符名称写法逐位规则高频用途按位与a b两个bit都为1才为1掩码截取、清零置位|按位或a | b任一个bit为1就为1合并标志、置位^按位异或a ^ bbit相同为0、不同为1翻转、交换、简单校验~按位取反~a0变1、1变0配合做位清除左移a n全体左移n位低位补0乘以2^n、生成位标志右移a n全体右移n位除以2^n、拆字节取高位这些运算符小学二年级的信息课都能看到但真正会用和不会用之间差距很大。下边我按实战频率逐个讲。2.2 按位与和按位或|我的日常工作主力按位与最常见的场景是“截取”。举个例子ARGB颜色值是一个int里面塞了四个通道Alpha、Red、Green、Blue每个通道占8位颜色值0xAARRGGBB。想取出Red分量怎么操作先右移16位把RR挪到最低字节再跟0xFF做与运算把高位的Alpha和RR片段全部清零留下的就是纯净的红色分量。这个技巧在图像处理、游戏GUI、富文本渲染里几乎是每天都要写的代码。我写过一个分享卡片生成服务需要把设计师给的十六进制颜色比如#3EB575拆成RGB三个整数去做透明度混合最后再用位运算打包回ARGBint argb (alpha 24) | (red 16) | (green 8) | blue;一行代码把四个分量拼回一个int。很多初学者以为透明度和RGB必须存四个字段其实一个int就够了。类似地按位或还有一个更直白的名字叫“合并开关”options OPTION_A | OPTION_B | OPTION_C表示同时开启三个选项。按位或的另一个核心操作是“置位”state | FLAG_NEW_USER只把FLAG_NEW_USER对应的那一位设为1其他位保持原样。清除一位则用state ~FLAG_NEW_USER先用取反把FLAG_NEW_USER对应的位变成0再按位与其他位因为与1相与保持不变。这两个组合是位掩码最基础的原子操作后面第三大部分会专门展开。2.3 异或^翻转、交换与校验异或是六个运算符里最有灵性的一个。它的三个性质值得背下来a ^ 0 a任何数和0异或不变a ^ a 0任何数和自己异或清零a ^ b ^ b a连续异或两次同一个数会回到原值。基于第三条有了经典的无临时变量交换a ^ b; b ^ a; a ^ b;不过实际开发里我不推荐你用这种写法现代编译器对临时变量交换的优化已经足够好这种技巧更多出现在面试题和算法竞赛里。异或更务实的用途是“翻转开关”state ^ FLAG_POPUP如果该位原来是0会变成1原来是1会变成0不需要先读取当前状态再决定置位还是清位。我经常用它做按钮高亮、动效开关这一类只需要切换状态的逻辑。异或还有一个容易被忽视的应用简单校验。CRC、奇偶校验、IP校验和很多底层协议都用到异或来检测数据是否被篡改。我在做嵌入式串口通信的时候收发双方约定一个密钥字节对每个数据包做异或生成校验字节接收方重新算一遍再比对不一致就丢弃重传。虽然这算不上加密但防线路干扰造成的偶然性错误足够了开销几乎为零。2.4 移位操作乘除法加速与字节序陷阱左移一位等于乘2右移一位等于除2这个规律对无符号数成立对有符号数则要小心符号位。Java里int x -1; x 1结果还是-1因为算术右移会把符号位一并补到高位想要逻辑右移必须用。C/C的对有符号数是算术右移还是逻辑右移由实现定义但主流编译器都是算术右移。这个坑我后面第六部分单独讲。移位另一个大用途是生成位标志1 n就是第n位的独立标志。声明权限位的时候#define PERM_READ (1 0) #define PERM_WRITE (1 1) #define PERM_EXEC (1 2)这比直接写0x01、0x02、0x04可读性好太多因为1 n一眼就告诉读者“这是第几位”。移位还常配合与运算拆字节和拼字节。比如要把一个16位整数拆成高8位、低8位发给串口int value 0x3A7F; int high (value 8) 0xFF; // 0x3A int low value 0xFF; // 0x7F接收方再拼回来int restored (high 8) | low;。这一收一放就是网络协议里最常见的编码手段你平时用的TCP头、IP头里全是这么干的。3. 位掩码设计模式把一组布尔状态塞进一个整数3.1 订单状态机的位掩码实现位掩码bitmask是bits思维最直接的产品。最容易理解的实战案例是订单状态。一个订单在生命周期里可能有多个标签待支付、已支付、已发货、已签收、退换货中、已评价。这些标签不是互斥的——一个订单可能既已支付又已发货同时还处在退换货流程里。如果用枚举或者互斥的状态字段来管理要么得定义一堆组合枚举但组合是爆炸性的要么就会陷入“这个订单到底处于哪种状态”的语义纠纷。位掩码的实现思路是完全不同的。我把每个标签当成一个独立的bit位订单的任何状态组合都对应唯一的整数public class OrderFlags { public static final int PAID 1 0; public static final int SHIPPED 1 1; public static final int SIGNED 1 2; public static final int REFUNDING 1 3; public static final int REVIEWED 1 4; private int flags; public void markPaid() { flags | PAID; } public boolean isPaidAndShipped() { return (flags (PAID | SHIPPED)) (PAID | SHIPPED); } public boolean isInRefundFlow() { return (flags REFUNDING) ! 0; } }判断“已支付且已发货”一行搞定判断“是否处于可退换货流程”也只需要一次与运算。这里有个特别容易写错的地方判断多个位同时为1不能写(flags (PAID | SHIPPED)) ! 0因为只要命中任意一个位就会返回true必须写成 (PAID | SHIPPED)保证两个位都为1才成立。这个细节我在代码评审里见过不止一次。3.2 RBAC权限系统里的经典用法权限系统是位掩码最经典的舞台。假设一个后台管理平台需要四种操作权限读、写、删除、审核四个二进制位就足够表达public static final int PERM_READ 1 0; public static final int PERM_WRITE 1 1; public static final int PERM_DELETE 1 2; public static final int PERM_AUDIT 1 3;用户的权限用一个int表示角色就是一组预设的int常量public static final int ROLE_ADMIN PERM_READ | PERM_WRITE | PERM_DELETE | PERM_AUDIT; public static final int ROLE_OPERATOR PERM_READ | PERM_WRITE | PERM_AUDIT; public static final int ROLE_GUEST PERM_READ;校验接口权限时if ((userPermission requiredPermission) requiredPermission) { // 允许放行 }为什么这套模式能在各种业务系统里长盛不衰因为它把权限的组合判断压缩成了一行条件判断数据库里只需要一个整数列Redis里也只需要一个int字段序列化开销几乎为零。我做过的几个后台系统权限判断逻辑分散在各处后来统一封装了一个PermissionChecker.check(userPerm, requiredPerm)静态方法所有入口都走它上线后权限相关的Bug率肉眼可见地降了下来。3.3 位掩码的两个隐性好处与三个必守纪律两个隐性好处值得说透。第一是组合爆炸被处理得很优雅4种权限就有16种组合8种权限就是256种如果用布尔字段表达判断“拥有读和写但不能删除”这种受限权限要写一长串条件位掩码里先构造required PERM_READ | PERM_WRITE再写(perm required) required (perm PERM_DELETE) 0清晰到不用注释就能读懂。第二是扩展成本低新加一种权限只需要定义一个新的1 n不用改表结构、不用改实体类旧判断代码全都照常工作。我在一个项目里把权限从5种扩展到12种整个过程中数据库表一行没改。但位掩码有三条纪律我用斜体强调一下位标志常量必须有命名且集中管理。绝不要在业务代码里裸写state 0x08。0x08是第3位过两个月连你自己都可能忘了它的含义。所有FLAG和PERM常量放在一个统一类里用1 n定义注释写清楚每一位的业务意思。预留位要留足够空间。不要把32个bit全部用完至少留出4到8位给未来功能扩展。我见过一个把32位全部占满的系统后来加需求时只能引入第二个int字段所有历史判断代码全部要跟着改。组合条件的可读性需要注释护航。位掩码的代码本质是紧凑的执行效率很高但对第一次接触这套模式的同事来说可能像天书。越是多条件组合判断越要加注释说明真实业务场景最好再附带一段肉眼可读的例子比长篇理论管用得多。4. 位深度的两个实战战场图像调色与音频合成4.1 8bit色深下的色带问题与10bit的解决方案前面讲的bits都是“几个bit”这一节我想讲“每个像素用多少bit”也就是位深度。这个概念是我切入图像处理之后遇到的第一个大坑。8bit色深指每个红绿蓝通道用8bit表示每通道有2的8次方共256个亮度等级三个通道合起来能表达1677万种颜色。听起来很多但人眼对大面积渐变区域的亮度分辨能力远超想象。当画面里有一段从亮到暗的平滑渐变256个等级不够细腻时就会看到肉眼可辨的“阶梯状色带”专业术语叫banding。我在调色服务里第一次遇到这个问题是处理一张黄昏天空照片转成网页用8bit JPG。原图是12bit Raw进入16bit工作空间后一切正常但我做了提亮和对比度增强再输出成8bit时天空区域出现了明显的横向条纹。同事说“是不是相机噪点”其实是位深不足导致的量化误差被对比度增强放大了。解决思路分三层第一源素材尽量用高位深采集12bit/14bit Raw比8bit JPG好得多第二后期处理全程在16bit空间进行最后输出时才降到8bit第三对天空、云层这种大面积渐变区域加抖动dithering在量化时加一点随机噪声破坏周期性条纹人眼对噪声不敏感反而感知不到色带。最核心的编程实践是处理像素时不要过早用低精度整数算尽量在float空间算完最后一次性量化到目标位深。我对比过两种写法差距非常明显// 每步都转回8bit再算精度不断流失 int r8 (pixel 16) 0xFF; double brighted r8 * 1.3 * 0.5; int result (int) brighted; // 全程float最后量化时四舍五入 double rNorm ((pixel 16) 0xFF) / 255.0; double brighted rNorm * 1.3 * 0.5; int result (int)(brighted * 255 0.5);多写一个0.5的四舍五入配合高位深中间计算色带问题能明显减弱。这段代码我至今还在用也是我评审图像类代码时最关注的一类错误。4.2 音频位深16bit与24bit之间隔着一个“动态范围”音频的位深概念类似每个采样点用多少bit表示振幅。16bit音频能表示2的16次方个振幅等级动态范围约96dB24bit能表示1677万等级动态范围约144dB。这48dB的差距就是电噪声底和音乐高潮之间的巨大空间。我做音频合成小项目时输出16bit WAV内部用float算振幅采样值都在-1.0到1.0最终转换short q16 (short)(Math.max(-1.0, Math.min(1.0, sample)) * 32767);看上去没问题。但当我给一个正弦波叠加多个谐波、再做动态范围压缩时16bit的量化噪底开始变得“毛茸茸”的。后来我在内部处理链路引入了一个24bit的中间缓冲格式用int的低24位存一个采样点所有特效处理都在24bit空间完成最后一步才转成16bit输出再配合一个简单的三角波抖动噪底改善非常明显。这个经验跟图像处理完全一致任何对实时数据流的处理中间过程的位宽必须大于最终输出位宽最后再做一次量化。很多初学者会犯的错就是在8bit图像或16bit音频上反复处理每一步都可能引入不可逆的精度损失。4.3 用位运算读写ARGB像素的实际代码位深度的日常高频操作是颜色通道的拆分与合并。ARGB8888格式里一个像素占用4字节分别存透明度和红绿蓝三个通道每通道8bit。从int像素里读出某通道int alpha (argb 24) 0xFF; int red (argb 16) 0xFF; int green (argb 8) 0xFF; int blue argb 0xFF;拼回去则是int argb (alpha 24) | (red 16) | (green 8) | blue;这段代码简单但我在代码评审里见过不下十种错误版本。最常见的错误是忘了对通道做 0xFF导致高位污染第二种是用而不是当像素值是有符号负数时Java的int最高位即Alpha通道大于等于128时就会变成负数算术右移会把符号位扩展取出红色分量变成0xFFFFFFxx最终图片一片红色高亮。所以音视频处理里有一条铁律拿到通道分量后第一件事就是 0xFF拼回像素之前再做一次 0xFF夹紧宁多勿少。5. 三个让我眼前一亮的bits优化案例5.1 布隆过滤器用百万bits换来的两千万数据判重布隆过滤器是bits思维最性感的产物。一个很长的bit数组配合若干哈希函数就能回答“某个元素是否可能存在”。它允许假阳性说不存在但实际可能不存在但不允许假阴性说不存在就一定不存在。这里的“允许假阳性”不是随便说说而是用极小的误判概率换来了极大的内存节省。我在爬虫系统里做URL去重时需要判断两千万个URL是否已经抓取过。如果直接存HashSet两千万个URL每个平均六七十字节几个GB内存轻松耗尽还要考虑哈希碰撞和扩容开销。用布隆过滤器开一个2亿bit约23.8MB的位数组配合三个不同哈希函数比如MD5、SHA1、FNV的截断或变体把每个URL映射到三个bit位并置1。判断时检查这三个bit是否全为1全1说明大概率存在只要有一个0就必然不存在。核心实现示意public class BloomFilter { private byte[] bitmap new byte[(capacity 7) / 8]; public void add(String url) { for (int seed : seeds) { int idx (hash(url, seed) Integer.MAX_VALUE) % capacity; setBit(idx, true); } } public boolean mightContain(String url) { for (int seed : seeds) { int idx (hash(url, seed) Integer.MAX_VALUE) % capacity; if (!getBit(idx)) return false; } return true; } }其中setBit和getBit的关键索引计算就是位运算private void setBit(int index, boolean value) { int byteIndex index 3; int bitIndex index 7; if (value) { bitmap[byteIndex] | (byte)(1 bitIndex); } else { bitmap[byteIndex] (byte)~(1 bitIndex); } } private boolean getBit(int index) { int byteIndex index 3; int bitIndex index 7; return (bitmap[byteIndex] (1 bitIndex)) ! 0; }这里index 3等价于index / 8index 7等价于index % 8但前者更快。布隆过滤器把两千万URL的判重内存从约1.5GB降到了24MB换来千分之几的误判率——对爬虫去重来说偶尔重复抓一个URL完全可接受。5.2 HashMap容量为什么死磕2的幂一次取模的耗时账很多编程语言里哈希表的默认容量是16扩容通常是翻倍。这不是巧合当容量是2的n次幂时哈希到桶位的计算可以用hash (capacity - 1)代替hash % capacity一次按位与替代一次取模。两者耗时差距有多大我给过自己一个粗略测试一百万次随机哈希取模约12到15毫秒位与约1到2毫秒。单次差别是微秒级但放到每秒上千万次查询的缓存服务里会被放大成明显的CPU消耗。OpenJDK的HashMap源码里正是这样写的if ((p tab[i (n - 1) hash]) null) tab[i] newNode(hash, key, value, null);注意(n - 1) hashn始终保持2的幂。我在自己实现精简版缓存Map时照搬了这个思路初始化容量256扩容时左移一位变成512、1024、2048所有定位操作都用 (capacity - 1)。这个习惯一旦养成再看那些“容量不按2的幂来”的哈希表设计就会很自然地怀疑它的性能上限。需要注意位运算取模快捷键只在容量是2的幂时有效别拿 (k - 1)当通用取模用否则哈希分布会严重不均。5.3 十亿级在线状态的bitset方案125MB搞定最后这个案例是IM系统里的用户在线状态判断。需求很直白十亿注册用户要快速判断任意用户是否在线支持秒级更新。如果用MapLong, Boolean十亿个条目光存储开销就非常吓人就算用Redis的String存每个key也有几十字节开销。用bitset的思路给每个用户ID分配一个bit位在线置1、离线置0。十亿用户需要十亿个bit换算一下1,000,000,000 / 8 125,000,000字节也就是125MB。这在内存里完全放得下在Redis里也只是一个1.25亿字节的字符串比十亿个key优雅太多。查询在线状态public boolean isOnline(long userId) { int byteIndex (int)(userId 3); int bitIndex (int)(userId 7); return (onlineBitmap[byteIndex] (1 bitIndex)) ! 0; }更新状态时只改一个bit。这个方案的缺点是不能按用户维度随意增删只能整体加载、整体写回Redis但配合分段处理按用户ID前缀拆成多个段每段一个独立的bitset可以实现分段加载和并发更新。这是我做实时业务以来用最少代码解决最大规模问题的例子之一。6. 踩过位运算这些坑之后我的三条铁律6.1 铁律一位运算用得起但注释必须写到位位掩码的代码天然紧凑一眼看过去全是、|、~很多同事第一反应是“难懂”。我的结论是位运算本身没有错错的是没有把意图说出来。凡是用了1 n定义常量务必写明第n位对应什么业务含义凡是出现(flags (A | B)) (A | B)这种多条件组合判断务必加注释说明真实业务场景。我见过最离谱的是一段权限判断代码函数名只叫check()参数是一个整数调用方传进来的数字还是硬编码的0x30A之类。原作者三个月后再去看也看不懂了最后只能重构。从那以后我给自己立的规矩是位运算和位掩码代码的注释密度要比普通代码高一倍宁可啰嗦不可省略。6.2 铁律二移位前先想清楚符号位和字节序位运算相关的坑我至少踩过三回每次都是线上问题。第一次是Java里int的右移。处理ARGB像素时某个像素的int值是负数Alpha通道大于127就会出现我用color 16取红色分量结果符号扩展把高位全补成1红色分量瞬间变成0xFFFFFFxx。改成color 16才正常。Java里是算术右移补符号位是逻辑右移补0C/C没有需要先转成无符号类型再移位。第二次是大小端。我和嵌入式同事联调设备协议协议规定16位整数用小端字节序我按大端解包结果所有数据高低字节颠倒调试到半夜才排查出来。位运算本身没有大小端概念但一旦涉及“把字节流拼成整数”或“把整数拆成字节数组”就必须先确认双方约定的字节序用ByteBuffer.order(ByteOrder.LITTLE_ENDIAN)这种显式方式处理。第三次是左移溢出。1 31在Java的int中会变成0x80000000也就是Integer.MIN_VALUE一个负数。如果拿它当位标志再和同样为负的state做与运算结果判断要格外小心。所以位标志定义尽量从低位开始除非你非常明确自己在做有符号数否则别轻易碰最高位。6.3 铁律三位深度只是存储格式处理链路才能决定最终质量最后这条送给做图像和音频的同行。很多人以为“输出格式是8bit所以内部处理用8bit就够了”这句话是错的。真正的质量瓶颈在中间处理链路的位宽和量化方式而不是最终存储格式。内部用16bit、24bit甚至float计算最后一步再量化成8bit或16bit并辅以抖动效果远好于每一步都匆匆忙忙转回低精度。我在调色管道优化里反复验证过这条规律同样一张12bit Raw转8bit JPG只要中间保留至少16bit的计算精度最后输出肉眼几乎看不到色带中间任何一步用了8bit整数计算无论怎么调参数色带都会重现。音频也是一样内部32bit float处理最终转16bit时加dither这是专业软件的标准流程自研工具链也应该照做。把“大位宽内部处理、一次性低精度输出”刻进习惯里能帮你少走很多弯路。之前有人问我研究bits到底值不值。我都会反问他你的项目里有没有需要区分几十上百种组合状态的场景有没有高并发的哈希定位有没有图像音频处理的精度问题只要有其一你早晚会回到bit这边来。我自己从业务开发转到音视频处理再转到基础架构每一个阶段都跟bits打过照面有些是主动优化有些是踩坑之后才补课。如果你现在正卡在某个性能问题上不妨先问自己三个问题能不能把状态压缩成一个int能不能把取模改成位与能不能把一条复杂判断改成位掩码组合很多时候答案就藏在最底层的这几个bit里。