在 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 01102、执行 >>16 运算。
运算结果是 0110 0010 1101 1000。
0110 0010 1101 1000 1111 0100 0011 0110 >>16 = 0110 0010 1101 10003、因为计算机存储补位，所以需将其转为补位。
正数的补码就是其本身，补码是：0110 0010 1101 1000。
4、因为 byte 为 1 字节 8 位，所以强制转换时计算机只保留其后 8 位。
保留 ８ 位的结果是：1101 1000。
5、保留 ８位后的数值仍然是补位，而要展示给用户需转换成原位。
补：1101 1000
反：1101 0111
原：1010 10006、最高位 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数据溢出问题
你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧