sonic：基于 JIT 武艺的开源全场景高功能 JSON 库

项目货仓：
https://github.com/bytedance/sonic

sonic 是字节跳动开源的一款 Golang JSON 库，基于即时编译（Just-In-Time Compilation）与向量化编程（Single Instruction Multiple Data）武艺，大幅提升了 Go 步骤的 JSON 编解码功能。同时团结 lazy-load 计划头脑，它也为不同业务场景打造了一套全盘高效的 API。

自 2021 年 7 月份公布以来， sonic 已被抖音、今天头条等业务接纳，累计为字节跳动节流了数十万 CPU 核。

为什么要自研 JSON 库

JSON（JavaScript Object Notation）以其简便的语法和机动的自形貌才能，被广泛使用于各互联网业务。但是 JSON 由于实质是一种文本协议，且没有相似 Protobuf 的欺压模子束缚（schema），编解码听从屡屡十分低下。再加上有些业务开发者对 JSON 库的不恰中选型与使用，终极招致办事功能急剧劣化。

在字节跳动，我们也碰到了上述成绩。依据此前统计的公司 CPU 占比 TOP 50 办事的功能分析数据，JSON 编解码开支总体接近 10%，单个业务占比乃至凌驾 40%，提升 JSON 库的功能至关紧张。因此我们对业界现有 Go JSON 库举行了一番评价测试。

起首，依据主流 JSON 库 API，我们将它们的使用办法分为三种：

泛型（generic）编解码：JSON 没有对应的 schema，只能依据自形貌语义将读取到的 value 表明为对应言语的运转时目标，比如：JSON object 转化为 Go map[string]interface{}；

定型（binding）编解码：JSON 有对应的 schema，可以同时团结模子界说（Go struct）与 JSON 语法，将读取到的 value 绑定到对应的模子字段上去，同时完成数据剖析与校验；

查找（get）& 修正（set）：指定某种端正的查找途径（寻常是 key 与 index 的聚集），获取必要的那局部 JSON value 并处理。

其次，我们依据样本 JSON 的 key 数目和深度分为三个量级：

小（small）：400B，11 key，深度 3 层；

中（medium）：110KB，300+ key，深度 4 层（实践业务数据，此中有多量的嵌套 JSON string)；

大（large）：550KB，10000+ key，深度 6 层。

测试后果如下：

不同数据量级下 JSON 库功能体现

后果体现：现在这些 JSON 库均无法在各场景下都坚持最优功能，即使是如今使用最广泛的第三方库 json-iterator，在泛型编解码、大数据量级场景下的功能也满意不了我们的必要。

JSON 库的基准编解码功能固然紧张，但是对不同场景的最优婚配更紧张 —— 于是我们走上了自研 JSON 库的路途。

开源库 sonic 武艺原理

由于 JSON 业务场景繁复，指望经过单一算法来优化并不实际。于是在计划 sonic 的历程中，我们参考了其他范畴/言语的优化头脑（不仅限于 JSON），将其交融到各个处理环节中。此中较为中心的武艺有三块：JIT、lazy-load 与 SIMD 。

JIT

关于有 schema 的定型编解码场景而言，很多运算但是不必要在“运转时”实行。这里的“运转时”是指步骤真正开头剖析 JSON 数据的时间段。

举个例子，假如业务模子中确定了某个 JSON key 的值一定是布尔典范，那么我们就可以在序列化阶段直接输入这个目标对应的 JSON 值（‘true’或‘false’），并不必要再反省这个目标的具体典范。

sonic-JIT 的中心头脑就是：将模子表明与数据处理逻辑分散，让前者在“编译期”安稳下去。

这种头脑也存在于标准库和某些第三方 JSON 库，如 json-iterator 的函数组装形式：把 Go struct 拆分析释成一个个字段典范的编解码函数，然后组装并缓存为整个目标对应的编解码器（codec），运转时再加载出来处理 JSON。但是这种完成难以制止转化成多量 interface 和 function 调用栈，随着 JSON 数据量级的增长，function-call 开支也成倍扩大。仅有将模子表明逻辑真正编译出来，完成 stack-less 的实行体，才干最大化 schema 带来的功能收益。

业界完成办法现在主要有两种：代码天生 code-gen（或模版 template）和 即时编译 JIT。前者的优点是库开发者完成起来相对简便，缺陷是增长业务代码的维护本钱和范围性，无法做到秒级热更新——这也是代码天生办法的 JSON 库受众并不广泛的缘故之一。JIT 则将编译历程移到了步骤的加载（或初次剖析）阶段，只必要提供 JSON schema 对应的布局体典范信息，就可以一次性编译天生对应的 codec 并高效实行。

sonic-JIT 大抵历程如下：

sonic-JIT 体系

初次运转时，基于 Go 反射来获取必要编译的 schema 信息；
团结 JSON 编解码算法天生一套自界说的正中代码 OP codes；
将 OP codes 翻译为 Plan9 汇编；
使用第三方库 golang-asm 将 Plan 9 转为机器码；
将天生的二进制码注入到内存 cache 中并封装为 go function；
后续剖析，直接依据 type ID （rtype.hash）从 cache 中加载对应的 codec 处理 JSON。

从终极完成的后果来看，sonic-JIT 天生的 codec 功能不仅好于 json-iterator，乃至凌驾了代码天生办法的 easyjson（见后文“功能测试”章节）。这一方面跟底层文本处理算子的优化有关（见后文“SIMD & asm2asm”章节），另一方面来自于 sonic-JIT 能控制底层 CPU 指令，在运转时创建了一套独立高效的 ABI（Application Binary Interface）体系：

将使用经常的变量放到安稳的存放器上（如 JSON buffer、布局体指针），尽力制止 memory load & store；
本人维护变量栈（内存池），制止 Go 函数栈扩展；
主动天生跳转表，增速 generic decoding 的分支跳转；
使用存放器转达参数（如今 Go Assembly 并未支持，见“SIMD & asm2asm”章节）。

Lazy-load

关于大局部 Go JSON 库，泛型编解码是它们功能体现最差的场景之一，但是由于业务本身必要或业务开发者的选型不妥，它屡屡也是被使用得最经常的场景。

泛型编解码功能差仅仅是由于没有 schema 吗？但是不然。我们可以比力一下 C++ 的 JSON 库，如 rappidjson、simdjson，它们的剖析办法都是泛型的，但功能仍旧很好（simdjson 可达 2GB/s 以上）。标准库泛型剖析功能差的基本缘故在于它接纳了 Go 原生泛型——interface（map[string]interface{}）作为 JSON 的编解码目标。

这但是是一种糟糕的选择：起首是数据反序列化的历程中，map 插进的开支很高；其次在数据序列化历程中，map 遍历也远不如数组高效。

回过头来看，JSON 本身就具有完备的自形貌才能，假如我们用一种与 JSON AST 更贴近的数据布局来形貌，不仅可以让转换历程愈加简便，乃至可以完成按需加载（lazy-load）——这便是 sonic-ast 的中心逻辑：它是一种 JSON 在 Go 中的编解码目标，用 node {type, length, pointer} 表现随意一个 JSON 数据节点，并团结树与数组布局形貌节点之间的层级干系。

sonic-ast 布局表现

sonic-ast 完成了一种有形态、可伸缩的 JSON 剖析历程：当使用者 get 某个 key 时，sonic 接纳 skip 盘算来轻量化跳过要获取的 key 之前的 json 文本；关于该 key 之后的 JSON 节点，直接不做任何的剖析处理；仅使用者真正必要的 key 才完全剖析（转为某种 Go 原始典范）。由于节点转换比拟剖析 JSON 代价小得多，在并不必要完备数据的业务场景下收益相当可观。

固然 skip 是一种轻量的文本剖析（处理 JSON 控制字符“[”、“{”等），但是使用相似 gjson 这种地道的 JSON 查找库时，屡屡会有相反途径查找招致的反复开支。

针对该成绩，sonic 在关于子节点 skip 处理历程增长了一个步调，将跳过 JSON 的 key、起始位、完毕位纪录下去，分派一个 Raw-JSON 典范的节点保存下去，如此二次 skip 就可以直接基于节点的 offset 举行。同时 sonic-ast 支持了节点的更新、插进和序列化，乃至支持将随意 Go types 转为节点并保存下去。

换言之，sonic-ast 可以作为一种通用的泛型数据容器交换 Go interface，在协议转换、动态署理等办事场景有宏大潜力。

SIMD & asm2asm

无论是定型编解码场景照旧泛型编解码场景，中心都离不开 JSON 文本的处理与盘算。此中一些成绩在业界以前有比力成熟高效的处理方案，如浮点数转字符串算法 Ryu，整数转字符串的查表法等，这些都被完成到 sonic 的底层文本算子中。

另有一些成绩逻辑相对简便，但是约莫碰面临较大数目级的文本，如 JSON string 的 unquote\quote 处理、空缺字符的跳过等。此时我们就必要某种武艺伎俩来提升处理才能。SIMD 就是如此一种用于并行处理大范围数据的武艺，现在大局部 CPU 已具有 SIMD 指令集（比如 Intel AVX），并且在 simdjson 中有比力告捷的实践。

底下是一段 sonic 中 skip 空缺字符的算法代码：

#if USE_AVX2 // 一次比力比力32个字符 while (likely(nb >= 32)) { // vmovd 将单个字符转成YMM __m256i x = _mm256_load_si256 ((const void *)sp); // vpcmpeqb 比力字符，同时为了富裕使用CPU 超标量特性使用4 倍循环 __m256i a = _mm256_cmpeq_epi8 (x, _mm256_set1_epi8(' ')); __m256i b = _mm256_cmpeq_epi8 (x, _mm256_set1_epi8('\t')); __m256i c = _mm256_cmpeq_epi8 (x, _mm256_set1_epi8('\n')); __m256i d = _mm256_cmpeq_epi8 (x, _mm256_set1_epi8('\r')); // vpor 交融4次后果 __m256i u = _mm256_or_si256 (a, b); __m256i v = _mm256_or_si256 (c, d); __m256i w = _mm256_or_si256 (u, v); // vpmovmskb 将比力后果按位展现 if ((ms = _mm256_movemask_epi8(w)) != -1) { _mm256_zeroupper(); // tzcnt 盘算末了零的个数N return sp - ss + __builtin_ctzll(~(uint64_t)ms); } /* move to next block */ sp += 32; nb -= 32; } /* clear upper half to avoid AVX-SSE transition penalty */ _mm256_zeroupper(); #endif

sonic 中 strnchr() 完成（SIMD 局部）

开发者们会发觉这段代码但是是用 C 言语编写的 —— 但是 sonic 中绝大大多文本处理函数都是用 C 完成的：一方面 SIMD 指令集在 C 言语下有较好的封装，完成起来较为容易；另一方面这些 C 代码经过 clang 编译能富裕享用其编译优化带来的提升。为此我们开发了一套 x86 汇编转 Plan9 汇编的东西 asm2asm，将 clang 输入的汇编经过 Go Assembly 机制静态嵌入到 sonic 中。同时在 JIT 天生的 codec 中我们使用 asm2asm 东西盘算好的 C 函数 PC 值，直接调用 CALL 指令跳转，从而绕过 Go Assembly 不克不及存放器传参的限定，压榨最初一丝 CPU 功能。

别的

除了上述提到的武艺外，sonic 内里另有很多的细节优化，好比使用 RCU 交换 sync.Map 提升 codec cache 的加载速率，使用内存池变小 encode buffer 的内存分派，等等。这里限于篇幅便不具体掀开先容了，感兴致的同砚可以自行搜刮阅读 sonic 源码举行了解。

功能测试

我们从前文中的不同测试场景举行测试，取得后果如下：

小数据（400B，11 个 key，深度 3 层）

中数据（110KB，300+ key，深度 4 层）

大数据（550KB，10000+ key，深度 6 层）

可以看到 sonic 在几乎一切场景下都处于抢先（sonic-ast 由于直接使用了 Go Assembly 导入的 C 函数招致小数据集下有一定功能折损）

均匀编码功能较 json-iterator 提升 240% ，均匀解码功能较 json-iterator 提升 110% ；
单 key 修正才能较 sjson 提升 75% 。

并且在消费情况中，sonic 中也验证了精良的收益，办事巅峰期占用核数变小将近三分之一：

字节某办事在 sonic 上线前后的 CPU 占用（核数）比力

结语

由于底层基于汇编举行开发，sonic 如今仅支持 amd64 架构下的 darwin/linux 平台，后续会渐渐扩展到别的利用体系及架构。除此之外，我们也思索将 sonic 在 Go 言语上的告捷履历移植到不同言语及序列化协议中。现在 sonic 的 C++ 版本正在开发中，其定位是基于 sonic 中心头脑及底层算子完成一套通用的高功能 JSON 编解码接口。

克日，sonic 公布了第一个大版本 v1.0.0，标志着其除了可被企业机动用于消费情况，也正在积极呼应社区需求、拥抱开源生态。我们渴望 sonic 将来在使用场景和功能方面可以有更多打破，接待开发者们到场过来奉献 PR，一同打造业界最佳的 JSON 库！

干系链接

项目地点：https://github.com/bytedance/sonic

BenchMark：https://github.com/bytedance/sonic/blob/main/bench.sh