我注意到，當(dāng)我在 Go HTTP 服務(wù)器的上下文中計(jì)時(shí) JSON 解組時(shí)，即使對于小對象也需要 30,000+ 納秒。這對我來說似乎很大，所以我運(yùn)行了一些獨(dú)立的基準(zhǔn)測試，結(jié)果令人驚訝地顯示每次解組的平均時(shí)間約為 500 納米。為了更深入地研究這個(gè)問題，我編寫了一個(gè)程序，它只對同一個(gè)小對象執(zhí)行一系列解組，這表明第一個(gè)解組很慢，而后續(xù)的要快得多：package mainimport (    "time"    "fmt"    "encoding/json")var b []bytetype Dog struct {    Age int `json:"Age"`}func unmarshalDog() {    dogCopy := Dog{}    start := time.Now().UnixNano()    json.Unmarshal(b, &dogCopy)    end := time.Now().UnixNano()    fmt.Printf("Time to marshal/unmarshal: %d\n", end-start)}func main() {    // Marshal an object into a byte array which we will repeatedly unmarshal from    d := Dog {        Age: 5,    }    var err error    b, err = json.Marshal(d)    if err != nil {        panic(err)    }    for i := 0; i < 20; i++ {        unmarshalDog()    }    // Allow the goroutines to finish before terminating execution.    time.Sleep(3 * time.Second)}輸出：$ go run testJSONPerformance.goTime to marshal/unmarshal: 34127Time to marshal/unmarshal: 1465Time to marshal/unmarshal: 979Time to marshal/unmarshal: 892Time to marshal/unmarshal: 849Time to marshal/unmarshal: 814Time to marshal/unmarshal: 822Time to marshal/unmarshal: 822Time to marshal/unmarshal: 815Time to marshal/unmarshal: 829Time to marshal/unmarshal: 822Time to marshal/unmarshal: 819unmarshalDog()更有趣的是，當(dāng)我運(yùn)行同一個(gè)程序但在一個(gè)單獨(dú)的 goroutine 中運(yùn)行每次調(diào)用viago unmarshalDog()時(shí)，預(yù)熱現(xiàn)象消失并且平均解組時(shí)間長得多：Time to marshal/unmarshal: 36540Time to marshal/unmarshal: 4652Time to marshal/unmarshal: 56959Time to marshal/unmarshal: 3887Time to marshal/unmarshal: 57068Time to marshal/unmarshal: 3519Time to marshal/unmarshal: 37160我還嘗試了一個(gè)版本，而不是解組相同的字節(jié)數(shù)組，我每次都編組和解組一個(gè)不同的對象（以防某種運(yùn)行時(shí)緩存正在進(jìn)行）。在這種情況下，結(jié)果是一樣的。我非常想知道這種明顯的“熱身”是怎么回事。在 HTTP 服務(wù)器的上下文中，每個(gè)請求都會(huì)得到一個(gè)不同的 goroutine，因此每個(gè)解組平均來說都非常慢。這似乎不是最理想的，因?yàn)轱@然 Go 有可能在特定上下文中用 1/50 的時(shí)間進(jìn)行解組。所有直覺贊賞！