golang什麼時候應該把方法繫結在struct的值上而不是指標上？

TaoWen發表於2019-02-16
GolangStruct指標

golang 支援 struct 也支援 struct 的指標。一個常見的困惑是既然struct 指標存在了，為什麼不乾脆只有struct的指標呢？兩個原因：

  • struct不可空，而struct指標可以為nil

  • []my_struct的記憶體是連續的，而[]*my_struct只有指標是連續存放的，而實際的內容則需要跟隨指標去讀取

同時struct應該也有助於escape analysis，使得物件可以分配在棧上，而不用去進行多執行緒爭搶的分配堆上的記憶體。但是這只是一個猜想。

一個更有趣的問題是，什麼時候方法應該繫結在struct上，而不是struct指標上？考慮以下測試程式

type MyStruct struct {
    field int
}
local_variable := MyStruct{1}
fmt.Println(unsafe.Pointer(&local_variable))
local_variable.modify_struct_value()
fmt.Println(local_variable) // {1}
copied := local_variable.copy_my_self()
fmt.Println(unsafe.Pointer(&copied))
func (self MyStruct) modify_struct_value() {
    fmt.Println(unsafe.Pointer(&self))
    self.field = 2
}
func (self MyStruct) copy_my_self() MyStruct {
    fmt.Println(unsafe.Pointer(&self))
    return self
}

執行的輸出是

0xc82000a2c8
0xc82000a2e0
{1}
0xc82002a028
0xc82000a2f0

這個證明了幾個事情

  • 在方法執行之前struct就被拷貝了一份

  • 對這份拷貝的修改，不會影響原struct（廢話）

  • 如果返回這份拷貝給呼叫方，呼叫方在儲存在區域性變數的時候還會再拷貝一遍（沒有return value optimization）

根據這樣的行為，除非我們想讓一個方法是類似c++的const的行為（以記憶體拷貝為代價），其他的場景下基本沒有理由把行為繫結在struct上而不是繫結在struct指標上。

結論：

  • struct因為可以控制記憶體layout，有其存在意義。效能不敏感的場景，一直使用struct指標也無需有負罪感。

  • 總是把方法繫結在struct指標上，而不要繫結在struct上，以避免不必要的記憶體拷貝

相關文章