使用 JSON.unmarshal 和 JSON.newdecoder.decode 在 Golang 解码 JSON

I'm developing an API client where I need to encode a JSON payload on request and decode a JSON body from the response.

I've read the source code from several libraries and from what I have seen, I have basically two possibilities for encoding and decoding a JSON string.

Use json.Unmarshal passing the entire response string

data, err := ioutil.ReadAll(resp.Body)
if err == nil && data != nil {
    err = json.Unmarshal(data, value)
}

or using json.NewDecoder.Decode

err = json.NewDecoder(resp.Body).Decode(value)

In my case, when dealing with HTTP responses that implements io.Reader, the second version seems to be require less code, but since I've seen both I wonder if there is any preference whether I should use a solution rather than the other.

Moreover, the accepted answer from this question says

Please use json.Decoder instead of json.Unmarshal.

but it didn't mention the reason. Should I really avoid using json.Unmarshal?

转载于:https://stackoverflow.com/questions/21197239/decoding-json-in-golang-using-json-unmarshal-vs-json-newdecoder-decode

csdnceshi69
YaoRaoLov You can use io.LimitReader to prevent that.
2 年多之前 回复
csdnceshi50
三生石@ IMO, ioutil.ReadAll is almost always the wrong thing to do. It's not related to your goal, but requires you to have enough contiguous memory to store whatever might be coming down the pipe, even if the last 20TB of response is after the last } in your JSON.
6 年多之前 回复
csdnceshi65
larry*wei It just depends on what input is more convenient for you to use. blog.golang.org/json-and-go gives examples of using both techniques.
6 年多之前 回复
csdnceshi51
旧行李 This pull request on GitHub replaced a call to Unmarshal with json.NewDecoder to "remove buffer in JSON decoding."
6 年多之前 回复

2个回答

It really depends on what your input is. If you look at the implementation of the Decode method of json.Decoder, it buffers the entire JSON value in memory before unmarshalling it into a Go value. So in most cases it won't be any more memory efficient (although this could easily change in a future version of the language).

So a better rule of thumb is this:

  • Use json.Decoder if your data is coming from an io.Reader stream, or you need to decode multiple values from a stream of data.
  • Use json.Unmarshal if you already have the JSON data in memory.

For the case of reading from an HTTP request, I'd pick json.Decoder since you're obviously reading from a stream.

csdnceshi62
csdnceshi62 No, you're probably right. I was just interpreting your statement differently than you intended. Apologies for the confusion.
3 年多之前 回复
weixin_41568196
撒拉嘿哟木头 are you sure? The source code still says it reads the entire value into the buffer before decoding: github.com/golang/go/blob/master/src/encoding/json/…. The Buffered method is there to let you see any extra data that was read into the internal buffer after the value.
3 年多之前 回复
weixin_41568110
七度&光 Also: by inspecting the Go 1.3 source code, we can also learn that for encoding, if you use a json.Encoder, it will reuse a global buffer pool (backed by the new sync.Pool), which should decrease buffer churn a lot if you're encoding a lot of json. There's only one global pool so different json.Encoder's share it. The reason this couldn't be done for the json.Marshal interface is because the bytes are returned to the user and the user doesn't have a way to "return" the bytes to the pool. So if you're doing a lot of encoding, json.Marshal always has quite a bit buffer churn.
6 年多之前 回复

We must get []byte from the pipe before decode, so read from io is necessary when deal with HTTP connections, so i think the two function is equal. But when the data has save in memory, or we have get the []byte, we can use Unmarshal directly, it is better.

The json.Decoder is used when reading and writing to HTTP connections, WebSockets, or files.

The json.Unmarshal is used when the input is []byte

Csdn user default icon
上传中...
上传图片
插入图片
抄袭、复制答案,以达到刷声望分或其他目的的行为,在CSDN问答是严格禁止的,一经发现立刻封号。是时候展现真正的技术了!
立即提问
相关内容推荐