golang interface 介面介紹

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

[TOC]

golang interface 介面介紹

interface 介紹

如果說goroutine和channel是Go並發的兩大基石，那麼介面是Go語言編程中資料類型的關鍵。在Go語言的實際編程中，幾乎所有的資料結構都圍繞介面展開，介面是Go語言中所有資料結構的核心。

Go不是一種典型的OO語言，它在文法上不支援類和繼承的概念。

沒有繼承是否就無法擁有多態行為了呢？答案是否定的，Go語言引入了一種新類型—Interface，它在效果上實現了類似於C++的“多態”概念，雖然與C++的多態在文法上並非完全對等，但至少在最終實現的效果上，它有多態的影子。

雖然Go語言沒有類的概念，但它支援的資料類型可以定義對應的method(s)。本質上說，所謂的method(s)其實就是函數，只不過與普通函數相比，這類函數是作用在某個資料類型上的，所以在函數簽名中，會有個receiver(接收器)來表明當前定義的函數會作用在該receiver上。

Go語言支援的除Interface類型外的任何其它資料類型都可以定義其method（而並非只有struct才支援method），只不過實際項目中，method(s)多定義在struct上而已。
從這一點來看，我們可以把Go中的struct看作是不支援繼承行為的輕量級的“類”。

從文法上看，Interface定義了一個或一組method(s)，這些method(s)只有函數簽名，沒有具體的實現代碼（有沒有聯想起C++中的虛函數？）。若某個資料類型實現了Interface中定義的那些被稱為"methods"的函數，則稱這些資料類型實現（implement）了interface。這是我們常用的OO方式，如下是一個簡單的樣本

```type MyInterface interface{    Print()}func TestFunc(x MyInterface) {}type MyStruct struct {}func (me MyStruct) Print() {}func main() {    var me MyStruct    TestFunc(me)}```

Why Interface

為什麼要用介面呢？在Gopher China 上的分享中，有大神給出了下面的理由：

writing generic algorithm （泛型程式設計）
hiding implementation detail （隱藏具體實現）
providing interception points

下面大體再介紹下這三個理由

writing generic algorithm （泛型程式設計）

嚴格來說，在 Golang 中並不支援泛型程式設計。在 C++ 等進階語言中使用泛型程式設計非常的簡單，所以泛型程式設計一直是 Golang 詬病最多的地方。但是使用 interface 我們可以實現泛型程式設計，如下是一個參考樣本

```package sort// A type, typically a collection, that satisfies sort.Interface can be// sorted by the routines in this package.  The methods require that the// elements of the collection be enumerated by an integer index.type Interface interface {    // Len is the number of elements in the collection.    Len() int    // Less reports whether the element with    // index i should sort before the element with index j.    Less(i, j int) bool    // Swap swaps the elements with indexes i and j.    Swap(i, j int)}...// Sort sorts data.// It makes one call to data.Len to determine n, and O(n*log(n)) calls to// data.Less and data.Swap. The sort is not guaranteed to be stable.func Sort(data Interface) {    // Switch to heapsort if depth of 2*ceil(lg(n+1)) is reached.    n := data.Len()    maxDepth := 0    for i := n; i > 0; i >>= 1 {        maxDepth++    }    maxDepth *= 2    quickSort(data, 0, n, maxDepth)}```

Sort 函數的形參是一個 interface，包含了三個方法：Len()，Less(i,j int)，Swap(i, j int)。使用的時候不管數組的元素類型是什麼類型（int, float, string…），只要我們實現了這三個方法就可以使用 Sort 函數，這樣就實現了“泛型程式設計”。

這種方式，我在閃聊項目裡面也有實際應用過，具體案例就是對訊息排序。

下面給一個具體樣本，代碼能夠說明一切，一看就懂：

```type Person struct {Name stringAge  int}func (p Person) String() string {    return fmt.Sprintf("%s: %d", p.Name, p.Age)}// ByAge implements sort.Interface for []Person based on// the Age field.type ByAge []Person //自訂func (a ByAge) Len() int           { return len(a) }func (a ByAge) Swap(i, j int)      { a[i], a[j] = a[j], a[i] }func (a ByAge) Less(i, j int) bool { return a[i].Age < a[j].Age }func main() {    people := []Person{        {"Bob", 31},        {"John", 42},        {"Michael", 17},        {"Jenny", 26},    }    fmt.Println(people)    sort.Sort(ByAge(people))    fmt.Println(people)}```

hiding implementation detail （隱藏具體實現）

隱藏具體實現，這個很好理解。比如我設計一個函數給你返回一個 interface，那麼你只能通過 interface 裡面的方法來做一些操作，但是內部的具體實現是完全不知道的。

例如我們常用的context包，就是這樣的，context 最先由 google 提供，現在已經納入了標準庫，而且在原有 context 的基礎上增加了：cancelCtx，timerCtx，valueCtx。

剛好前面我們有專門說過context，現在再來回顧一下

```func WithCancel(parent Context) (ctx Context, cancel CancelFunc) {    c := newCancelCtx(parent)    propagateCancel(parent, &c)    return &c, func() { c.cancel(true, Canceled) }}```

表明上 WithCancel 函數返回的還是一個 Context interface，但是這個 interface 的具體實現是 cancelCtx struct。

```    // newCancelCtx returns an initialized cancelCtx.    func newCancelCtx(parent Context) cancelCtx {        return cancelCtx{            Context: parent,            done:    make(chan struct{}),        }    }        // A cancelCtx can be canceled. When canceled, it also cancels any children    // that implement canceler.    type cancelCtx struct {        Context     //注意一下這個地方            done chan struct{} // closed by the first cancel call.        mu       sync.Mutex        children map[canceler]struct{} // set to nil by the first cancel call        err      error                 // set to non-nil by the first cancel call    }        func (c *cancelCtx) Done() <-chan struct{} {        return c.done    }        func (c *cancelCtx) Err() error {        c.mu.Lock()        defer c.mu.Unlock()        return c.err    }        func (c *cancelCtx) String() string {        return fmt.Sprintf("%v.WithCancel", c.Context)    }```

儘管內部實現上下面三個函數返回的具體 struct （都實現了 Context interface）不同，但是對於使用者來說是完全無感知的。

```func WithCancel(parent Context) (ctx Context, cancel CancelFunc)    //返回 cancelCtxfunc WithDeadline(parent Context, deadline time.Time) (Context, CancelFunc) //返回 timerCtxfunc WithValue(parent Context, key, val interface{}) Context    //返回 valueCtx```

providing interception points

咱無更多，待補充

interface 源碼分析

說了這麼多， 然後可以再來瞧瞧具體源碼的實現

interface 底層結構

根據 interface 是否包含有 method，底層實現上用兩種 struct 來表示：iface 和 eface。eface表示不含 method 的 interface 結構，或者叫 empty interface。對於 Golang 中的大部分資料類型都可以抽象出來 _type 結構，同時針對不同的類型還會有一些其他資訊。

```type eface struct {    _type *_type    data  unsafe.Pointer}type _type struct {    size       uintptr // type size    ptrdata    uintptr // size of memory prefix holding all pointers    hash       uint32  // hash of type; avoids computation in hash tables    tflag      tflag   // extra type information flags    align      uint8   // alignment of variable with this type    fieldalign uint8   // alignment of struct field with this type    kind       uint8   // enumeration for C    alg        *typeAlg  // algorithm table    gcdata    *byte    // garbage collection data    str       nameOff  // string form    ptrToThis typeOff  // type for pointer to this type, may be zero}```

iface 表示 non-empty interface 的底層實現。相比於 empty interface，non-empty 要包含一些 method。method 的具體實現存放在 itab.fun 變數裡。

```type iface struct {    tab  *itab    data unsafe.Pointer}// layout of Itab known to compilers// allocated in non-garbage-collected memory// Needs to be in sync with// ../cmd/compile/internal/gc/reflect.go:/^func.dumptypestructs.type itab struct {    inter  *interfacetype    _type  *_type    link   *itab    bad    int32    inhash int32      // has this itab been added to hash?    fun    [1]uintptr // variable sized}```

試想一下，如果 interface 包含多個 method，這裡只有一個 fun 變數怎麼存呢？
其實，通過反編譯彙編是可以看出的，中間過程編譯器將根據我們的轉換目標類型的 empty interface 還是 non-empty interface，來對原資料類型進行轉換（轉換成 <_type, unsafe.Pointer> 或者 <itab, unsafe.Pointer>）。這裡對於 struct 滿不滿足 interface 的類型要求（也就是 struct 是否實現了 interface 的所有 method），是由編譯器來檢測的。

iface 之 itab

iface 結構中最重要的是 itab 結構。itab 可以理解為 pair<interface type, concrete type> 。當然 itab 裡面還包含一些其他資訊，比如 interface 裡麵包含的 method 的具體實現。下面細說。itab 的結構如下。

```type itab struct {    inter  *interfacetype    _type  *_type    link   *itab    bad    int32    inhash int32      // has this itab been added to hash?    fun    [1]uintptr // variable sized}```

其中 interfacetype 包含了一些關於 interface 本身的資訊，比如 package path，包含的 method。上面提到的 iface 和 eface 是資料類型（built-in 和 type-define）轉換成 interface 之後的實體的 struct 結構，而這裡的 interfacetype 是我們定義 interface 時候的一種抽象表示。

```type interfacetype struct {    typ     _type    pkgpath name    mhdr    []imethod}type imethod struct {   //這裡的 method 只是一種函式宣告的抽象，比如  func Print() error    name nameOff    ityp typeOff}```

_type 表示 concrete type。fun 表示的 interface 裡面的 method 的具體實現。比如 interface type 包含了 method A, B，則通過 fun 就可以找到這兩個 method 的具體實現。

interface的記憶體布局

瞭解interface的記憶體結構是非常有必要的，只有瞭解了這一點，我們才能進一步分析諸如類型斷言等情況的效率問題。先看一個例子：

```type Stringer interface {    String() string}type Binary uint64func (i Binary) String() string {    return strconv.Uitob64(i.Get(), 2)}func (i Binary) Get() uint64 {    return uint64(i)}func main() {    b := Binary{}    s := Stringer(b)    fmt.Print(s.String())}```

根據上面interface的源碼實現，可以知道，interface在記憶體上實際由兩個成員組成，如，tab指向虛表，data則指向實際引用的資料。虛表描繪了實際的類型資訊及該介面所需要的方法集

![Uploading interface記憶體布局_731644.png]

觀察itable的結構，首先是描述type資訊的一些中繼資料，然後是滿足Stringger介面的函數指標列表（注意，這裡不是實際類型Binary的函數指標集哦）。因此我們如果通過介面進行函數調用，實際的操作其實就是s.tab->fun0。是不是和C++的虛表很像？接下來我們要看看golang的虛表和C++的虛表區別在哪裡。

先看C++，它為每種類型建立了一個方法集，而它的虛表實際上就是這個方法集本身或是它的一部分而已，當面臨多繼承時（或者叫實現多個介面時，這是很常見的），C++對象結構裡就會存在多個虛表指標，每個虛表指標指向該方法集的不同部分，因此，C++方法集裡面函數指標有嚴格的順序。許多C++新手在面對多繼承時就變得蛋疼菊緊了，因為它的這種設計方式，為了保證其虛表能夠正常工作，C++引入了很多概念，什麼虛繼承啊，介面函數同名問題啊，同一個介面在不同的層次上被繼承多次的問題啊等等……就是老手也很容易因疏忽而寫出問題代碼出來。

我們再來看golang的實現方式，同C++一樣，golang也為每種類型建立了一個方法集，不同的是介面的虛表是在運行時專門產生的。可能細心的同學能夠發現為什麼要在運行時產生虛表。因為太多了，每一種介面類型和所有滿足其介面的實體類型的組合就是其可能的虛表數量，實際上其中的大部分是不需要的，因此golang選擇在運行時產生它，例如，當例子中當首次遇見s := Stringer(b)這樣的語句時，golang會產生Stringer介面對應於Binary類型的虛表，並將其緩衝。

理解了golang的記憶體結構，再來分析諸如類型斷言等情況的效率問題就很容易了，當判定一種類型是否滿足某個介面時，golang使用類型的方法集和介面所需要的方法集進行匹配，如果類型的方法集完全包含介面的方法集，則可認為該類型滿足該介面。例如某類型有m個方法，某介面有n個方法，則很容易知道這種判定的時間複雜度為O(mXn)，不過可以使用預先排序的方式進行最佳化，實際的時間複雜度為O(m+n)。

interface 與 nil 的比較

引用公司內部同事的討論議題，覺得之前自己也沒有理解明白，為此，單獨羅列出來，例子是最好的說明，如下

package mainimport (    "fmt"    "reflect")type State struct{}func testnil1(a, b interface{}) bool {    return a == b}func testnil2(a *State, b interface{}) bool {    return a == b}func testnil3(a interface{}) bool {    return a == nil}func testnil4(a *State) bool {    return a == nil}func testnil5(a interface{}) bool {    v := reflect.ValueOf(a)    return !v.IsValid() || v.IsNil()}func main() {    var a *State    fmt.Println(testnil1(a, nil))    fmt.Println(testnil2(a, nil))    fmt.Println(testnil3(a))    fmt.Println(testnil4(a))    fmt.Println(testnil5(a))}

返回結果如下

falsefalsefalsetruetrue

為啥呢？

一個interface{}類型的變數包含了2個指標，一個指標指向值的類型，另外一個指標指向實際的值
對一個interface{}類型的nil變數來說，它的兩個指標都是0；但是var a *State傳進去後，指向的類型的指標不為0了，因為有類型了， 所以比較為false。 interface 類型比較， 要是 兩個指標都相等， 才能相等。

常用技巧

待補充

1. func的參數處理: 返回具體的類型，接收interfaces參數