在 Github 项目mongo-java-driver
有一个类ObjectId.java
,它的作用是生成唯一 id 的,它的核心实现是下面这样一段代码 [1]:
public void putToByteBuffer(final ByteBuffer buffer) { notNull("buffer", buffer); isTrueArgument("buffer.remaining() >=12", buffer.remaining() >= OBJECT_ID_LENGTH); buffer.put(int3(timestamp)); buffer.put(int2(timestamp)); buffer.put(int1(timestamp)); buffer.put(int0(timestamp)); buffer.put(int2(randomValue1)); buffer.put(int1(randomValue1)); buffer.put(int0(randomValue1)); buffer.put(short1(randomValue2)); buffer.put(short0(randomValue2)); buffer.put(int2(counter)); buffer.put(int1(counter)); buffer.put(int0(counter)); }
上述代码中的int2()
方法定义如下:
private static byte int2(int x) { return (byte) (x >> 16); }
取当前时间戳(秒)1658385462,我们来测试一下该方法:
@Test public void test() { System.out.println(int2(1658385462)); // -40 }
得到的结果是 -40。即:(byte) 1658385462 >> 16 = -40
。
这是怎么算出来的?
1、首先,计算机要将 1658385462 转换为二进制数。
因为 int 为 4 字节 32 位,对应二进制结果如下:
0110 0010 1101 1000 1111 0100 0011 0110
2、执行 >>16 运算。
运算结果是 0110 0010 1101 1000。
0110 0010 1101 1000 1111 0100 0011 0110 >> 16 = 0110 0010 1101 1000
3、因为计算机存储补位,所以需将其转为补位。
正数的补码就是其本身,补码是:0110 0010 1101 1000。
4、因为 byte 为 1 字节 8 位,所以强制转换时计算机只保留其后 8 位。
保留 8 位的结果是:1101 1000。
5、保留 8位后的数值仍然是补位,而要展示给用户需转换成原位。
补:1101 1000 反:1101 0111 原:1010 1000
6、最高位 1 表示负数,将 010 1000 转换成十进制数,则为 -40。
原码:原码就是符号位加上真值的绝对值,即用第一位表示符号,其余位表示值。
反码:正数的反码是其本身。负数的反码是在其原码的基础上,符号位不变,其余各位取反。
补码:正数的补码就是其本身。负数的补码是在其原码的基础上,符号位不变,其余各位取反,最后+1。
从原码、反码、补码的表示方式不难看出,原码才是人眼最直观能看出值的表示方式,那么为什么还要有反码和补码呢?
答案是为了简化计算机集成电路的设计。
我们人脑是可以辨别第一位是符号位的,在计算的时候我们会根据符号位,选择对真值区域的加减。但是对于计算机,辨别“符号位”显然会让计算机的基础电路设计变得十分复杂,于是人们想出了将符号位也参与运算的方法。
我们知道,根据运算法则:减去一个正数等于加上一个负数,即:1-1 = 1 + (-1) = 0,所以机器可以只有加法而没有减法,这样计算机运算的设计就更简单了。此外,由于现阶段计算机 CPU 擅长做加法运算,CPU 硬件实现减法要复杂得多,而且运算效率很低,所以我们偷懒只讨论加法运算。说不定以后发明了减法加速硬件,那就另当别论了。
于是人们开始探索将符号位参与运算,并且只保留加法的方法。 首先来看原码:计算十进制的表达式:1-1=0。
1 - 1 = 1 + (-1) = [00000001]原 + [10000001]原 = [10000010]原 = -2
如果用原码表示,让符号位也参与计算,显然对于减法来说,结果是不正确的。这也就是为何计算机内部不使用原码表示一个数。
为了解决原码做减法的问题,出现了反码。
1 - 1 = 1 + (-1) = [0000 0001]原 + [1000 0001]原 = [0000 0001]反 + [1111 1110]反 = [1111 1111]反 = [1000 0000]原 = -0
发现用反码计算减法,结果的真值部分是正确的。
用反码计算减法,结果的真值部分是正确的。而唯一的问题其实就出现在“0”这个特殊的数值上。 虽然人们理解上 +0 和 -0 是一样的,但是 0 带符号是没有任何意义的。 而且会有[0000 0000]原
和[1000 0000]原
两个编码表示 0。
于是出现了补码,为了解决 0 的符号以及 0 的两个编码问题:
1 - 1 = 1 + (-1) = [0000 0001]原 + [1000 0001]原 = [0000 0001]补 + [1111 1111]补 = [0000 0000]补 = [0000 0000]原
这样 0 用 [0000 0000] 表示,而以前出现问题的 -0 则不存在了。那另一个编码 [1000 0000] 是否就弃用了呢?
(-1) + (-127) = [1000 0001]原 + [1111 1111]原 = [1111 1111]补 + [1000 0001]补 = [1000 0000]补
-1-127 的结果应该是 -128,刚好 [1000 0000] 可以用来表示 -128。在用补码运算的结果中,[1000 0000]补
就是 -128。
但是注意: -128 并没有原码和反码表示。对 -128 的补码[1000 0000]补
算出来的原码是[0000 0000]原
,这显然是不正确的。
使用补码,不仅仅修复了 0 的符号以及存在两个编码的问题,而且还能够多表示一个最低数。所以最终同样是 8 位二进制,使用原码或反码表示的范围为 [-127, +127],而使用补码表示的范围为 [-128, 127]。
我整理了本文知识消化链路,如下。
使用原码计算减法的结果是错误的 -> 出现了反码 -> 使用反码计算的 0 有两个,+0 和 -0 -> 出现了补码