Java 中的无符号算术支持

1. 概述

从 Java 诞生之初，所有数值类型默认都是有符号的（signed）。但在实际开发中，我们经常需要处理无符号（unsigned）数值。比如统计事件发生次数时，显然不可能出现负数。

从 JDK 8 开始，Java 正式引入了对无符号算术的支持——这并非新增了 unsigned int 这类语法关键字，而是通过 Integer 和 Long 类中新增的一组静态方法 构成了所谓的“无符号整数 API”。

本文将带你全面掌握这套 API 的使用方式，避免踩坑。

2. 位级表示原理

要理解有符号和无符号数的差异，必须从底层的二进制表示说起。

✅ Java 中所有整数默认采用“二进制补码”（two’s complement）编码。这种编码方式的妙处在于：加、减、乘等基本运算在有符号和无符号场景下，其位操作逻辑完全一致。

我们以 byte 类型为例说明（其他类型如 short/int/long 原理相同）：

假设有一个 byte 变量值为 100，其二进制表示为：

0110_0100

现在我们将其左移一位（相当于乘以 2）：

byte b1 = 100;
byte b2 = (byte) (b1 << 1);

左移后，b2 的二进制变为：

1100_1000

❌ 如果按无符号解释：这个值是 2^7 + 2^6 + 2^3 = 200
✅ 但在 Java 的有符号系统中，最高位是符号位（1 表示负数），所以实际值为：-2^7 + 2^6 + 2^3 = -56

验证一下：

assertEquals(-56, b2);

⚠️ 关键结论：有符号和无符号的运算过程是一样的，区别只在于 JVM 如何“解读”最终的二进制结果。

像加减乘这类操作无需特殊处理，但比较、除法、取模、解析和格式化这些操作就必须区分有无符号——这正是 Unsigned Integer API 要解决的问题。

3. 无符号整数 API 详解

JDK 8 在 Integer 和 Long 类中添加了一系列静态方法，用于支持无符号操作。两者用法几乎一致，下面我们以 Integer 为例展开。

3.1. 比较：compareUnsigned

普通 Integer.compare(a, b) 是按有符号比较的。而 compareUnsigned 会忽略符号位，把所有位都当作数值位处理。

举个典型例子：

int positive = Integer.MAX_VALUE; //  2147483647 -> 0111...1111
int negative = Integer.MIN_VALUE; // -2147483648 -> 1000...0000

有符号比较：

int signedComparison = Integer.compare(positive, negative);
assertEquals(1, signedComparison); // positive > negative

无符号比较：

int unsignedComparison = Integer.compareUnsigned(positive, negative);
assertEquals(-1, unsignedComparison); // positive < negative

为什么？因为从无符号角度看：

MAX_VALUE 是 0b0111...1111
MIN_VALUE 是 0b1000...0000 → 显然更大

甚至可以验证：

assertEquals(negative, positive + 1); // 无符号下：MAX_VALUE + 1 = MIN_VALUE

3.2. 除法与取模：divideUnsigned / remainderUnsigned

同样，除法和取模也需要专用方法处理无符号场景：

int positive = Integer.MAX_VALUE;
int negative = Integer.MIN_VALUE;

// 有符号运算
assertEquals(-1, negative / positive);        // -2147483648 / 2147483647 ≈ -1
assertEquals(-1, negative % positive);        // 余数为 -1

// 无符号运算
assertEquals(1, Integer.divideUnsigned(negative, positive));     // 2147483648 / 2147483647 = 1
assertEquals(1, Integer.remainderUnsigned(negative, positive));  // 余数为 1

⚠️ 如果混用有符号除法处理本应无符号的场景，结果会完全错误。

3.3. 字符串解析：parseUnsignedInt

parseInt 只能解析 [-2147483648, 2147483647] 范围内的字符串。而 parseUnsignedInt 支持 [0, 4294967295] 范围。

例如：

// parseInt 无法解析超过 MAX_VALUE 的正数
Throwable thrown = catchThrowable(() -> Integer.parseInt("2147483648"));
assertThat(thrown).isInstanceOf(NumberFormatException.class);

// parseUnsignedInt 可以
assertEquals(2147483648L, Integer.parseUnsignedInt("2147483648"));

✅ 注意：parseUnsignedInt 返回的是 int，但语义上表示的是无符号 int 的值（最大可达 2^32 - 1），所以接收时建议用 long 防溢出。

3.4. 格式化输出：toUnsignedString

与解析相反，toUnsignedString 可以将一个 int 变量按无符号方式转为字符串：

String signedString = Integer.toString(Integer.MIN_VALUE);
assertEquals("-2147483648", signedString);

String unsignedString = Integer.toUnsignedString(Integer.MIN_VALUE);
assertEquals("2147483648", unsignedString);

这个功能在打印哈希值、位运算结果、或与 C/C++ 系统交互时特别有用。

4. 优缺点分析

虽然很多来自 C/C++ 的开发者对无符号支持拍手叫好，但 Java 的这套 API 并非银弹，需理性看待。

✅ 看似合理的使用场景

防止负值误用：某些业务场景（如计数器）天然不应出现负数。
扩展取值范围：无符号 int 最大可达 4294967295，比有符号的 2147483647 多一倍。

❌ 实际中的问题与陷阱

负值未必是坏事
比如 String.indexOf() 返回 -1 表示未找到，这种“负值即异常”的模式在 Java 中非常普遍。强行用无符号反而会失去这种简洁表达。
范围扩展有限
如果 int 范围不够，翻倍后也大概率仍不够。真正需要大数值时，应该直接上 long 或 BigInteger，而不是依赖无符号 int。
极易混用导致 Bug
⚠️ 最大的坑：有符号和无符号变量在内存中二进制表示完全一样！
这意味着你可以轻易把一个无符号值当有符号用，反之亦然，而编译器不会报错。例如：
```
int unsignedValue = Integer.parseUnsignedInt("3000000000"); // 实际是负数：-1294967296
System.out.println(unsignedValue); // 输出 -1294967296，容易误导
System.out.println(Integer.toUnsignedString(unsignedValue)); // 正确输出 3000000000
```
这种隐式混淆是类型安全的反面教材。

5. 总结

JDK 8 引入的无符号算术 API 是对社区呼声的回应，但其实际价值有限，且容易引发误解和 Bug。

✅ 建议使用场景：

与底层协议、C 接口交互时解析/格式化无符号整数
位运算、哈希、序列号等明确不涉及符号的场景

❌ 不建议滥用：

日常业务逻辑中用无符号替代有符号
企图用它解决“int 不够用”的问题

简单粗暴地说：能不用就不用，要用就全程明确标注 + 单元测试覆盖。

示例代码已上传至 GitHub：https://github.com/baeldung/core-java-modules/tree/master/core-java-lang-math

Persistence

REST

Security