前阵子排查一个老项目的配置解析问题配置文件里写着一个看起来人畜无害的数字010。我下意识当十进制读成十结果程序一启动端口绑定直接出错。盯着日志看了半天才反应过来Java 里以 0 开头的整数是八进制字面量010 等于 8不是我以为的 10。就这么一个不起眼的细节差点让我把锅甩给框架。进制这个东西面试常考工作常用但很多人是会用不会懂知道有 0b、0x 这么个前缀却不清楚 JVM 底层为什么偏要用二进制看得懂十进制转二进制的笔试题却会在解析协议、处理颜色值的时候踩坑。今天这篇基础篇我就把 Java 的四种进制——二进制、八进制、十进制、十六进制——从字面量规则、内存存储原理、转换 API、常见坑位一路讲到实际应用。适合刚入门 Java 的同学做一次系统梳理也适合写了好几年代码、但对底层细节还模模糊糊的开发者查漏补缺。1. 先看门面Java 四种进制字面量的写法与易混淆点1.1 二进制、八进制、十进制、十六进制字面量一表看懂Java 的整数类型byte、short、int、long在源码里的字面量可以写成四种进制判断依据就是前缀。这里直接上一张对照表比记文字描述清晰得多进制前缀示例字面量对应的十进制值二进制0b / 0B0b101010八进制001210十进制无前缀1010十六进制0x / 0X0xA10对应的代码验证也很简单int bin 0b1010; // 二进制10 int oct 012; // 八进制10 int dec 10; // 十进制10 int hex 0xA; // 十六进制10 System.out.println(bin , oct , dec , hex);几个很容易忽略的细节值得单独拎出来说。二进制前缀是 0b / 0B从 JDK 7 开始支持字母大小写都可以。十六进制前缀是 0x / 0X注意这里是数字 0 加字母 x不是大写字母 O。我见过不少新手把 0x 写成 0O 或者字母 O 开头编辑器直接标红排查半天还以为是自己 IDE 配置坏了。八进制前缀就是单独的 0这个最隐蔽因为它经常被当成普通的十进制写法。另一个细节是 JDK 7 之后字面量里允许用下划线分隔数字比如 0b1010_1100、1_000_000纯粹为了可读性不影响数值本身。这里要给一个实战习惯源码里表达掩码、标志位这类常量时尽量直接写二进制或十六进制字面量不要写一个十进制数字再用注释解释它的二进制含义。注释和代码脱离是迟早的事而 0b0100 一眼就能看出是第三位为 1比int flag 4; // 第三位置1可靠得多。代码即文档进制字面量就是最朴素的文档。1.2 字面量进制与字符串解析进制是两套体系这是我在带新人时发现最容易混淆的点。源码里的 0x1A 是一个编译期就确定好的整数常量而运行时从配置文件、数据库、网络消息里拿到字符串 1A这是完全不同的场景。字符串转数字要走 Integer.parseInt 或 Integer.valueOf并且要显式传进制参数int fromHex Integer.parseInt(1A, 16); // 26 int fromBin Integer.parseInt(1010, 2); // 10字面量里的 0x、0b 前缀只在编译源码时生效字符串解析默认按十进制处理除非你显式传第二个参数。反过来也一样Integer.toBinaryString(10) 返回的是字符串 1010这个字符串不会自动带 0b 前缀你要拼日志、拼协议字段时得自己加。所以记住一句话字面量进制是编译器语法解析进制是运行时约定两者各管各的别混着用。后面避坑章节里的 parseInt 翻车案例根子就在这里。2. 内存真相从硬件电平到补码存储JVM 里到底存的是什么2.1 为什么计算机只用 0 和 1电压逻辑与硬开关先补最底层的问题为什么计算机不用十进制因为十进制需要识别十种不同的电平状态。假设用电压代表数字0 到 9 对应十档电压硬件要精确产生并区分这十档电压难度和成本都会急剧上升而且电压一抖动就会判错。二进制的 0 和 1 只需要区分高电平、低电平两种状态用晶体管开关就能轻松实现。状态越少抗噪声能力越强电路越简单可靠。打个比方你就懂了如果二进制是灯的开和关十进制就是让灯泡精确显示十档亮度还要在光线干扰下一眼分出哪档是哪档明显后者不靠谱得多。所以你在 Java 里写的 int、long最终在内存、CPU 寄存器里就是一排存储单元的电平组合。这也是为什么不管上层语言多高级最终落到硬件层面都是二进制的天下Java 不可能例外。2.2 补码不是算法而是规则负数为什么长这样这一节是底层原理的核心我要把它讲透。先看原码最高位当符号位其余位表示绝对值。8 位场景下10 是 00001010-10 是 10001010。但原码有个致命问题加减法没法统一。1 加 -1 用原码算00000001 加 10000001 得到 10000010被解读成 -2完全错误。反码和补码就是为了解决这个问题产生的。Java 以及绝大多数现代计算机都使用补码表示有符号整数规则只有两条非负数补码等于原码本身负数先按位取反再加 1。等价说法是负数的补码等于 2^n - |x|其中 n 是位数。拿 byte 的 -10 举例8 位下 10 是 00001010取反得到 11110101加 1 得到 11110110。这就是 -10 在内存里的真实样子。补码最大的好处是加减法不用区分符号。算 7 加 -300000111 加 11111101 得到 1_00000100最高位的进位自然丢弃剩下 00000100 正好是 4。同一个加法电路有符号无符号都能算CPU 设计因此大大简化。理解补码之后很多死记硬背的东西自然就通了。比如 byte 的范围为什么是 -128 到 1278 位能表示 256 个状态补码把最大负数 10000000 分给 -128正数最大到 01111111 也就是 127总比对称出 -127 到 128 要划算。这个不对称不是约定俗成拍脑袋是补码规则推出来的必然结果。提示这里不需要你去手动算补码做算术题但你需要形成这个认知——Java 里看到的所有 int、long 负数内存中的位模式都是补码形式。这个认知会直接影响你后面看 toBinaryString 输出时的理解。2.3 十六进制是二进制的人肉压缩包八进制是副产物既然内存里全是二进制为什么写代码反而常看到十六进制因为人看 010000111010 这种长串会瞎。一个十六进制数字正好对应 4 个二进制位转换表极其规整十六进制的 0 到 F对应二进制的 0000 到 1111。于是 16 位二进制 1010_1111_0000_1100 可以压写成 0xAFC读写效率直接翻倍。反过来看到 0xAFC 也能快速展开成二进制方便位运算分析。八进制同理一个八进制位对应 3 个二进制位也就是 000 到 111。它算历史遗留早期一批机器的字长是 24 位、36 位正好是 3 的倍数用八进制顺理成章现代 CPU 的字长是 8、16、32、64 位全是 4 的倍数十六进制自然胜出。这个历史背景不是单纯考据。它解释了为什么现在代码规范普遍禁止八进制字面量但允许十六进制现代计算机字节是 8 位两个十六进制字符正好描述一个字节而八进制三个字符描述 9 位跟字节对不齐。后面讲协议解析你会看到十六进制在底层调试里几乎是一统天下的地位。3. 进制转换实操内置 API 速查与手写轮子3.1 JDK 自带的方法怎么用才不会记混Integer 和 Long 各有一组进制转换方法它们之间的关系其实一一对应做一张速查表就不会记岔需求方法说明十进制整数变二进制字符串Integer.toBinaryString(int)内部按无符号处理见避坑章节十进制整数变八进制字符串Integer.toOctalString(int)十进制整数变十六进制字符串Integer.toHexString(int)任意进制字符串变整数Integer.parseInt(String, radix)radix 范围 2 到 36任意进制字符串变包装对象Integer.valueOf(String, radix)会缓存 -128 到 127 的常见值Long 对应版本Long.toBinaryString(long) 等同理实际用起来就是一组对称操作int n 254; System.out.println(Integer.toBinaryString(n)); // 11111110 System.out.println(Integer.toOctalString(n)); // 376 System.out.println(Integer.toHexString(n)); // fe System.out.println(Integer.parseInt(fe, 16)); // 254记忆记法就两条toXxxString 都是整数变字符串parseXxx 和 valueOf 都是字符串变整数。最容易记混的其实是 toBinaryString 对负数的输出行为这个我在避坑章节专门讲。3.2 手写二进制转换除基取余和位运算两种思路虽然平时可以直接用 API但面试和底层调试偶尔要求手写原理部分也必须懂。十进制转二进制最经典的方法是除 2 取余、逆序排列static String toBinary(int n) { if (n 0) return 0; StringBuilder sb new StringBuilder(); int t Math.abs(n); while (t 0) { sb.append(t % 2); t / 2; } return sb.reverse().toString(); }注意这段代码对负数取了绝对值它表达的是数值本身不是补码形式。想输出补码思路完全不一样见避坑章节。另一个更常用、更贴近实战的思路是位运算从高位往低位逐位取值。以 8 位输出为例static String toBinary8(int n) { StringBuilder sb new StringBuilder(); for (int i 7; i 0; i--) { sb.append((n i) 1); } return sb.toString(); }这里的 (n i) 1 意思是把 n 右移 i 位让目标位落到最低位再和 1 做与运算筛出这一位的值。这个手法在解析协议、判断标志位时天天都要用建议直接刻进肌肉记忆。3.3 浮点数的十六进制同样能看但别想着手算别以为进制只跟整数有关。Java 的 float 和 double 基于 IEEE 754 标准内存里同样是二进制1 位符号位、若干位指数、若干位尾数。JDK 提供了 Float.toHexString 和 Double.toHexString能直接看到浮点数的二进制科学记数法形态float f 0.1f; System.out.println(Float.toHexString(f)); // 0x1.99999ap-4这段输出的意思是 1.99999a十六进制小数乘以 2 的 -4 次方。你不需要手动把它换算回十进制但必须从这个输出中看出一件事0.1 在十进制下干干净净在二进制下却是无限循环小数所以 float 和 double 存在天然精度误差。这也就解释了为什么涉及金额、精确计数时要上 BigDecimal而不是直接拿 double 一顿相加。进制认知在这里直接决定了代码质量的判断力这是很容易被忽略的连带价值。4. 避坑现场我在真实代码里见到的进制翻车案例4.1 parseInt 的 radix 参数第二个参数不是可选项A同学曾经写过这样一段代码int port Integer.parseInt(prop.getProperty(port));配置文件里写的是 0x1F90他以为解析十六进制也支持带前缀结果运行时直接抛 NumberFormatException。原因就是前面铺垫过的parseInt(String) 默认 radix 是 10字符串里既不能有 0x 也不能有字母。正确写法是把进制参数显式传进去int port Integer.parseInt(value, 16);但这里还有个更隐蔽的细节传了 radix 之后字符串里仍然不能带 0x 前缀只能写数字部分 1F90。很多同学第一次改对后会在这个点上再翻一次车。另外 radix 参数本身有边界有效范围是 2 到 36超出直接抛异常传入 16 时字符串里出现 G 这类不合法字符也一样抛。所以解析外部输入前最好用正则或 Character.digit 方法先做一遍合法性校验别指望异常信息能帮你定位到具体是哪个字符惹的祸。4.2 toBinaryString 与负数你以为的补码其实是正数这是个经典误区值得单独占一个小节。Integer.toBinaryString(-1) 输出 32 个 1也就是 11111111111111111111111111111111。很多人把这当成补码输出严格说不准确这个 API 实际返回的是无符号视角下的二进制字符串内部把 -1 当作 2^32 - 1 也就是 4294967295 来处理。只不过对负数来说无符号展开的位模式和补码位模式恰好一致所以容易产生误解。理解这层之后你会解释很多连带的怪现象。比如把 -2 转二进制输出 32 位且末位是 0这确实和补码一致但如果你拿这个字符串再用 Integer.parseInt(bin, 2) 解析会得到 4294967294 而不是 -2因为解析时没有符号位概念。实战影响最明显的是处理 byte 类型。一个 byte 变量在参与位运算时会被自动提升成 int如果它是负数会先做符号扩展直接 toBinaryString 输出前面会多出一堆 1。想看到这个 byte 本身的 8 位形态必须先和 0xFF 做与运算byte b -1; System.out.println(Integer.toBinaryString(b)); // 11111111111111111111111111111111 System.out.println(Integer.toBinaryString(b 0xFF)); // 11111111这个 (b 0xFF) 的操作我在排查网络字节解析问题时用过无数次。它本质上就是把你关心的 8 位留下高位全部清零。4.3 以 0 开头的整数字面量最古老的 Java 陷阱开头那个端口事件值得在这里完整展开。Java 继承了 C 语言的传统整数以 0 开头就是八进制字面量。所以 010 是 80127 是 870777 是 511。这种写法在代码评审里是坑王级别int timeout 0100; // 你以为 100实际 64 int permission 0777; // 你以为 777实际 511更危险的是它不一定报错因为八进制值往往也在合法范围内程序照常运行只是行为和你预期不符排查起来相当费劲。我曾经在一个模拟项目中见过配置文件里写了 0400 表示权限结果读出来是 256权限判断全部错乱。应对办法很朴素新代码一律禁止写 0 开头的整数字面量用十进制或十六进制表达意图配置文件里的数值统一按字符串解析不要直接写成 Java 字面量放进源码代码审查时看到 0 开头的数字无论多小都要停下来确认意图。还有个小延伸Java 7 之后字面量支持下划线有同学写 01_000 想表示一万实际上 01_000 是八进制 512这种写法既反直觉又危险千万别用。4.4 前导零丢失与反转字符串转换边界进制转换之后拿到的是字符串而字符串和数字互转时有个天然陷阱前导零会丢。Integer.toBinaryString(2) 返回 10不会给你补成 00000010。当你需要固定位数对齐比如拼协议帧、生成掩码表必须手动补零。最常见的写法是用格式化String bin String.format(%8s, Integer.toBinaryString(2)).replace( , 0); // 00000010另一个我亲测踩过的坑是反方向解析固定长度的二进制字符串。Integer.parseInt(00000101, 2) 没问题前导零自动忽略但如果先把字符串 reverse 再解析边界就要小心。比如 0001 reverse 成 1000解析结果是 8 而不是 1。这类问题在自创编码、实现自定义协议时特别容易冒出来。我的建议是任何涉及字符串摆位的操作先写几个边界用例测试特别是全 0、最高位为 1、前导零超过 4 位这几种情况把预期值打印出来比对比事后在线上抓日志舒服多了。5. 进阶玩法位掩码、颜色值与协议解析里的进制实战5.1 用二进制位做权限标志与、或、非的封装思路进制学完不能只停留在转换题真正的价值在于位运算。最常见的场景是权限系统用 int 的低 3 位表示三种权限int READ 0b001; // 1 int WRITE 0b010; // 2 int EXEC 0b100; // 4为什么选 1、2、4 而不是 1、2、3因为二进制下每一位互不重叠可以放心用 | 叠加、用 判断int perm READ | WRITE; // 0b011有读有写 boolean canRead (perm READ) ! 0; // true boolean canExec (perm EXEC) ! 0; // false这种设计的扩展性极好加一个权限就是加一个更高的位存储结构不动老数据兼容。唯一要注意的是 int 只有 32 位权限位超过 32 个就要换 long 或改用 BitSet不要硬把标志位挤进 int 里再想办法绕过符号位那是给自己挖坑。5.2 从颜色值到字节流十六进制在通讯协议里的地位前端后端对接时颜色的经典表示是 #FF8800Java 里通常写成 0xFF8800。解析时用位运算拆通道正好是进制知识的直接应用int color 0xFF8800; int r (color 16) 0xFF; int g (color 8) 0xFF; int b color 0xFF;每两位十六进制对应一个字节通道0xFF 掩码把目标通道之外的高位全部清掉只留下需要的 8 位。这个套路一旦上手看到 0xFF8800 你脑子里的反应就不该是一个很大的数字而是红 FF、绿 88、蓝 00三个字节。同理解析 TCP、串口、Modbus 这类协议帧时一个字节就是两个十六进制字符。线上抓包工具打出来的报文几乎都是十六进制会读十六进制就等于会读协议。先把字节按序切开再把每个字节按位拆字段整个链路就通了。提示遇到报文里的多字节数值时一定要先确认字节序。常见的有大端 0x1234 存成 12 34 和小端 34 12搞反之后解析出的长度、校验码全都不对而且这种问题日志里几乎看不出来。5.3 调试技巧看到十六进制 dump 不要慌真调试的时候你往往看不到 0b 或 0x 前缀而是日志里直接打出来的一串形如 8A 3F 的字节。正确姿势是看两端一端是协议文档给出的字段定义一端是 dump 出来的十六进制流。这时候进制心算能力就是效率本身。0xA7 对应二进制 1010 0111高两位 10 是版本号、低三位 111 是功能码用掩码逐位筛出对应字段问题往往几分钟就定位。我自己排查线上问题的习惯是把关键变量的十六进制和二进制同时打出来先看十六进制确认字节序和通道再用掩码逐位确认标志位。很多看起来玄学的 bug最后的根因都逃不过三类大小端搞反、掩码错位、符号扩展没处理。而这三种问题本质上全是进制理解不到位。掌握进制的另一个隐性收益是读 JDK 源码。你会频繁看到 0x7fffffff、0xFF、0x80000000 这类魔数常量看得懂进制源码在你眼里就是逻辑清晰的位操作而不是一堆神秘数字排查问题的心态也会稳很多。最后分享一点个人体会。进制这个东西大学课本里学过但真正让我彻底搞懂的不是教材而是一次次线上翻车0 开头的配置让我半夜起来改代码toBinaryString 的符号扩展让我多查了半宿文档ByteBuf 的大小端问题让我学会看十六进制报文前先确认字节序。如果你现在还觉得进制只是面试题建议在项目里刻意找一个位运算或十六进制解析的小场景练手把今天这些 API 和坑位亲手过一遍。看到 0 开头数字先停下来想想它是不是八进制看到负数编码输出先确认有没有符号扩展——这两个习惯比背一百道进制转换题有用得多。