golang json性能分析詳解

前言

眾所周知Json 作為一種重要的數(shù)據(jù)格式，具有良好的可讀性以及自描述性，廣泛地應(yīng)用在各種數(shù)據(jù)傳輸場(chǎng)景中。Go 語(yǔ)言里面原生支持了這種數(shù)據(jù)格式的序列化以及反序列化，內(nèi)部使用反射機(jī)制實(shí)現(xiàn)，性能有點(diǎn)差，在高度依賴 json 解析的應(yīng)用里，往往會(huì)成為性能瓶頸，好在已有很多第三方庫(kù)幫我們解決了這個(gè)問(wèn)題，但是這么多庫(kù)，對(duì)于像我這種有選擇困難癥的人來(lái)說(shuō)，到底要怎么選擇呢，下面就給大家來(lái)一一分析一下

ffjson

go get -u github.com/pquerna/ffjson

原生的庫(kù)性能比較差的主要原因是使用了很多反射的機(jī)制，為了解決這個(gè)問(wèn)題，ffjson 通過(guò)預(yù)編譯生成代碼，類(lèi)型的判斷在預(yù)編譯階段已經(jīng)確定，避免了在運(yùn)行時(shí)的反射

但也因此在編譯前需要多一個(gè)步驟，需要先生成 ffjson 代碼，生成代碼只需要執(zhí)行 ffjson file.go> 就可以了，其中 file.go 是一個(gè)包含 json 結(jié)構(gòu)體定義的 go 文件。注意這里 ffjson 是這個(gè)庫(kù)提供的一個(gè)代碼生成工具，直接執(zhí)行上面的 go get 會(huì)把這個(gè)工具安裝在 $GOPATH/bin 目錄下，把 $GOPATH/bin 加到 $PATH 環(huán)境變量里面，可以全局訪問(wèn)

另外，如果有些結(jié)構(gòu)，不想讓 ffjson 生成代碼，可以通過(guò)增加注釋的方式

// ffjson: skip
type Foo struct {
 Bar string
}
// ffjson: nodecoder
type Foo struct {
 Bar string
}

easyjson

go get -u github.com/mailru/easyjson/...

easyjson 的思想和 ffjson 是一致的，都是增加一個(gè)預(yù)編譯的過(guò)程，預(yù)先生成對(duì)應(yīng)結(jié)構(gòu)的序列化反序列化代碼，除此之外，easyjson 還放棄了一些原生庫(kù)里面支持的一些不必要的特性，比如：key 類(lèi)型聲明，key 大小寫(xiě)不敏感等等，以達(dá)到更高的性能

生成代碼執(zhí)行 easyjson -all file.go> 即可，如果不指定 -all 參數(shù)，只會(huì)對(duì)帶有 //easyjson:json 的結(jié)構(gòu)生成代碼

//easyjson:json
type A struct {
 Bar string
}

jsoniter

go get -u github.com/json-iterator/go

這是一個(gè)很神奇的庫(kù)，滴滴開(kāi)發(fā)的，不像 easyjson 和 ffjson 都使用了預(yù)編譯，而且 100% 兼容原生庫(kù)，但是性能超級(jí)好，也不知道怎么實(shí)現(xiàn)的，如果有人知道的話，可以告訴我一下嗎？

2018-1-28日更新，來(lái)自官方（@taowen）的回復(fù)：

沒(méi)啥神奇的。就是預(yù)先緩存了對(duì)應(yīng)struct的decoder實(shí)例而已。然后unsafe.Pointer省掉了一些interface{}的開(kāi)銷(xiāo)。還有一些文本解析上的優(yōu)化

使用上面，你只要把所有的

import "encoding/json"

替換成

import "github.com/json-iterator/go"
var json = jsoniter.ConfigCompatibleWithStandardLibrary

就可以了，其它都不需要?jiǎng)?/p>

codec-json

go get -u github.com/ugorji/go/codec

這個(gè)庫(kù)里面其實(shí)包含很多內(nèi)容，json 只是其中的一個(gè)功能，比較老，使用起來(lái)比較麻煩，性能也不是很好

jsonparser

go get -u github.com/buger/jsonparser

嚴(yán)格來(lái)說(shuō)，這個(gè)庫(kù)不屬于 json 序列化的庫(kù)，只是提供了一些 json 解析的接口，使用的時(shí)候需要自己去設(shè)置結(jié)構(gòu)里面的值，事實(shí)上，每次調(diào)用都需要重新解析 json 對(duì)象，性能并不是很好

就像名字暗示的那樣，這個(gè)庫(kù)只是一個(gè)解析庫(kù)，并沒(méi)有序列化的接口

性能測(cè)試

對(duì)上面這些 json 庫(kù)，作了一些性能測(cè)試，測(cè)試代碼在：https://github.com/hatlonely/hellogolang/blob/master/internal/json/json_benchmark_test.go，下面是在我的 Macbook 上測(cè)試的結(jié)果（實(shí)際結(jié)果和庫(kù)的版本以及機(jī)器環(huán)境有關(guān)，建議自己再測(cè)試一遍）：

BenchmarkMarshalStdJson-4     1000000   1097 ns/op
BenchmarkMarshalJsonIterator-4    2000000   781 ns/op
BenchmarkMarshalFfjson-4      2000000   941 ns/op
BenchmarkMarshalEasyjson-4     3000000   513 ns/op
BenchmarkMarshalCodecJson-4     1000000   1074 ns/op
BenchmarkMarshalCodecJsonWithBufio-4   1000000   2161 ns/op
BenchmarkUnMarshalStdJson-4     500000   2512 ns/op
BenchmarkUnMarshalJsonIterator-4    2000000   591 ns/op
BenchmarkUnMarshalFfjson-4     1000000   1127 ns/op
BenchmarkUnMarshalEasyjson-4     2000000   608 ns/op
BenchmarkUnMarshalCodecJson-4     20000  122694 ns/op
BenchmarkUnMarshalCodecJsonWithBufio-4  500000   3417 ns/op
BenchmarkUnMarshalJsonparser-4    2000000   877 ns/op
golang_json_performance

從上面的結(jié)果可以看出來(lái)：

• easyjson 無(wú)論是序列化還是反序列化都是最優(yōu)的，序列化提升了1倍，反序列化提升了3倍
• jsoniter 性能也很好，接近于easyjson，關(guān)鍵是沒(méi)有預(yù)編譯過(guò)程，100%兼容原生庫(kù)
• ffjson 的序列化提升并不明顯，反序列化提升了1倍
• codecjson 和原生庫(kù)相比，差不太多，甚至更差
• jsonparser 不太適合這樣的場(chǎng)景，性能提升并不明顯，而且沒(méi)有反序列化

所以綜合考慮，建議大家使用 jsoniter，如果追求極致的性能，考慮 easyjson

參考鏈接

• ffjson: https://github.com/pquerna/ffjson
• easyjson: https://github.com/mailru/easyjson
• jsoniter: https://github.com/json-iterator/go
• jsonparser: https://github.com/buger/jsonparser
• codecjson: http://ugorji.net/blog/go-codec-primer

總結(jié)

以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，如果有疑問(wèn)大家可以留言交流，謝謝大家對(duì)腳本之家的支持。