本文详解 Java 中 ~ 运算符如何将整数按位取反，并阐明为何同一比特模式（如 11111111...1101）在有符号语境下被解释为 -3，而非无符号大数；核心在于 Java 始终采用固定宽度的二进制补码表示，且无 unsigned int 类型，语义由数据类型静态决定。
本文详解 java 中 `~` 运算符如何将整数按位取反，并阐明为何同一比特模式（如 `11111111...1101`）在有符号语境下被解释为 `-3`，而非无符号大数；核心在于 java 始终采用**固定宽度的二进制补码表示**，且**无 unsigned int 类型**，语义由数据类型静态决定。
在 Java 中，int 是 32 位有符号整数，严格遵循二进制补码（Two's Complement） 编码规则。这意味着：
- 所有 int 值都以 32 位二进制形式存储；
- 最高位（bit 31）是符号位：0 表示非负数，1 表示负数；
- 负数的值 = 对应正数的补码表示（即 ~x + 1），反之亦然。
以 int x = 2 为例：
int x = 2;
System.out.println(Integer.toBinaryString(x)); // 输出: 10（注意：toBinaryString 不补零）
System.out.println(String.format("%32s",
Integer.toBinaryString(x)).replace(' ', '0'));
// 输出: 00000000000000000000000000000010
执行按位取反 ~x：
int y = ~x; // 按位翻转每一位
System.out.println(y); // 输出: -3
System.out.println(String.format("%32s",
Integer.toBinaryString(y)).replace(' ', '0'));
// 输出: 11111111111111111111111111111101
这里的关键点在于：~ 不改变数据类型，只做纯位操作。它把 0000...0010 变成 1111...1101，而 Java 编译器和 JVM 始终将 int 的这 32 位解释为补码有符号整数——因此 1111...1101 直接被解码为 -3（验证：-3 的补码 = ~3 + 1 = 1111...1100 + 1 = 1111...1101）。
⚠️ 常见误解澄清：
- ❌ “机器会自动判断这个数是 -3 还是 4294967293” → 错。Java 没有 unsigned int 类型，JVM 在运行时不保留额外的‘符号意图’元信息；它只依据变量声明的类型（int）决定解码方式。
- ✅ 正确理解：11111111111111111111111111111101 作为 int 就是 -3；若你强行将其当作无符号数看待（例如用 Integer.toUnsignedString(y)），输出才是 4294967293，但这只是显示层面的 reinterpretation，底层存储未变，且该值仍无法赋给 int 变量（因超出 int 正数范围）。
补充说明：Java 8+ 提供了无符号工具方法（如 Integer.compareUnsigned()、Integer.toUnsignedString()），用于模拟无符号运算逻辑，但它们本质是通过位运算+类型转换实现的，并不引入新类型：
int negative = ~2; // -3 System.out.println(Integer.toUnsignedString(negative)); // "4294967293" System.out.println(Integer.compareUnsigned(negative, 0) > 0); // true —— 视为无符号时大于0
✅ 总结：
- ~ 是纯粹的位翻转，不涉及数值转换；
- Java 中 int 的语义（有符号补码）决定了同一比特序列的唯一合法解释；
- “歧义”只存在于跨语言对比（如 C 的 unsigned int）或人为误读中；在 Java 体系内，比特模式与 int 值之间是一一对应的（双射）——因为定义域已被限定为 ([-2^{31}, 2^{31}-1])，共 (2^{32}) 个值，恰好填满全部 32 位组合。所谓“违反单射”，实则是混淆了不同类型系统下的编码契约。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
