上一篇文章《聊聊Unsafe的一些使用技巧》写作之后，阅读量很快超过了 1500，Kirito 在这里感谢大家的阅读啦，所以我又来更新了。如果你还没有阅读上一篇文章，我建议你先去看下，闲话不多说，开始今天的话题。

无论是日常开发还是竞赛，Unsafe 不常有而 ByteBuffer 常有，只介绍 Unsafe，让我的博文显得很“炫技”，为了证明“Kirito的技术分享”它可是一个正经的公众号，所以这篇文章会说到另一个比较贴地气的主角 ByteBuffer。我会把我这么多年打比赛的经验传授给你，只求你的一个三连。

从 DirectBuffer 的构造器说起

书接上文，我提到过 DirectBuffer 开辟的堆外内存其实就是通过 Unsafe 分配的，但没有详细介绍，今天就给他补上。看一眼 DirectBuffer 的构造函数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

DirectByteBuffer(int cap) {                   // package-private
    super(-1, 0, cap, cap);
    boolean pa = VM.isDirectMemoryPageAligned();
    int ps = Bits.pageSize();
    long size = Math.max(1L, (long)cap + (pa ? ps : 0));
    Bits.reserveMemory(size, cap);
    long base = 0;
    try {
        base = unsafe.allocateMemory(size);
    } catch (OutOfMemoryError x) {
        Bits.unreserveMemory(size, cap);
        throw x;
    }
    unsafe.setMemory(base, size, (byte) 0);
    if (pa && (base % ps != 0)) {
        // Round up to page boundary
        address = base + ps - (base & (ps - 1));
    } else {
        address = base;
    }
    cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
    att = null;
}

短短的十几行代码，蕴含了非常大的信息量，先说关键点

• long base = unsafe.allocateMemory(size); 调用 Unsafe 分配内存，返回内存首地址
• unsafe.setMemory(base, size, (byte) 0); 初始化内存为 0。这一行我们放在下节做重点介绍。
• Cleaner.create(this, new Deallocator(base, size, cap)); 设置堆外内存的回收器，不详细介绍了，可以参考我之前的文章《一文探讨堆外内存的监控与回收》。

仅构造器中的这一幕，便让 Unsafe 和 ByteBuffer 产生了千丝万缕的关联，发挥想象力的话，可以把 ByteBuffer 看做是 Unsafe 一系列内存操作 API 的 safe 版本。而安全一定有代价，在编程领域，一般都有一个常识，越是接近底层的事物，控制力越强，性能越好；越接近用户的事物，更易操作，但性能会差强人意。ByteBuffer 封装的 limit/position/capacity 等概念，用熟悉了之后我觉得比 Netty 后封装 的 ByteBuf 还要简便，但即使优秀如它，仍然有被人嫌弃的一面：大量的边界检查。

一个最吸引性能挑战赛选手去使用 Unsafe 操作内存，而不是 ByteBuffer 地方，便是边界检查。如示例代码一：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public ByteBuffer put(byte[] src, int offset, int length) {
    if (((long)length << 0) > Bits.JNI_COPY_FROM_ARRAY_THRESHOLD) {
        checkBounds(offset, length, src.length);
        int pos = position();
        int lim = limit();
        assert (pos <= lim);
        int rem = (pos <= lim ? lim - pos : 0);
        if (length > rem)
            throw new BufferOverflowException();
            Bits.copyFromArray(src, arrayBaseOffset,
                               (long)offset << 0,
                               ix(pos),
                               (long)length << 0);
        position(pos + length);
    } else {
        super.put(src, offset, length);
    }
    return this;
}

你不用关心上述这段代码在 DirectBuffer 中充当着什么作用，我想展示给你的仅仅是它的 checkBounds 和 一堆 if/else，尤其是追求极致性能的场景，极客们看到 if/else 会神经敏感地意识到分支预测的性能下降，第二意识是这坨代码能不能去掉。

如果你不希望有一堆边界检查，完全可以借助 Unsafe 实现一个自定义的 ByteBuffer，就像下面这样。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

public class UnsafeByteBuffer {

    private final long address;
    private final int capacity;
    private int position;
    private int limit;

    public UnsafeByteBuffer(int capacity) {
        this.capacity = capacity;
        this.address = Util.unsafe.allocateMemory(capacity);
        this.position = 0;
        this.limit = capacity;
    }

    public int remaining() {
        return limit - position;
    }

    public void put(ByteBuffer heapBuffer) {
        int remaining = heapBuffer.remaining();
        Util.unsafe.copyMemory(heapBuffer.array(), 16, null, address + position, remaining);
        position += remaining;
    }

    public void put(byte b) {
        Util.unsafe.putByte(address + position, b);
        position++;
    }

    public void putInt(int i) {
        Util.unsafe.putInt(address + position, i);
        position += 4;
    }

    public byte get() {
        byte b = Util.unsafe.getByte(address + position);
        position++;
        return b;
    }

    public int getInt() {
        int i = Util.unsafe.getInt(address + position);
        position += 4;
        return i;
    }

    public int position() {
        return position;
    }

    public void position(int position) {
        this.position = position;
    }

    public void limit(int limit) {
        this.limit = limit;
    }

    public void flip() {
        limit = position;
        position = 0;
    }

    public void clear() {
        position = 0;
        limit = capacity;
    }

}

在一些比赛中，为了避免选手进入无止境的内卷，Unsafe 通常是禁用的，但是也有一些比赛，允许使用 Unsafe 的一部分能力，让选手们放飞自我，探索可能性。例如 Unsafe#allocateMemory 是不会受到 -XX:MaxDirectMemory 和 -Xms 限制的，在这次第二届云原生编程挑战赛遭到了禁用，但 Unsafe#put 、Unsafe#get、Unsafe#copyMemory 允许被使用。 如果你一定希望使用 Unsafe 操作堆外内存，可以写出这样的代码，它跟示例代码一完成的是同样的操作。

1
2
3
4
5

byte[] src = ...;

ByteBuffer byteBuffer = ByteBuffer.allocateDirect(src.length);
long address = ((DirectBuffer)byteBuffer).address();
Util.unsafe.copyMemory(src, 16, null, address, src.length);

这便是我想介绍的第一个关键点：DirectByteBuffer 可以借助 Unsafe 完成内存级别细粒度的操作，从而绕开边界检查。

DirectByteBuffer 的内存初始化

注意到 DirectByteBuffer 构造器中有另一个涉及到 Unsafe 的操作： unsafe.setMemory(base, size, (byte) 0);。这段代码主要是为了给内存初始化 0。说实话，我是没有太懂这里的初始化操作，因为按照我的认知，默认值也是 0。在某些场景或者硬件下，内存操作是非常昂贵的，尤其是大片的内存被开辟时，这段代码可能会成为 DirectByteBuffer 的瓶颈。

如果希望分配内存时，不进行这段初始化逻辑，可以借助于 Unsafe 分配内存，再对 DirectByteBuffer 进行魔改。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

public class AllocateDemo {

    private Field addressField;
    private Field capacityField;
    
    public AllocateDemo() throws NoSuchFieldException {
        Field capacityField = Buffer.class.getDeclaredField("capacity");
        capacityField.setAccessible(true);
        Field addressField = Buffer.class.getDeclaredField("address");
        addressField.setAccessible(true);
    }
    
    public ByteBuffer allocateDirect(int cap) throws IllegalAccessException {
        long address = Util.unsafe.allocateMemory(cap);

        ByteBuffer byteBuffer = ByteBuffer.allocateDirect(1);
        Util.unsafe.freeMemory(((DirectBuffer) byteBuffer).address());

        addressField.setLong(byteBuffer, address);
        capacityField.setInt(byteBuffer, cap);

        byteBuffer.clear();
        return byteBuffer;
    }

}

经过这么一顿操作，我们便得到了一份没有初始化的 DirectByteBuffer，不过不用担心，一切都在正常工作，并且 setMemory for free!

聊聊 ByteBuffer 的零拷贝

算作是题外话了，主要是跟 ByteBuffer 相关的一个话题：零拷贝。 ByteBuffer 在作为读缓冲区时被使用时，有一部分小伙伴会选择使用加锁的方式访问内存，但其实这是非常错误的做法，应当使用 ByteBuffer 提供的 duplicate 和 slice 这两个方法。

并发读取缓冲的方案：

1
2
3
4
5
6

ByteBuffer byteBuffer = ByteBuffer.allocateDirect(1024);
ByteBuffer duplicate = byteBuffer.duplicate();
duplicate.limit(512);
duplicate.position(256);
ByteBuffer slice = duplicate.slice();
// use slice

这样便可以在不改变原始 ByteBuffer 指针的前提下，任意对 slice 后的 ByteBuffer 进行并发读取了。

总结

最近时间有限，白天工作，晚上还要抽时间打比赛，先分享这么多。更多性能优化小技巧，可以期待一下 1~2 个星期云原生比赛结束，我就开始继续发总结和其他调优方案。

本文阅读求个 1000，不过分吧！

一键三连，这次一定。

前言

记得初学 Java 那会，刚学完语法基础，就接触到了反射这个 Java 提供的特性，尽管在现在看来，这是非常基础的知识点，但那时候无疑是兴奋的，瞬间觉得自己脱离了“Java 初学者”的队伍。随着工作经验的积累，我也逐渐学习到了很多类似的让我为之而兴奋的知识点，Unsafe 的使用技巧无疑便是其中一个。

sun.misc.Unsafe 是 JDK 原生提供的一个工具类，包含了很多在 Java 语言看来很 cool 的操作，例如内存分配与回收、CAS 操作、类实例化、内存屏障等。正如其命名一样，由于其可以直接操作内存，执行底层系统调用，其提供的操作也是比较危险的。Unsafe 在扩展 Java 语言表达能力、便于在更高层（Java层）代码里实现原本要在更低层（C层）实现的核心库功能上起到了很大的作用。

从 JDK9 开始，Java 模块化设计的限制，使得非标准库的模块都无法访问到 sun.misc.Unsafe。但在 JDK8 中，我们仍然可以直接操作 Unsafe，再不学习，后面可能就没机会了。

前言

国庆假期一眨眼就过去了，本来在家躺平的很舒服，没怎么肝云原生编程挑战赛，传送门：https://tianchi.aliyun.com/s/8bf1fe4ae2aea736e692c31c6952042d ，偏偏对手们假期开始卷起来了，眼看就要被人反超了，吓得我赶紧继续优化了。比赛大概还有一个月才结束，Kirito 的详细方案也会在比赛结束后分享，这期间我会分享一些比赛中的一些通用优化或者细节知识点，例如本文就是这么一个例子。

趁着假期最后一天，分享一个很多人容易踩得一个坑：HeapByteBuffer 的使用问题。我们都知道 NIO 分装了 ByteBuffer 接口，使得 filechannel 的文件 IO API 变得非常的简单。ByteBuffer 主要有两个实现类

• HeapByteBuffer 堆内内存
• DirectByteBuffer 堆外内存

按我的个人经验，大多数情况，无论是读操作还是写操作，我都倾向于使用 DirectByteBuffer，主要是因为 HeapByteBuffer 在和 FileChannel 交互时，可能会有一些出乎大家意料的内部操作，也就是这篇文章的标题中提到的注意事项，这里先卖个关子。

先来看看这次比赛为什么要用到 HeapByteBuffer 呢？

原因一：赛题需要设计分级存储，并且提供了 6G 堆内内存 + 2G 堆外内存，一个最直接的思路便是使用内存来存储热点数据，而内存存储数据最方便的数据结构便是 ByteBuffer 了。

原因二：由于堆内 6G 远大于堆外 2G，且 JVM 参数不能调整，所以要想利用好堆内富余的内存去做缓存，非 HeapByteBuffer 莫属了。

可能有一些读者并没有关注赛题，我这里简化一下前言，可以直接理解为：有一块 2G 的 HeapByteBuffer 用于文件 IO，我们该如何利用。

前言

好久没有分享文件 IO 的小技巧了，依稀记得上次分享还是在上次。

第二届云原生编程挑战赛正在火热进行中，Kirito 也在做《针对冷热读写场景的RocketMQ存储系统设计》这个题目，不过参与的是内部赛道，没法跟外部的小伙伴们一起排名了。

众所周知，存储设计离不开文件 IO，将数据存储到文件中进行持久化，是大多数消息队列、数据库系统的常规操作。在比赛中，为了更贴近实际的生产场景，往往也会引入正确性检测阶段，以避免让选手设计一些仅仅支持内存行为的代码逻辑。试想一下，RocketMQ 或者 Mysql 在宕机之后因为索引丢失，而导致数据无法查询，这该是多么可怕的一件事！

正确性检测要求我们写入的数据能够被查询出来，没有丢失，按照我个人的参赛经验，通常分为三种级别

• 进程正常退出或者进程被 kill -15 中断
• 进程被 kill -9 中断
• 系统掉电

前言

这是一篇很久之前就想动笔写的文章，最近正好看到群里有小伙伴分享了 Dubbo 连接相关的文章，才又让我想起了这个话题。今天想跟大家聊的便是 Dubbo 中的连接控制这一话题。说到“连接控制”，可能有读者还没反应过来，但你对下面的配置可能不会感到陌生：

1

<dubbo:reference interface="com.foo.BarService" connections="10" />

如果你还不了解 Dubbo 中连接控制的用法，可以参考官方文档：https://dubbo.apache.org/zh/docs/advanced/config-connections/ ，话说最近 Dubbo 官方文档来了一次大换血，好多熟悉的文档差点都没找到在哪儿 Orz。

众所周知，dubbo 协议通信默认是长连接，连接配置功能用于决定消费者与提供者建立的长连接数。但官方文档只给出了该功能的使用方法，却并没有说明什么时候应该配置连接控制，本文将主要围绕该话题进行探讨。

本文也会涉及长连接相关的一些知识点。

转载自：https://zhuanlan.zhihu.com/p/21388517

论顺序的重要性

做饭的故事

今天女朋友加班，机智的她早已在昨晚准备好食材，回家只需下锅便可。谁知开会就是个无底洞，到了B1，还有B2，无穷匮也。

辛苦如她，为了能让她一回家就吃上热腾腾的饭菜，我准备亲自下厨，奉献出我的第一次。食材都已备好，我相信没有那么难，估摸着应该和我习以为常的流程处理差不多，开火 | 加食材 | 上配料 | 翻炒 | 出锅，啊哈，想想还有点小激动。

今天的晚饭是西红柿炒鸡蛋和胡萝卜炒肉，实际操作才发现，又遇到了一个大坑……

食材是这样的：

1
2

案板1号（西红柿炒鸡蛋的食材），从左向右依次放着：西红柿、鸡蛋、葱
案板2号（胡萝卜炒肉的食材），从左向右依次放着：蒜、胡萝卜丝、肉

食材在案板上整齐划一依次排开，我是先放西红柿呢，还是先放鸡蛋呢，还是先放葱呢？简单沟通后得知，案板上的食材是按顺序放好的，我只需要按顺序下锅即可。听着电视哼着90年代的老歌，三下五除二，两道菜如期完成。

闻着怪味，我知道第一次就这么失败了。

等她回家，一番检讨后，才知道是顺序放错了。每道菜都应该是从右往左依次放食材，即葱->鸡蛋->西红柿。这是逗我的么！？一般人所理解的按默认顺序不应该是从左往右嘛！

朋友们，到底应该是从左往右还是从右往左？

剥鸡蛋的故事

《格列佛游记》中记载了两个征战的强国，你不会想到的是，他们打仗竟然和剥鸡蛋的姿势有关。

很多人认为，剥鸡蛋时应该打破鸡蛋较大的一端，这群人被称作“大端（Big endian）派”。可是当今皇帝的祖父小时候吃鸡蛋的时候碰巧将一个手指弄破了。所以，他的父亲（当时的皇帝）就下令剥鸡蛋必须打破鸡蛋较小的一端，违令者重罚，由此产生了“小端（Little endian）派”。

老百姓们对这项命令极其反感，由此引发了6次叛乱，其中一个皇帝送了命，另一个丢了王位。据估计，先后几次有11000人情愿受死也不肯去打破鸡蛋较小的一端！

看到没有，仅仅是剥鸡蛋就能产生这么大的分歧，“大端”和“小端”有这么重要嘛！

字节序

字节

字节（Byte）作为计算机世界的计量单位，和大家手中的人民币多少多少“元”一个意思。反正，到了计算机的世界，说字节就对了，使用人家的基本计量单位，这是入乡随俗。

比如，一个电影是1G个字节（1GB），一首歌是10M个字节（10MB），一张图片是1K个字节（1KB）。

字节序

一元钱可以干嘛？啥也干不了，公交都不够坐的。一个字节可以干嘛？至少可以存一个字符。

当数据太大，一个字节存不下的时候，我们就得使用多个字节了。比如，我有两个分别需要4个字节存储的整数，为了方便说明，使用16进制表示这两个数，即0x12345678和0x11223344。有的人采用以下方式存储这个两个数字：

这个方案看起来不错，但是，又有人采用了以下方式：

蒙圈了吧，到底该用哪一种方式来存！两种方案虽有不同，但也有共识，即依次存储每一个数字，即先存0x12345678，再存0x11223344。大家的分歧在于，对于某一个要表示的值，因为只能一个字节一个字节的存嘛，我是把值的低位存到低地址，还是把值的高位存到低地址。前者使用的是“小端（Little endian）”字节序，即先存低位的那一端（两个数字的最低位分别是0x78、0x44），如上图中的第一个图；后者使用的是“大端（Big endian）”字节序，即先存高位的那一端（两个数字的最高位分别是0x12、0x11）,如上图中的第二个图。

由此也引发了计算机界的大端与小端之争，不同的CPU厂商并没有达成一致：

• x86，MOS Technology 6502，Z80，VAX，PDP-11等处理器为Little endian。
• Motorola 6800，Motorola 68000，PowerPC 970，System/370，SPARC（除V9外）等处理器为Big endian。
• ARM, PowerPC (除PowerPC 970外), DEC Alpha, SPARC V9, MIPS, PA-RISC and IA64的字节序是可配置的。

大端也好，小端也罢，就权当是个人爱好吧，只要你不影响别人就行，对不？

网络字节序

前面的大端和小端都是在说计算机自己，也被称作主机字节序。其实，只要自己能够自圆其说是没啥问题的。问题是，网络的出现使得计算机可以通信了。通信，就意味着相处，相处必须得有共同语言啊，得说普通话，要不然就容易会错意，下了一个小时的小电影发现打不开，理解错误了！

但是每个计算机都有自己的主机字节序啊，还都不依不饶，坚持做自己，怎么办？

TCP/IP协议隆重出场，RFC1700规定使用“大端”字节序为网络字节序，其他不使用大端的计算机要注意了，发送数据的时候必须要将自己的主机字节序转换为网络字节序（即“大端”字节序），接收到的数据再转换为自己的主机字节序。这样就与CPU、操作系统无关了，实现了网络通信的标准化。突然觉得，TCP/IP协议好任性啊有木有！

为了程序的兼容，你会看到，程序员们每次发送和接受数据都要进行转换，这样做的目的是保证代码在任何计算机上执行时都能达到预期的效果。

这么常用的操作，BSD Socket提供了封装好的转换接口，方便程序员使用。包括从主机字节序到网络字节序的转换函数：htons、htonl；从网络字节序到主机字节序的转换函数：ntohs、ntohl。当然，有了上面的理论基础，也可以编写自己的转换函数。

下面的一段代码可以用来判断计算机是大端的还是小端的，判断的思路是确定一个多字节的值（下面使用的是4字节的整数），将其写入内存（即赋值给一个变量），然后用指针取其首地址所对应的字节（即低地址的一个字节），判断该字节存放的是高位还是低位，高位说明是Big endian，低位说明是Little endian。

1
2
3
4
5
6
7
8
9
10
11
12

#include <stdio.h>
int main ()
{
  unsigned int x = 0x12345678;
  char *c = (char*)&x;
  if (*c == 0x78) {
    printf("Little endian");
  } else {
    printf("Big endian");
  }
  return 0;
}

身边的字节序

字符编码方式UTF-16、UTF-32同样面临字节序的问题，因为他们分别使用2个字节和4个字节编码Unicode字符，一旦某个值用多个字节表示，就必须要考虑存储的顺序了。于是，采用了最简单粗暴的方式，给文件头部写几个字符，用来表示是大端呢还是小端：

头部的字符 编码 字节序 FF FE UTF-16/UCS-2 Little endian FE FF UTF-16/UCS-2 Big endian FF FE 00 00 UTF-32/UCS-4 Little endian 00 00 FE FF UTF-32/UCS-4 Big-endian

这里不得不提一下UTF-8啊，明明人家是单个字节的，不存在什么字节序的问题。微软为了统一UTF-X，硬生生给他的头部也加了几个字符！是的，这几个字符就是BOM（Byte Order Mark），这就是Windows下的UTF-8。

相信很多人都被UTF-8的BOM给坑过，多了这个BOM的UTF-8文件，会导致很多问题啊。比如，写的Shell脚本，内容为#!/usr/bin/env bash，在UTF-8有BOM和UTF-8无BOM的编码下，对应的16进制为：

所以，有BOM的话，Shell解释器就报错啦。原因在于，解释器希望遇到#!/usr/bin/env bash，而使用UTF-8有BOM进行编码的内容会多了3个字节的EF BB BF。

对于UTF-8和UTF-8无BOM两种编码格式，我们更多的使用UTF-8无BOM。

在很多追求性能的程序挑战赛中，经常会遇到一个操作：将 String 转换成 Integer/Long。如果你没有开发过高并发的系统，或者没有参加过任何性能挑战赛，可能会有这样的疑问：这有啥好讲究的，Integer.valueOf/Long.valueOf 又不是不能用。实际上，很多内置的转换工具类只满足了功能性的需求，在高并发场景下，可能会是热点方法，成为系统性能的瓶颈。

文章开头，我先做一下说明，本文的测试结论出自：https://kholdstare.github.io/technical/2020/05/26/faster-integer-parsing.html 。测试代码基于 C++，我会在翻译原文的同时，添加了部分自己的理解，以协助读者更好地理解其中的细节。

前言

之前在分享《海量无序数据寻找第 K 大的数》这篇文章时，就已经提到过我参加了阿里云举办的《第三届数据库大赛创新上云性能挑战赛–高性能分析型查询引擎赛道》，传送门：https://tianchi.aliyun.com/competition/entrance/531895/introduction。 截止到 8 月 20 日，终于结束了漫长的赛程。作为阿里云员工的我，按照赛题规定，只能参加初赛，不能参加复赛，出于不影响比赛的目的，终于等到了比赛完全结束，才动笔写下了这篇参赛总结。

照例先说成绩，这里贴一下排行榜，总共有 1446 只队伍，可以看到不少学生和其他公司的员工都参赛了。

我的成绩是第 14 名（普哥忙于 KPI，没有能带飞我，diss 一下嘿嘿），内部排名也是进入了前五，虽然被剥夺了参加复赛的资格，但是也给了内部的奖励作为补偿，奖品是啥呢？

前言

今天要聊的技术是序列化，这不是我第一次写序列化相关的文章了，今天动笔之前，我还特地去博客翻了下我博客早期的一篇序列化文章（如下图），竟然都过去 4 年了。

为什么又想聊序列化了呢？因为最近的工作用到了序列化相关的内容，其次，这几年 Dubbo 也发生了翻天覆地的变化，其中 Dubbo 3.0 主推的 Tripple 协议，更是打着下一代 RPC 通信协议的旗号，有取代 Dubbo 协议的势头。而 Tripple 协议使用的便是 Protobuf 序列化方案。

另外，Dubbo 社区也专门搞了一个序列化压测的项目：https://github.com/apache/dubbo-benchmark.git ，本文也将围绕这个项目，从性能维度展开对 Dubbo 支持的各个序列化框架的讨论。

当我们聊序列化的时候，我们关注什么？

最近几年，各种新的高效序列化方式层出不穷，最典型的包括：

• 专门针对 Java 语言的：JDK 序列化、Kryo、FST
• 跨语言的：Protostuff，ProtoBuf，Thrift，Avro，MsgPack 等等

为什么开源社区涌现了这么多的序列化框架，Dubbo 也扩展了这么多的序列化实现呢？主要还是为了满足不同的需求。

序列化框架的选择主要有以下几个方面：

1. 跨语言。是否只能用于 java 间序列化 / 反序列化，是否跨语言，跨平台。
2. 性能。分为空间开销和时间开销。序列化后的数据一般用于存储或网络传输，其大小是很重要的一个参数；解析的时间也影响了序列化协议的选择，如今的系统都在追求极致的性能。
3. 兼容性。系统升级不可避免，某一实体的属性变更，会不会导致反序列化异常，也应该纳入序列化协议的考量范围。

和 CAP 理论有点类似，目前市面上很少有一款序列化框架能够同时在三个方面做到突出，例如 Hessian2 在兼容性方面的表现十分优秀，性能也尚可，Dubbo 便使用了其作为默认序列化实现，而性能方面它其实是不如 Kryo 和 FST 的，在跨语言这一层面，它表现的也远不如 ProtoBuf，JSON。

其实反过来想想，要是有一个序列化方案既是跨语言的，又有超高的性能，又有很好的兼容性，那不早就成为分布式领域的标准了？其他框架早就被干趴了。

大多数时候，我们是挑选自己关注的点，找到合适的框架，满足我们的诉求，这才导致了序列化框架百花齐放的局面。

性能测试

很多序列化框架都宣称自己是“高性能”的，光他们说不行呀，我还是比较笃信“benchmark everything”的箴言，这样得出的结论，更能让我对各个技术有自己的认知，避免人云亦云，避免被不是很权威的博文误导。

怎么做性能测试呢？例如像这样？

1
2
3

long start = System.currentTimeMillis();
measure();
System.out.println(System.currentTimeMillis()-start);

貌似不太高大上，但又说不上有什么问题。如果你这么想，那我推荐你了解下 JMH 基准测试框架，我之前写过的一篇文章《JAVA 拾遗 — JMH 与 8 个测试陷阱》推荐你先阅读以下。

事实上，Dubbo 社区的贡献者们早就搭建了一个比较完备的 Dubbo 序列化基础测试工程：https://github.com/apache/dubbo-benchmark.git。

你只要具备基本的 JMH 和 Dubbo 的知识，就可以测试出在 Dubbo 场景下各个序列化框架的表现。

我这里也准备了一份我测试的报告，供读者们参考。如果大家准备自行测试，不建议在个人 windows/mac 上 benchmark，结论可能会不准确。我使用了两台阿里云的 ECS 来进行测试，测试环境：Aliyun Linux，4c8g，启动脚本：

1

java -server -Xmx2g -Xms2g -XX:MaxDirectMemorySize=1g -XX:+UseG1GC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/home/admin/

为啥选择这个配置？我手上正好有两台这样的资源，没有特殊的设置~，况且从启动脚本就可以看出来，压测程序不会占用太多资源，我都没用满。

测试工程介绍：

1
2
3
4
5
6
7
8
9

public interface UserService {
    public boolean existUser(String email);

    public boolean createUser(User user);

    public User getUser(long id);

    public Page<User> listUser(int pageNo);
}

一个 UserService 接口对业务应用中的 CRUD 操作。server 端以不同的序列化方案提供该服务，client 使用 JMH 进行多轮压测。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

@Benchmark
    @BenchmarkMode({Mode.Throughput })
    @OutputTimeUnit(TimeUnit.SECONDS)
    @Override
    public boolean existUser() throws Exception {
      // ...
    }

    @Benchmark
    @BenchmarkMode({Mode.Throughput})
    @OutputTimeUnit(TimeUnit.SECONDS)
    @Override
    public boolean createUser() throws Exception {
      // ...
    }

    @Benchmark
    @BenchmarkMode({Mode.Throughput})
    @OutputTimeUnit(TimeUnit.SECONDS)
    @Override
    public User getUser() throws Exception {
      // ...
    }

    @Benchmark
    @BenchmarkMode({Mode.Throughput})
    @OutputTimeUnit(TimeUnit.SECONDS)
    @Override
    public Page<User> listUser() throws Exception {
      // ...
    }

整体的 benchmark 框架结构如上，详细的实现，可以参考源码。我这里只选择的一个评测指标 Throughput，即吞吐量。

省略一系列压测过程，直接给出结果：

Kryo

1
2
3
4
5

Benchmark           Mode  Cnt      Score      Error  Units
Client.createUser  thrpt    3  20913.339 ± 3948.207  ops/s
Client.existUser   thrpt    3  31669.871 ± 1582.723  ops/s
Client.getUser     thrpt    3  29706.647 ± 3278.029  ops/s
Client.listUser    thrpt    3  17234.979 ± 1818.964  ops/s

Fst

1
2
3
4
5

Benchmark           Mode  Cnt      Score       Error  Units
Client.createUser  thrpt    3  15438.865 ±  4396.911  ops/s
Client.existUser   thrpt    3  25197.331 ± 12116.109  ops/s
Client.getUser     thrpt    3  21723.626 ±  7441.582  ops/s
Client.listUser    thrpt    3  15768.321 ± 11684.183  ops/s

Hessian2

1
2
3
4
5

Benchmark           Mode  Cnt      Score      Error  Units
Client.createUser  thrpt    3  22948.875 ± 2005.721  ops/s
Client.existUser   thrpt    3  34735.122 ± 1477.339  ops/s
Client.getUser     thrpt    3  20679.921 ±  999.129  ops/s
Client.listUser    thrpt    3   3590.129 ±  673.889  ops/s

FastJson

1
2
3
4
5

Benchmark           Mode  Cnt      Score      Error  Units
Client.createUser  thrpt    3  26269.487 ± 1667.895  ops/s
Client.existUser   thrpt    3  29468.687 ± 5152.944  ops/s
Client.getUser     thrpt    3  25204.239 ± 4326.485  ops/s
Client.listUser    thrpt    3   9823.574 ± 2087.110  ops/s

Tripple

1
2
3
4
5

Benchmark           Mode  Cnt      Score       Error  Units
Client.createUser  thrpt    3  19721.871 ±  5121.444  ops/s
Client.existUser   thrpt    3  35350.031 ± 20801.169  ops/s
Client.getUser     thrpt    3  20841.078 ±  8583.225  ops/s
Client.listUser    thrpt    3   4655.687 ±   207.503  ops/s

怎么看到这个测试结果呢？createUser、existUser、getUser 这几个方法测试下来，效果是参差不齐的，不能完全得出哪个框架性能最优，我的推测是因为序列化的数据量比较简单，量也不大，就是一个简单的 User 对象；而 listUser 的实现是返回了一个较大的 List<User> ，可以发现，Kryo 和 Fst 序列化的确表现优秀，处于第一梯队；令我意外的是 FastJson 竟然比 Hessian 还要优秀，位列第二梯队；Tripple（背后是 ProtoBuf）和 Hessian2 位列第三梯队。

当然，这样的结论一定受限于 benchmark 的模型，测试用例中模拟的 CRUD 也不一定完全贴近业务场景，毕竟业务是复杂的。

怎么样，这样的结果是不是也符合你的预期呢？

Dubbo 序列化二三事

最后，聊聊你可能知道也可能不知道的一些序列化知识。

hession-lite

Dubbo 使用的 Hessian2 其实并不是原生的 Hessian2 方案。注意看源码中的依赖：

1
2
3
4

<dependency>
  <groupId>com.alibaba</groupId>
  <artifactId>hessian-lite</artifactId>
</dependency>

最早是阿里开源的 hessian-lite，后来随着 Dubbo 贡献给了 Apache，该项目也一并进入了 Apache，github 地址：https://github.com/apache/dubbo-hessian-lite。相比原生 Hessian2，Dubbo 独立了一个仓库致力于在 RPC 场景下，发挥出更高的性能以及满足一些定制化的需求。

在 IO 线程中进行序列化

Dubbo 客户端在高版本中默认是在业务线程中进行序列化的，而不是 IO 线程，你可以通过 decode.in.io 控制序列化与哪个线程绑定

1
2
3
4
5

<dubbo:reference id="userService" check="false"
                 interface="org.apache.dubbo.benchmark.service.UserService"
                 url="dubbo://${server.host}:${server.port}">
    <dubbo:parameter key="decode.in.io" value="true" />
</dubbo:reference>

在 benchmark 时，我发现 IO 线程中进行序列化，性能会更好，这可能和序列化本身是一个耗费 CPU 的操作，多线程无法加速反而会导致更多的竞争有关。

SerializationOptimizer

某些序列化实现，例如 Kryo 和 Fst 可以通过显示注册序列化的类来进行加速，如果想利用该特性来提升序列化性能，可以实现 org.apache.dubbo.common.serialize.support.SerializationOptimizer 接口。一个示例：

1
2
3
4
5
6

public class SerializationOptimizerImpl implements SerializationOptimizer {
    @Override
    public Collection<Class<?>> getSerializableClasses() {
        return Arrays.asList(User.class, Page.class, UserService.class);
    }
}

按照大多数人的习惯，可能会觉得这很麻烦，估计很少有用户这么用。注意客户端和服务端需要同时开启这一优化。

别忘了在 protocol 上配置指定这一优化器：

1

<dubbo:protocol name="dubbo" host="${server.host}" server="netty4" port="${server.port}" serialization="kryo" optimizer="org.apache.dubbo.benchmark.serialize.SerializationOptimizerImpl"/>

序列化方式由服务端指定

一般而言，Dubbo 框架使用的协议（默认是 dubbo）和序列化方式（默认是 hessian2）是由服务端指定的，不需要在消费端指定。因为服务端是服务的提供者，拥有对服务的定义权，消费者在订阅服务收到服务地址通知时，服务地址会包含序列化的实现方式，Dubbo 以这样的契约方式从而实现 consumer 和 provider 的协同通信。

在大多数业务应用，应用可能既是服务 A 的提供者，同时也是服务 B 的消费者，所以建议在架构决策者层面协商固定出统一的协议，如果没有特殊需求，保持默认值即可。

但如果应用仅仅作为消费者，而又想指定序列化协议或者优化器（某些特殊场景），注意这时候配置 protolcol 是不生效的，因为没有服务提供者是不会触发 protocol 的配置流程的。可以像下面这样指定消费者的配置：

1
2
3
4
5

<dubbo:reference id="userService" check="false"
                 interface="org.apache.dubbo.benchmark.service.UserService"
                 url="dubbo://${server.host}:${server.port}?optimizer=org.apache.dubbo.benchmark.serialize.SerializationOptimizerImpl&amp;serialization=kryo">
    <dubbo:parameter key="decode.in.io" value="true" />
</dubbo:reference>

& 代表 &，避免 xml 中的转义问题

总结

借 Dubbo 中各个序列化框架的实现，本文探讨了选择序列化框架时我们的关注点，并探讨了各个序列化实现在 Dubbo 中具体的性能表现， 给出了详细的测试报告，同时，也给出了一些序列化的小技巧，如果在 Dubbo 中修改默认的序列化行为，你可能需要关注这些细节。

最后再借 Dubbo3 支持的 Tripple 协议来聊一下技术发展趋势的问题。我们知道 json 能替代 xml 作为众多前后端开发者耳熟能详的一个技术，并不是因为其性能如何如何，而是在于其恰如其分的解决了大家的问题。一个技术能否流行，也是如此，一定在于其帮助用户解决了痛点。至于解决了什么问题，在各个历史发展阶段又是不同的，曾经，Dubbo2.x 凭借着其丰富的扩展能力，强大的性能，活跃度高的社区等优势帮助用户解决一系列的难题，也获得了非常多用户的亲来；现在，Dubbo3.x 提出的应用级服务发现、统一治理规则、Tripple 协议，也是在尝试解决云原生时代下的难题，如多语言，适配云原生基础设施等，追赶时代，帮助用户。

前言

Arthas 的 watch 指令一直是我排查线上问题时使用最多的指令，没有之一。而按照条件进行 watch 也是很常见的一个需求，例如线上一个方法会有大量的调用，而我们可以按照指定的条件，watch 到我们希望观察的那一次调用。

说实话，我对 Arthas 也没有什么研究，一开始还真不清楚原来 Arthas watch 可以按条件过滤，翻看一下官方文档：https://arthas.aliyun.com/doc/watch#id6

条件表达式的例子

1
2
3
4
5
6
7

$ watch demo.MathGame primeFactors "{params[0],target}" "params[0]<0"
Press Ctrl+C to abort.
Affect(class-cnt:1 , method-cnt:1) cost in 68 ms.
ts=2018-12-03 19:36:04; [cost=0.530255ms] result=@ArrayList[
    @Integer[-18178089],
    @MathGame[demo.MathGame@41cf53f9],
]