关于后端:byte16583854621640怎么算的

在 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
-> 呈现了补码

更多技术干货，敬请关注公众号「杨同学 technotes」，欢送技术交换。

文中提及的链接

[1] ObjectId#putToByteBuffer

参考资料

计算机为什么要应用原码、反码、补码

java 中 int 强制转 byte 数据溢出问题

关于后端:byte16583854621640怎么算的

注释

计算过程

什么是原码、反码、补码？

为什么要有反码？

为什么要有补码？

小结