项目库房：github.com/bytedance/s…

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 层。

测验成果如下：

image.png

不同数据量级下 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 大致进程如下：

image.png

sonic-JIT 系统

  1. 初度运行时，依据 Go 反射来获取需求编译的 schema 信息（AST）；
  2. 结合 JSON 编解码算法生成一套自定义的中间代码 OP codes（SSA）；
  3. 将 OP codes 翻译为 Plan9 汇编（LL）；
  4. 运用第三方库 golang-asm 将 Plan 9 转为机器码（ASM）；
  5. 将生成的二进制码注入到内存 cache 中并封装为 go function（DL）；
  6. 后续解析，直接依据 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 数据节点，并结合树与数组结构描绘节点之间的层级关系。

image.png

sonic-ast 结构示意

sonic-ast 完成了一种有状况、可弹性的 JSON 解析进程：当运用者 get 某个 key 时，sonic 选用 skip 计算来轻量化越过要获取的 key 之前的 json 文本；关于该 key 之后的 JSON 节点，直接不做任何的解析处理；仅运用者真实需求的 key 才完全解析（转为某种 Go 原始类型）。因为节点转化相比解析 JSON 价值小得多，在并不需求完好数据的事务场景下收益相当可观。

尽管 skip 是一种轻量的文本解析（处理 JSON 操控字符“[”、“{”等），可是运用相似 gjson 这种朴实的 JSON 查找库时，往往会有相同路径查找导致的重复开支（见benchmark）。

针对该问题，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 源码进行了解。

功能测验

咱们以前文中的不同测验场景进行测验（测验代码见benchmark），得到成果如下：

图片

小数据（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 库！

相关链接

项目地址：github.com/bytedance/s…

BenchMark：github.com/bytedance/s…