[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 string
Age 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) //返回 cancelCtx
func WithDeadline(parent Context, deadline time.Time) (Context, CancelFunc) //返回 timerCtx
func 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 uint64
func (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 main
import (
"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))
}
複製程式碼返回結果如下
false
false
false
true
true
複製程式碼為啥呢？
一個interface{}型別的變數包含了2個指標，一個指標指向值的型別，另外一個指標指向實際的值 對一個interface{}型別的nil變數來說，它的兩個指標都是0；但是var a *State傳進去後，指向的型別的指標不為0了，因為有型別了， 所以比較為false。 interface 型別比較， 要是 兩個指標都相等， 才能相等。
常用技巧
待補充
- func的引數處理: 返回具體的型別，接收interfaces引數