起源

就在今年9月份，我負責的部門平臺項目發(fā)布了一個新版本，該版本同時上線了一個新功能，簡單說有點類似定時任務。頭一天一切正常，但第二天出現(xiàn)了極少數(shù)任務沒有正常執(zhí)行（已經暫停的任務繼續(xù)執(zhí)行，正常的任務反而沒有執(zhí)行）的情況。

問題的現(xiàn)象讓我和另一個同事的第一反應是定時任務執(zhí)行的邏輯出現(xiàn)了問題。但在我們耗費了大量的時間去DEBUG、測試后，發(fā)現(xiàn)問題的根本并不在功能邏輯，而是一段已經上線了一年并且沒有動過的底層公共代碼。這段代碼的核心就是本篇文章的主人公gob，引發(fā)問題的根源則是go語言的一個特性：零值。

后文中我會用一個更簡化的例子描述這個 BUG。

1 gob 與零值

先簡單介紹一下gob和零值。

1.1 零值

零值是 Go 語言中的一個特性，簡單說就是：Go 語言會給一些沒有被賦值的變量提供一個默認值。譬如下面這段代碼：

package main
import (
    "fmt"
)
type person struct {
    name   string
    gender int
    age    int
}
func main() {
    p := person{}
    var list []byte
    var f float32
    var s string
    var m map[string]int
    fmt.Println(list, f, s, m)
    fmt.Printf("%+v", p)
}
/* 結果輸出
[] 0  map[]
{name: gender:0 age:0}
*/

零值在很多時候確實為開發(fā)者帶來了方便，但也有許多不喜歡它的人認為零值的存在使得代碼從語法層面上不嚴謹，帶來了一些不確定性。譬如我即將在后文中詳細描述的問題。

1.2 gob

gob是 Go 語言自帶的標準庫，在encoding/gob中。gob其實是go binary的簡寫，因此從它的名稱我們也可以猜到，gob應當與二進制相關。

實際上gob是 Go 語言獨有的以二進制形式序列化和反序列化程序數(shù)據(jù)的格式，類似 Python 中的 pickle。它最常見的用法是將一個對象（結構體）序列化后存儲到磁盤文件，在需要使用的時候再讀取文件并反序列化出來，從而達到對象持久化的效果。

例子我就不舉了，本篇也不是gob的使用專題。這是它的**官方文檔**，對gob用法不熟悉的朋友們可以看一下文檔中的Example部分，或者直接看我后文中描述問題用到的例子。

2 問題

2.1 需求

在本文的開頭，我簡單敘述了問題的起源，這里我用一個更簡單的模型來展開描述。

首先我們定義一個名為person的結構體：

type person struct {
    // 和 json 庫一樣，字段首字母必須大寫（公有）才能序列化
    ID     int
    Name   string // 姓名
    Gender int    // 性別：男 1，女 0
    Age    int    // 年齡
}

圍繞這個結構體，我們會錄入若干個人員信息，每一個人員都是一個person對象。但出于一些原因，我們必須使用gob將這些人員信息持久化到本地磁盤，而不是使用 MySQL 之類的數(shù)據(jù)庫。

接著，我們有這樣一個需求：

遍歷并反序列化本地存儲的gob文件，然后判斷男女性別的數(shù)量，并統(tǒng)計。

2.2 代碼

根據(jù)上面的需求和背景，代碼如下（為了節(jié)省篇幅，這里省略了 package, import, init() 等代碼）：

• defines.go

// .gob 文件所在目錄
const DIR = "./persons"
type person struct {
    // 和 json 庫一樣，字段首字母必須大寫（公有）才能序列化
    ID     int
    Name   string // 姓名
    Gender int    // 性別：男 1，女 0
    Age    int    // 年齡
}
// 需要持久化的對象們
var persons = []person{
    {0, "Mia", 0, 21},
    {1, "Jim", 1, 18},
    {2, "Bob", 1, 25},
    {3, "Jenny", 0, 16},
    {4, "Marry", 0, 30},
}

• serializer.go

// serialize 將 person 對象序列化后存儲到文件，
// 文件名為 ./persons/${p.id}.gob
func serialize(p person) {
    filename := filepath.Join(DIR, fmt.Sprintf("%d.gob", p.ID))
    buffer := new(bytes.Buffer)
    encoder := gob.NewEncoder(buffer)
    _ = encoder.Encode(p)
    _ = ioutil.WriteFile(filename, buffer.Bytes(), 0644)
}
// unserialize 將 .gob 文件反序列化后存入指針參數(shù)
func unserialize(path string, p *person) {
    raw, _ := ioutil.ReadFile(path)
    buffer := bytes.NewBuffer(raw)
    decoder := gob.NewDecoder(buffer)
    _ = decoder.Decode(p)
}

• main.go

func main() {
    storePersons()
    countGender()
}
func storePersons() {
    for _, p := range persons {
        serialize(p)
    }
}
func countGender() {
    counter := make(map[int]int)
    // 用一個臨時指針去作為文件中對象的載體，以節(jié)省新建對象的開銷。
    tmpP := &person{}
    for _, p := range persons {
        // 方便起見，這里直接遍歷 persons ，但只取 ID 用于讀文件
        id := p.ID
        filename := filepath.Join(DIR, fmt.Sprintf("%d.gob", id))
        // 反序列化對象到 tmpP 中
        unserialize(filename, tmpP)
        // 統(tǒng)計性別
        counter[tmpP.Gender]++
    }
    fmt.Printf("Female: %+v, Male: %+v\n", counter[0], counter[1])
}

執(zhí)行代碼后，我們得到了這樣的結果：

// 對象們
var persons = []person{
    {0, "Mia", 0, 21},
    {1, "Jim", 1, 18},
    {2, "Bob", 1, 25},
    {3, "Jenny", 0, 16},
    {4, "Marry", 0, 30},
}
// 結果輸出
Female: 1, Male: 4

嗯？1 個女性，4 個男性？BUG出現(xiàn)了，這樣的結果顯然與我們的預設數(shù)據(jù)不符。是哪里出了問題？

2.3 定位

我們在countGender()函數(shù)中的for循環(huán)里添加一行打印語句，將每次讀取到的person對象讀出來，然后得到了這樣的結果：

// 添加行
fmt.Printf("%+v\n", tmpP)
// 結果輸出
&{ID:0 Name:Mia Gender:0 Age:21}
&{ID:1 Name:Jim Gender:1 Age:18}
&{ID:2 Name:Bob Gender:1 Age:25}
&{ID:3 Name:Jenny Gender:1 Age:16}
&{ID:4 Name:Marry Gender:1 Age:30}

好家伙，Jenny 和 Marry 都給變成男人了！但神奇的是，除了 Gender 這一項外，其他所有的數(shù)據(jù)都正常！看到這一結果，如果大家和我一樣，平時經常和 JSON、Yml 之類的配置文件打交道，很可能會想當然地認為：上面的 gob 文件讀取正常，應當是存儲出了問題。

但gob文件是二進制文件，我們難以像 JSON 文件那樣用肉眼去驗證。即便在 Linux 下使用xxd之類的工具，也只能得到這樣一種模棱兩可的輸出：

>$ xxd persons/1.gob 
0000000: 37ff 8103 0101 0670 6572 736f 6e01 ff82  7......person...
0000010: 0001 0401 0249 4401 0400 0104 4e61 6d65  .....ID.....Name
0000020: 010c 0001 0647 656e 6465 7201 0400 0103  .....Gender.....
0000030: 4167 6501 0400 0000 0eff 8201 0201 034a  Age............J
0000040: 696d 0102 0124 00                        im...$.
>$ xxd persons/0.gob 
0000000: 37ff 8103 0101 0670 6572 736f 6e01 ff82  7......person...
0000010: 0001 0401 0249 4401 0400 0104 4e61 6d65  .....ID.....Name
0000020: 010c 0001 0647 656e 6465 7201 0400 0103  .....Gender.....
0000030: 4167 6501 0400 0000 0aff 8202 034d 6961  Age..........Mia
0000040: 022a 00                                  .*.

也許我們可以嘗試去硬解析這幾個二進制文件，來對比它們之間的差異；或者反序列化兩個除了 Gender 外一模一樣的對象到gob文件中，然后對比。大家如果有興趣的話可以嘗試一下。當時的我們因為時間緊迫等原因，沒有嘗試這種做法，而是修改數(shù)據(jù)繼續(xù)測試。

2.4 規(guī)律

由于上文中出問題的兩個數(shù)據(jù)都是女性，程序員的直覺告訴我這也許并不是巧合。于是我嘗試修改數(shù)據(jù)的順序，將男女完全分開，然后進行測試：

// 第一組，先女后男
var persons = []person{
    {0, "Mia", 0, 21},
    {3, "Jenny", 0, 16},
    {4, "Marry", 0, 30},
    {1, "Jim", 1, 18},
    {2, "Bob", 1, 25},
}
// 結果輸出
&{ID:0 Name:Mia Gender:0 Age:21}
&{ID:3 Name:Jenny Gender:0 Age:16}
&{ID:4 Name:Marry Gender:0 Age:30}
&{ID:1 Name:Jim Gender:1 Age:18}
&{ID:2 Name:Bob Gender:1 Age:25}

// 第二組，先男后女
var persons = []person{
    {1, "Jim", 1, 18},
    {2, "Bob", 1, 25},
    {0, "Mia", 0, 21},
    {3, "Jenny", 0, 16},
    {4, "Marry", 0, 30},
}
// 結果輸出
&{ID:1 Name:Jim Gender:1 Age:18}
&{ID:2 Name:Bob Gender:1 Age:25}
&{ID:2 Name:Mia Gender:1 Age:21}
&{ID:3 Name:Jenny Gender:1 Age:16}
&{ID:4 Name:Marry Gender:1 Age:30}

吊詭的現(xiàn)象出現(xiàn)了，先女后男時，結果一切正常；先男后女時，男性正常，女性全都不正常，甚至 Mia 原本為 0 的 ID 這里也變成了 2！

經過反復地測試和對結果集的觀察，我們得到了這樣一個有規(guī)律的結論：所有男性數(shù)據(jù)都正常，出問題的全是女性數(shù)據(jù)！

進一步公式化描述這個結論就是：如果前面的數(shù)據(jù)為非 0 數(shù)字，同時后面的數(shù)據(jù)數(shù)字為 0 時，則后面的 0 會被它前面的非 0 所覆蓋。

3 答案

再次審計程序代碼，我注意到了這一句：

// 用一個臨時指針去作為文件中對象的載體，以節(jié)省新建對象的開銷。
tmpP := &person{}

為了節(jié)省額外的新建對象的開銷，我用了同一個變量來循環(huán)加載文件中的數(shù)據(jù)，并進行性別判定。結合前面我們發(fā)現(xiàn)的 BUG 規(guī)律，答案似乎近在眼前了：所謂后面的數(shù)據(jù) 0 被前面的非 0 覆蓋，很可能是因為使用了同一個對象加載文件，導致前面的數(shù)據(jù)殘留。

驗證的方法也很簡單，只需要將那個公共對象放到下面的for循環(huán)里，使每一次循環(huán)都重新創(chuàng)建一個對象用于加載文件數(shù)據(jù)，以切斷上一個數(shù)據(jù)的影響。

我們修改一下代碼（省略了多余部分）：

for _, p := range persons {
    // ...
    tmpP := &person{}
    // ...
}
// 結果輸出
&{ID:0 Name:Mia Gender:0 Age:21}
&{ID:1 Name:Jim Gender:1 Age:18}
&{ID:2 Name:Bob Gender:1 Age:25}
&{ID:3 Name:Jenny Gender:0 Age:16}
&{ID:4 Name:Marry Gender:0 Age:30}
Female: 3, Male: 2

對了！

結果確實如我們推想，是數(shù)據(jù)殘留的原因。但這里又有一個問題了：為什么先 0 后非 0 （先女后男）的情況下，老方法讀取的數(shù)據(jù)又一切正常呢？以及，除了 0 會被影響外，其他的數(shù)字（年齡）又都不會被影響？

所有的問題現(xiàn)在似乎都在指向 0 這個特殊數(shù)字！

直到此時，零值這個特性才終于被我們察覺。于是我趕緊閱讀了gob庫的**官方文檔**，發(fā)現(xiàn)了這么一句話：

If a field has the zero value for its type (except for arrays; see above), it is omitted from the transmission.

翻譯一下：

如果一個字段的類型擁有零值（數(shù)組除外），它會在傳輸中被省略。

這句話的前后文是在說struct，因此這里的field指的也是結構體中的字段，符合我們文中的例子。

根據(jù)我們前面得到的結論，以及官方文檔的說明，我們現(xiàn)在終于可以得出一個完整的結論了：

gob庫在操作數(shù)據(jù)時，會忽略數(shù)組之外的零值。而我們的代碼一開始使用一個公共對象來加載文件數(shù)據(jù)，由于零值不被傳輸，因此原數(shù)據(jù)中為零值的字段就不會讀到，我們看到的實際上是上一個非零值的對象數(shù)據(jù)。

解決方法也很簡單，就是我上面做的，不要使用公共對象去加載就好了。

4 回顧

文章開頭我敘述的項目 BUG 里，我使用了 0 和 1 來表示一個定時任務的狀態(tài)（暫停、運行）。就像上面 person.Gender 一樣，不同任務之間因為零值問題受到了干擾，從而造成了任務執(zhí)行異常，而不涉及零值的其他字段則一切正常。盡管是線上生產環(huán)境，但所幸問題發(fā)現(xiàn)的早，處理的及時，并沒有造成任何生產事故。但整個過程和最終的答案卻深深印在了我的腦海里。

后來我和我同事簡單討論過，為什么gob選擇忽略零值？以我的角度來看，可能是為了節(jié)省空間。而我們一開始編寫的代碼，也是為了節(jié)省空間而創(chuàng)建了一個公共對象，結果兩個節(jié)省空間的邏輯最終碰撞出了一個隱蔽的 BUG。

以上就是Golang中由零值和gob庫特性引起B(yǎng)UG解析的詳細內容，更多關于Golang零值gob庫引起B(yǎng)UG的資料請關注腳本之家其它相關文章！

最新評論