dubbo序列化数据包

dubbo序列化数据包

在分析dubbo序列化的时候,对ExchangeCodec中encodeRequest方法的Bytes.short2bytes(MAGIC, header)不是很理解,故写此文章

一、计算机中的位运算

1. ^ 异或位运算 两者相同位0 两者不同为1 例 6^7=00000110 ^ 00000111=00000001=1
2. | 或运算 只要有一个为1 那么就为1 例 6|7=00000110 | 00000111=00000111=7
3. & 与运算 两者都为1 才为1 例 6&7=00000110 & 00000111=00000110=6
4. ～ 取反 本来是0 变成1 本来是1变成0 例 6=00000110=11111001=-121(最高位为符号位)

那么-15 | 3等于多少呢 note(负数求补码应该是出去符号位取反+1)
答案 : -15在计算机中是以补码的方式存在的也就是 15的补码 = 15的反码+1 =11110000+1=11110001; 3是正数 补码是其本身;其结果是 11110001 | 00000011=11110011 然而还没有到最后 还要计算原码(原码就是补码再求补码再+1) 11110011 的补码 也就是反码+1: 10001100+1=10001101=-13

二、运算符

1.<<:左移运算符，不需要考虑符号位，因为在后面补0，把二进制的数字向左移动，低位补0。比如说 3<<2。3的二进制码为11，向左移动2位就是1100，那么结果就是12。

2.>>：右移运算符，带符号位。根据这个要移动的数字决定正负，如果是正数，那么就在前面补0，如果是负数就在前面补1。比如说 3>>2，3的二进制码为00000011，向右移动2位，就变成00000000，转化为十进制就是0了（3是正数所以在高位补0）。再比如说-3>>2，-3的二进制码为10000011，转化为补码（只要涉及到负数，就需要转换到补码计算，正数之所以不用转化，是因为他们的补码和原码是一致的）11111101，进行位移运算，就是11111111，这个是补码，需要再转回原码。那么就是取反+1，结果就是10000001，转化为十进制就是-1。

3.>>>：右移运算符，与上面的区别就是这个运算符是无符号的。不论正负，高位都补0。如果要用-3>>2来验证，因为高位补0，就需要把所有的位数都写全了。如果是int，那就要写成32位来运算。切记切记。上面很多因为高位的变化“取反再取反”会导致前面所有的位都没变所以我就简化了，但是这个>>>运算符不行哦，它会把负数变为正数。

三、Bytes.short2bytes(MAGIC, header);

protected static final short MAGIC = (short) 0xdabb;

1. 其中0xdabb是16进制的 那么它转化成二进制是11011010 10111011 最高位是1 要转为原码=10100101 01000100+1=1010010101000101=-9541
2. b[off + 1] = (byte) v; b[off + 0] = (byte) (v >>> 8);首先看这两行代码 第一句是直接把short转成byte 那么转换后的结果是直接取二进制11011010 10111011的后8位 然后再取反+1 得到的值是11000101=-69 后面一句表示是无符号向右移动8位 那么得出来的结果是11011010然后再取反+1=10100110=-38 其实byte数组中的每一个下标表示的是8个二进制位 只不过是以10进制显示给用户来看 中间就有很多转换的过程
3. 因此 一开始是设置 header[2] = (byte) (FLAG_REQUEST | serialization.getContentTypeId());(其中FLAG_REQUEST=10000000=-128) 那么任何小于128的值和FLAG_REQUEST或运算的时候 由于取得都是具体的一个bit的值 因此或运算就会把这个位置占住 后面解码进行判断的时候 只需要进行与运算 就知道在编码的时候是否有设置过这个值了