对比 fastjson
,gjson
,jsonparser
的性能以及优缺点。
这篇文章深入源码分析一下在 Go 中标准库是如何解析 JSON 的,然后再看看有哪些比较流行的 Json 解析库,以及这些库都有什么特点,在什么场景下能更好的帮助我们进行开发。
This article is first published in the medium MPP plan. If you are a medium user, please follow me on the medium. Thank you very much.
其实本来我是没打算去看 JSON 库的性能问题的,但是最近我对我的项目做了一次 pprof,从下面的火焰图中可以发现在业务逻辑处理中,有一半多的性能消耗都是在 JSON 解析过程中,所以就有了这篇文章。
这篇文章深入源码分析一下在 Go 中标准库是如何解析 JSON 的,然后再看看有哪些比较流行的 Json 解析库,以及这些库都有什么特点,在什么场景下能更好的帮助我们进行开发。
主要介绍分析以下几个库(2024-06-13):
库名 | Star |
---|---|
标准库 JSON Unmarshal | |
valyala/fastjson | 2.2 k |
tidwall/gjson | 13.8 k |
buger/jsonparser | 5.4 k |
标准库 JSON Unmarshal
|
|
官方的 JSON 解析库需要传两个参数,一个是需要被序列化的对象,另一个是表示这个对象的类型。
在真正执行 JSON 解析之前会调用 reflect.ValueOf
来获取参数 v 的反射对象。然后会获取到传入的 data 对象的开头非空字符来界定该用哪种方式来进行解析。
|
|
如果被解析的对象是以[
开头,那么表示这是个数组对象会进入到 scanBeginArray 分支;如果是以{
开头,表明被解析的对象是一个结构体或 map,那么进入到 scanBeginObject 分支 等等。
小结
通过看 Unmarshal 源码中可以看到其中使用了大量的反射来获取字段值,如果是多层嵌套的 JSON 的话,那么还需要递归进行反射获取值,可想而知性能是非常差的了。
但是如果对性能不是那么看重的话,直接使用它其实是一个非常好的选择,功能完善的同时并且官方也一直在迭代优化,说不定在以后的版本中性能也会得到质的飞跃。并且他应该是唯一一个可以直接把JSON对象转成 go struct 的。
fastjson
这个库的特点和它的名字一样就是快,它的介绍页是这么说的:
Fast. As usual, up to 15x faster than the standard encoding/json.
它的使用也是非常的简单,如下:
|
|
使用 fastjson 首先要将被解析的 JSON 串交给 Parser 解析器进行解析,然后通过 Parse 方法返回的对象来获取。如果是嵌套对象可以直接在 Get 方法传参的时候传入相应的父子 key 即可。
分析
fastjson
在设计上和标准库 Unmarshal
不同的是,它将 JSON 解析划分为两部分:Parse、Get。
Parse 负责将 JSON 串解析成为一个结构体并返回,然后通过返回的结构体来获取数据。在 Parse 解析的过程是无锁的,所以如果想要在并发地调用 Parse 进行解析需要使用 ParserPool
fastjson 是从上往下依次遍历 JSON ,然后解析好的数据存放在 Value 结构体中:
|
|
这个结构体非常简成:
o Object
:表示被解析的结构是一个对象;a []*Value
:表示表示被解析的结构是个数组;s string
:如果被解析的结构不是对象也不是数组,那么其他类型的值会以字符串的形式存放在这个字段中;t Type
:表示这个结构的类型,有 TypeObject、TypeArray、TypeString、TypeNumber等。
|
|
这个结构存放对象的递归结构。如果把上面例子中的 JSON 串解析完毕之后就是这样一个结构:
代码
在代码实现上,由于没有了反射部分的代码,所以整个解析过程变得非常的清爽。我们直接看看主干部分的解析:
|
|
parseValue 会根据字符串的第一个非空字符来判断要解析的类型。这里用一个对象类型来做解析:
|
|
parseObject 函数也非常简单,在循环体中会获取 key 值,然后调用 parseValue 递归解析 value 值,从上往下依次解析 JSON 对象,直到最后遇到 }
退出。
小结
通过上面的分析可以知道 fastjson
在实现上比标准库简单不少,性能也高上不少。使用 Parse 解析好 JSON 树之后可以多次反复使用,避免了需要反复解析进而提升性能。
但是它的功能是非常的简陋的,没有常用的如 JSON 转 Struct 或 JSON 转 map 的操作。如果只是想简单的获取 JSON 中的值,那么使用这个库是非常方便的,但是如果想要把 JSON 值转化成一个结构体就需要自己动手一个个设值了。
GJSON
GJSON 在我的测试中,虽然性能是没有 fastjson 这么极致,但是功能是非常完善,性能也是相当 OK 的,下面先简单介绍一下 GJSON 的功能。
GJSON 的使用是和 fastjson 差不多的,也是非常的简单,只要在参数中传入 json 串以及需要获取的值即可:
|
|
除了这个功能以外还可以进行简单的模糊匹配,支持在键中包含通配符*
和?
,*
匹配任意多个字符,?
匹配单个字符,如下:
|
|
child*.2
:首先child*
匹配children
,.2
读取第 3 个元素;c?ildren.0
:c?ildren
匹配到children
,.0
读取第一个元素;
除了模糊匹配以外还支持修饰符操作:
|
|
children|@reverse
先读取数组children
,然后使用修饰符@reverse
翻转之后返回,输出。
|
|
@flatten
将数组nested
的内层数组平坦到外层后返回:
|
|
等等还有一些其他有意思的功能,大家可以去查阅一下官方文档。
分析
GJSON 的 Get 方法参数是由两部分组成,一个是 JSON 串,另一个叫做 Path 表示需要获取的 JSON 值的匹配路径。
在 GJSON 中因为要满足很多的定义的解析场景,所以解析是分为两部分的,需要先解析好 Path 之后才去遍历解析 JSON 串。
在解析过程中如果遇到可以匹配上的值,那么会直接返回,不需要继续往下遍历,如果是匹配多个值,那么会一直遍历完整个 JSON 串。如果遇到某个 Path 在 JSON 串中匹配不到,那么也是需要遍历完整个 JSON 串。
在解析的过程中也不会像 fastjson 一样将解析的内容保存在一个结构体中,可以反复的利用。所以当调用 GetMany 想要返回多个值的时候,其实也是需要遍历 JSON 串多次,因此效率会比较低。
除此之外,在解析 JSON 的时候并不会对它进行校验,即使这个放入的字符串不是个 JSON 也会照样解析,所以需要用户自己去确保放入的是 JSON 。
代码
|
|
Get 方法里面可以看到有很长一串的代码是用来解析各种 Path,然后一个 for 循环一直遍历 JSON 直到找到 ‘{‘ 或 ‘[‘,然后才进行相应的逻辑进行处理。
|
|
在上面看 parseObject 这段代码的时候其实不是想让大家学习如何解析 JSON,以及遍历字符串,而是想要让大家看看一个 bad case 是怎样的。for 循环一层套一层,if 一个接以一个看得我 San 值狂掉,这片代码大家是不是看起来很眼熟?是不是有点像工作中遇到的某个同事写的代码?
小结
优点:
- 性能相对标准库来说还算不错;
- 可玩性高,可以各种检索、自定义返回值,这点非常方便;
缺点: - 不会校验 JSON 的正确性;
- 代码的 Code smell 很重。
需要注意的是,如果需要解析返回 JSON 的值的话,GetMany 函数会根据指定的 key 值来一次次遍历 JSON 字符串,解析为 map 可以减少遍历次数。
jsonparser
这也是一个比较热门,并且号称高性能,能比标准库快十倍的解析速度。
分析
jsonparser 也是传入一个 JSON 的 byte 切片,以及可以通过传入多个 key 值来快速定位到相应的值,并返回。
和 GJSON 一样,在解析过程中是不会像 fastjson 一样有个数据结构缓存已解析过的 JSON字符串,但是遇到需要解析多个值的情况可以使用 EachKey 函数来解析多个值,只需要遍历一次 JSON字符串即可实现获取多个值的操作。
如果遇到可以匹配上的值,那么会直接返回,不需要继续往下遍历,如果是匹配多个值,那么会一直遍历完整个 JSON 串。如果遇到某个 Path 在 JSON 串中匹配不到,那么也是需要遍历完整个 JSON 串。
并且在遍历 JSON 串的时候通过循环的方式来减少递归的使用,减少了调用栈的深度,一定程度上也是可以提升性能。
在功能性上 ArrayEach、ObjectEach、EachKey 等三个函数都可以传入一个自定义的函数,通过函数来实现个性化的需求,使得实用性大大增强。
对于 jsonparser 来说,代码没什么可分析的,非常的清晰,感兴趣的可以自己去看看。
小结
对于 jsonparser 来说相对标准库比较而言性能如此高的原因可以总结为:
- 使用 for 循环来减少递归的使用;
- 相比标准库而言没有使用反射;
- 在查找相应的 key 值找到了便直接退出,可以不用继续往下递归;
- 所操作的 JSON 串都是已被传入的,不会去重新再去申请新的空间,减少了内存分配;
除此之外在 api 的设计上也是非常的实用,ArrayEach、ObjectEach、EachKey 等三个函数都可以传入一个自定义的函数在实际的业务开发中解决了不少问题。
缺点也是非常的明显,不能对 JSON 进行校验,即使这个 传入的不是 JSON。
性能对比
解析小 JSON 字符串
解析一个结构简单,大小约 190 bytes 的字符串
库名 | 操作 | 每次迭代耗时 | 占用内存数 | 分配内存次数 | 性能 |
---|---|---|---|---|---|
标准库 | 解析为map | 724 ns/op | 976 B/op | 51 allocs/op | 慢 |
解析为struct | 297 ns/op | 256 B/op | 5 allocs/op | 一般 | |
fastjson | get | 68.2 ns/op | 0 B/op | 0 allocs/op | 最快 |
parse | 35.1 ns/op | 0 B/op | 0 allocs/op | 最快 | |
GJSON | 转map | 255 ns/op | 1009 B/op | 11 allocs/op | 一般 |
get | 232 ns/op | 448 B/op | 1 allocs/op | 一般 | |
jsonparser | get | 106 ns/op | 232 B/op | 3 allocs/op | 快 |
解析中等大小 JSON 字符串
解析一个具有一定复杂度,大小约 2.3KB 的字符串
库名 | 操作 | 每次迭代耗时 | 占用内存数 | 分配内存次数 | 性能 |
---|---|---|---|---|---|
标准库 | 解析为map | 4263 ns/op | 10212 B/op | 208 allocs/op | 慢 |
解析为struct | 4789 ns/op | 9206 B/op | 259 allocs/op | 慢 | |
fastjson | get | 285 ns/op | 0 B/op | 0 allocs/op | 最快 |
parse | 302 ns/op | 0 B/op | 0 allocs/op | 最快 | |
GJSON | 转map | 2571 ns/op | 8539 B/op | 83 allocs/op | 一般 |
get | 1489 ns/op | 448 B/op | 1 allocs/op | 一般 | |
jsonparser | get | 878 ns/op | 2728 B/op | 5 allocs/op | 快 |
解析大 JSON 字符串
解析复杂度比较高,大小约 2.2MB 的字符串
库名 | 操作 | 每次迭代耗时 | 占用内存数 | 分配内存次数 | 性能 |
---|---|---|---|---|---|
标准库 | 解析为map | 2292959 ns/op | 5214009 B/op | 95402 allocs/op | 慢 |
解析为struct | 1165490 ns/op | 2023 B/op | 76 allocs/op | 一般 | |
fastjson | get | 368056 ns/op | 0 B/op | 0 allocs/op | 快 |
parse | 371397 ns/op | 0 B/op | 0 allocs/op | 快 | |
GJSON | 转map | 1901727 ns/op | 4788894 B/op | 54372 allocs/op | 一般 |
get | 1322167 ns/op | 448 B/op | 1 allocs/op | 一般 | |
jsonparser | get | 233090 ns/op | 1788865 B/op | 376 allocs/op | 最快 |
总结
在这次的分享过程中,我找了很多 JSON 的解析库分别进行对比分析,可以发现这些高性能的解析库基本上都有一些共同的特点:
- 不使用反射;
- 通过遍历 JSON 字符串的字节来挨个解析;
- 尽量使用传入的 JSON 字符串来进行解析遍历,减少内存分配;
- 牺牲了一定的兼容性;
尽管如此,但是功能上,每个都有一定的特色 fastjson 的 api 操作最简单;GJSON 提供了模糊查找的功能,自定义程度最高;jsonparser 在实现高性能的解析过程中,还可以插入回调函数执行,提供了一定程度上的便利。
综上,回到文章的开头中,对于我自己的业务来说,业务也只是简单的解析 http 请求返回的 JSON 串的部分字段,并且字段都是确定的,无需搜索功能,但是有时候需要做一些自定义的操作,所以对我来说 jsonparser 是最合适的。
所以如果各位对性能有一定要求,不妨结合自己的业务情况来挑选一款 JSON 解析器。
Reference
https://github.com/buger/jsonparser
https://github.com/tidwall/gjson
https://github.com/valyala/fastjson
https://github.com/json-iterator/go
https://github.com/mailru/easyjson
https://github.com/Jeffail/gabs
https://github.com/bitly/go-simplejson