## 附録：作者/譯者 ### 英文作者 - **[Alan A. A. Donovan](https://github.com/adonovan)** is a member of [Google’s Go](https://golang.org/) team in New York. He holds computer science degrees from Cambridge and MIT and has been programming in industry since 1996. Since 2005, he has worked at Google on infrastructure projects and was the co-designer of its proprietary build system, [Blaze](http://bazel.io/). He has built many libraries and tools for static analysis of Go programs, including [oracle](https://godoc.org/golang.org/x/tools/oracle), [`godoc -analysis`](https://godoc.org/golang.org/x/tools/cmd/godoc), eg, and [gorename](https://godoc.org/golang.org/x/tools/cmd/gorename). - **[Brian W. Kernighan](http://www.cs.princeton.edu/~bwk/)** is a professor in the Computer Science Department at Princeton University. He was a member of technical staff in the Computing Science Research Center at [Bell Labs](http://www.cs.bell-labs.com/) from 1969 until 2000, where he worked on languages and tools for [Unix](http://doc.cat-v.org/unix/). He is the co-author of several books, including [The C Programming Language, Second Edition (Prentice Hall, 1988)](http://s3-us-west-2.amazonaws.com/belllabs-microsite-dritchie/cbook/index.html), and [The Practice of Programming (Addison-Wesley, 1999)](https://en.wikipedia.org/wiki/The_Practice_of_Programming). ------- ### 中文譯者 中文譯者 | 章節 -------------------------------------- | ------------------------- `chai2010 ` | 前言/第2~4章/第10~13章 `CrazySssst` | 第5章 `foreversmart ` | 第7章 `Xargin ` | 第1章/第6章/第8~9章 ------- ## 譯文授權 除特别註明外, 本站內容均采用[知識共享-署名(CC-BY) 3.0協議](http://creativecommons.org/licenses/by/3.0/)授權, 代碼遵循[Go項目的BSD協議](http://golang.org/LICENSE)授權.

## 13.5. 幾點忠告 我們在前一章結尾的時候，我們警告要謹慎使用reflect包。那些警告同樣適用於本章的unsafe包。 高級語言使得程序員不用在關心眞正運行程序的指令細節，同時也不再需要關註許多如內存布局之類的實現細節。因爲高級語言這個絶緣的抽象層，我們可以編寫安全健壯的，併且可以運行在不同操作繫統上的具有高度可移植性的程序。 但是unsafe包，它讓程序員可以透過這個絶緣的抽象層直接使用一些必要的功能，雖然可能是爲了獲得更好的性能。但是代價就是犧牲了可移植性和程序安全，因此使用unsafe包是一個危險的行爲。我們對何時以及如何使用unsafe包的建議和我們在11.5節提到的Knuth對過早優化的建議類似。大多數Go程序員可能永遠不會需要直接使用unsafe包。當然，也永遠都會有一些需要使用unsafe包實現會更簡單的場景。如果確實認爲使用unsafe包是最理想的方式，那麽應該盡可能將它限製在較小的范圍，那樣其它代碼就忽略unsafe的影響。 現在，趕緊將最後兩章拋入腦後吧。編寫一些實實在在的應用是眞理。請遠離reflect的unsafe包，除非你確實需要它們。 最後，用Go快樂地編程。我們希望你能像我們一樣喜歡Go語言。

## 13.4. 通過cgo調用C代碼 Go程序可能會遇到要訪問C語言的某些硬件驅動函數的場景，或者是從一個C++語言實現的嵌入式數據庫査詢記録的場景，或者是使用Fortran語言實現的一些線性代數庫的場景。C語言作爲一個通用語言，很多庫會選擇提供一個C兼容的API，然後用其他不同的編程語言實現（譯者：Go語言需要也應該擁抱這些鉅大的代碼遺産）。 在本節中，我們將構建一個簡易的數據壓縮程序，使用了一個Go語言自帶的叫cgo的用於支援C語言函數調用的工具。這類工具一般被稱爲 *foreign-function interfaces* （簡稱ffi）, 併且在類似工具中cgo也不是唯一的。SWIG（ http://swig.org ）是另一個類似的且被廣泛使用的工具，SWIG提供了很多複雜特性以支援C++的特性，但SWIG併不是我們要討論的主題。 在標準庫的`compress/...`子包有很多流行的壓縮算法的編碼和解碼實現，包括流行的LZW壓縮算法（Unix的compress命令用的算法）和DEFLATE壓縮算法（GNU gzip命令用的算法）。這些包的API的細節雖然有些差異，但是它們都提供了針對 io.Writer類型輸出的壓縮接口和提供了針對io.Reader類型輸入的解壓縮接口。例如： ```Go package gzip // compress/gzip func NewWriter(w io.Writer) io.WriteCloser func NewReader(r io.Reader) (io.ReadCloser, error) ``` bzip2壓縮算法，是基於優雅的Burrows-Wheeler變換算法，運行速度比gzip要慢，但是可以提供更高的壓縮比。標準庫的compress/bzip2包目前還沒有提供bzip2壓縮算法的實現。完全從頭開始實現是一個壓縮算法是一件繁瑣的工作，而且 http://bzip.org 已經有現成的libbzip2的開源實現，不僅文檔齊全而且性能又好。 如果是比較小的C語言庫，我們完全可以用純Go語言重新實現一遍。如果我們對性能也沒有特殊要求的話，我們還可以用os/exec包的方法將C編寫的應用程序作爲一個子進程運行。隻有當你需要使用複雜而且性能更高的底層C接口時，就是使用cgo的場景了（譯註：用os/exec包調用子進程的方法會導致程序運行時依賴那個應用程序）。下面我們將通過一個例子講述cgo的具體用法。 譯註：本章采用的代碼都是最新的。因爲之前已經出版的書中包含的代碼隻能在Go1.5之前使用。從Go1.6開始，Go語言已經明確規定了哪些Go語言指針可以之間傳入C語言函數。新代碼重點是增加了bz2alloc和bz2free的兩個函數，用於bz_stream對象空間的申請和釋放操作。下面是新代碼中增加的註釋，説明這個問題： ```Go // The version of this program that appeared in the first and second // printings did not comply with the proposed rules for passing // pointers between Go and C, described here: // https://github.com/golang/proposal/blob/master/design/12416-cgo-pointers.md // // The rules forbid a C function like bz2compress from storing 'in' // and 'out' (pointers to variables allocated by Go) into the Go // variable 's', even temporarily. // // The version below, which appears in the third printing, has been // corrected. To comply with the rules, the bz_stream variable must // be allocated by C code. We have introduced two C functions, // bz2alloc and bz2free, to allocate and free instances of the // bz_stream type. Also, we have changed bz2compress so that before // it returns, it clears the fields of the bz_stream that contain // pointers to Go variables. ``` 要使用libbzip2，我們需要先構建一個bz_stream結構體，用於保持輸入和輸出緩存。然後有三個函數：BZ2_bzCompressInit用於初始化緩存，BZ2_bzCompress用於將輸入緩存的數據壓縮到輸出緩存，BZ2_bzCompressEnd用於釋放不需要的緩存。（目前不要擔心包的具體結構, 這個例子的目的就是演示各個部分如何組合在一起的。） 我們可以在Go代碼中直接調用BZ2_bzCompressInit和BZ2_bzCompressEnd，但是對於BZ2_bzCompress，我們將定義一個C語言的包裝函數，用它完成眞正的工作。下面是C代碼，對應一個獨立的文件。 ```C gopl.io/ch13/bzip /* This file is gopl.io/ch13/bzip/bzip2.c, */ /* a simple wrapper for libbzip2 suitable for cgo. */ #include int bz2compress(bz_stream *s, int action, char *in, unsigned *inlen, char *out, unsigned *outlen) { s->next_in = in; s->avail_in = *inlen; s->next_out = out; s->avail_out = *outlen; int r = BZ2_bzCompress(s, action); *inlen -= s->avail_in; *outlen -= s->avail_out; s->next_in = s->next_out = NULL; return r; } ``` 現在讓我們轉到Go語言部分，第一部分如下所示。其中`import "C"`的語句是比較特别的。其實併沒有一個叫C的包，但是這行語句會讓Go編譯程序在編譯之前先運行cgo工具。 ```Go // Package bzip provides a writer that uses bzip2 compression (bzip.org). package bzip /* #cgo CFLAGS: -I/usr/include #cgo LDFLAGS: -L/usr/lib -lbz2 #include #include bz_stream* bz2alloc() { return calloc(1, sizeof(bz_stream)); } int bz2compress(bz_stream *s, int action, char *in, unsigned *inlen, char *out, unsigned *outlen); void bz2free(bz_stream* s) { free(s); } */ import "C" import ( "io" "unsafe" ) type writer struct { w io.Writer // underlying output stream stream *C.bz_stream outbuf [64 * 1024]byte } // NewWriter returns a writer for bzip2-compressed streams. func NewWriter(out io.Writer) io.WriteCloser { const blockSize = 9 const verbosity = 0 const workFactor = 30 w := &writer{w: out, stream: C.bz2alloc()} C.BZ2_bzCompressInit(w.stream, blockSize, verbosity, workFactor) return w } ``` 在預處理過程中，cgo工具爲生成一個臨時包用於包含所有在Go語言中訪問的C語言的函數或類型。例如C.bz_stream和C.BZ2_bzCompressInit。cgo工具通過以某種特殊的方式調用本地的C編譯器來發現在Go源文件導入聲明前的註釋中包含的C頭文件中的內容（譯註：`import "C"`語句前僅捱着的註釋是對應cgo的特殊語法，對應必要的構建參數選項和C語言代碼）。 在cgo註釋中還可以包含#cgo指令，用於給C語言工具鏈指定特殊的參數。例如CFLAGS和LDFLAGS分别對應傳給C語言編譯器的編譯參數和鏈接器參數，使它們可以特定目録找到bzlib.h頭文件和libbz2.a庫文件。這個例子假設你已經在/usr目録成功安裝了bzip2庫。如果bzip2庫是安裝在不同的位置，你需要更新這些參數（譯註：這里有一個從純C代碼生成的cgo綁定，不依賴bzip2靜態庫和操作繫統的具體環境，具體請訪問 https://github.com/chai2010/bzip2 ）。 NewWriter函數通過調用C語言的BZ2_bzCompressInit函數來初始化stream中的緩存。在writer結構中還包括了另一個buffer，用於輸出緩存。 下面是Write方法的實現，返迴成功壓縮數據的大小，主體是一個循環中調用C語言的bz2compress函數實現的。從代碼可以看到，Go程序可以訪問C語言的bz_stream、char和uint類型，還可以訪問bz2compress等函數，甚至可以訪問C語言中像BZ_RUN那樣的宏定義，全部都是以C.x語法訪問。其中C.uint類型和Go語言的uint類型併不相同，卽使它們具有相同的大小也是不同的類型。 ```Go func (w *writer) Write(data []byte) (int, error) { if w.stream == nil { panic("closed") } var total int // uncompressed bytes written for len(data) > 0 { inlen, outlen := C.uint(len(data)), C.uint(cap(w.outbuf)) C.bz2compress(w.stream, C.BZ_RUN, (*C.char)(unsafe.Pointer(&data[0])), &inlen, (*C.char)(unsafe.Pointer(&w.outbuf)), &outlen) total += int(inlen) data = data[inlen:] if _, err := w.w.Write(w.outbuf[:outlen]); err != nil { return total, err } } return total, nil } ``` 在循環的每次迭代中，向bz2compress傳入數據的地址和剩餘部分的長度，還有輸出緩存w.outbuf的地址和容量。這兩個長度信息通過它們的地址傳入而不是值傳入，因爲bz2compress函數可能會根據已經壓縮的數據和壓縮後數據的大小來更新這兩個值。每個塊壓縮後的數據被寫入到底層的io.Writer。 Close方法和Write方法有着類似的結構，通過一個循環將剩餘的壓縮數據刷新到輸出緩存。 ```Go // Close flushes the compressed data and closes the stream. // It does not close the underlying io.Writer. func (w *writer) Close() error { if w.stream == nil { panic("closed") } defer func() { C.BZ2_bzCompressEnd(w.stream) C.bz2free(w.stream) w.stream = nil }() for { inlen, outlen := C.uint(0), C.uint(cap(w.outbuf)) r := C.bz2compress(w.stream, C.BZ_FINISH, nil, &inlen, (*C.char)(unsafe.Pointer(&w.outbuf)), &outlen) if _, err := w.w.Write(w.outbuf[:outlen]); err != nil { return err } if r == C.BZ_STREAM_END { return nil } } } ``` 壓縮完成後，Close方法用了defer函數確保函數退出前調用C.BZ2_bzCompressEnd和C.bz2free釋放相關的C語言運行時資源。此刻w.stream指針將不再有效，我們將它設置爲nil以保證安全，然後在每個方法中增加了nil檢測，以防止用戶在關閉後依然錯誤使用相關方法。 上面的實現中，不僅僅寫是非併發安全的，甚至併發調用Close和Write方法也可能導致程序的的崩潰。脩複這個問題是練習13.3的內容。 下面的bzipper程序，使用我們自己包實現的bzip2壓縮命令。它的行爲和許多Unix繫統的bzip2命令類似。 ```Go gopl.io/ch13/bzipper // Bzipper reads input, bzip2-compresses it, and writes it out. package main import ( "io" "log" "os" "gopl.io/ch13/bzip" ) func main() { w := bzip.NewWriter(os.Stdout) if _, err := io.Copy(w, os.Stdin); err != nil { log.Fatalf("bzipper: %v\n", err) } if err := w.Close(); err != nil { log.Fatalf("bzipper: close: %v\n", err) } } ``` 在上面的場景中，我們使用bzipper壓縮了/usr/share/dict/words繫統自帶的詞典，從938,848字節壓縮到335,405字節。大約是原始數據大小的三分之一。然後使用繫統自帶的bunzip2命令進行解壓。壓縮前後文件的SHA256哈希碼是相同了，這也説明了我們的壓縮工具是正確的。（如果你的繫統沒有sha256sum命令，那麽請先按照練習4.2實現一個類似的工具） ``` $ go build gopl.io/ch13/bzipper $ wc -c < /usr/share/dict/words 938848 $ sha256sum < /usr/share/dict/words 126a4ef38493313edc50b86f90dfdaf7c59ec6c948451eac228f2f3a8ab1a6ed - $ ./bzipper < /usr/share/dict/words | wc -c 335405 $ ./bzipper < /usr/share/dict/words | bunzip2 | sha256sum 126a4ef38493313edc50b86f90dfdaf7c59ec6c948451eac228f2f3a8ab1a6ed - ``` 我們演示了如何將一個C語言庫鏈接到Go語言程序。相反, 將Go編譯爲靜態庫然後鏈接到C程序，或者將Go程序編譯爲動態庫然後在C程序中動態加載也都是可行的（譯註：在Go1.5中，Windows繫統的Go語言實現併不支持生成C語言動態庫或靜態庫的特性。不過好消息是，目前已經有人在嚐試解決這個問題，具體請訪問 [Issue11058](https://github.com/golang/go/issues/11058) ）。這里我們隻展示的cgo很小的一些方面，更多的關於內存管理、指針、迴調函數、中斷信號處理、字符串、errno處理、終結器，以及goroutines和繫統線程的關繫等，有很多細節可以討論。特别是如何將Go語言的指針傳入C函數的規則也是異常複雜的（譯註：簡單來説，要傳入C函數的Go指針指向的數據本身不能包含指針或其他引用類型；併且C函數在返迴後不能繼續持有Go指針；併且在C函數返迴之前，Go指針是被鎖定的，不能導致對應指針數據被移動或棧的調整），部分的原因在13.2節有討論到，但是在Go1.5中還沒有被明確（譯註：Go1.6將會明確cgo中的指針使用規則）。如果要進一步閲讀，可以從 https://golang.org/cmd/cgo 開始。 **練習 13.3：** 使用sync.Mutex以保證bzip2.writer在多個goroutines中被併發調用是安全的。 **練習 13.4：** 因爲C庫依賴的限製。 使用os/exec包啟動/bin/bzip2命令作爲一個子進程，提供一個純Go的bzip.NewWriter的替代實現（譯註：雖然是純Go實現，但是運行時將依賴/bin/bzip2命令，其他操作繫統可能無法運行）。

## 13.3. 示例: 深度相等判斷 來自reflect包的DeepEqual函數可以對兩個值進行深度相等判斷。DeepEqual函數使用內建的==比較操作符對基礎類型進行相等判斷，對於複合類型則遞歸該變量的每個基礎類型然後做類似的比較判斷。因爲它可以工作在任意的類型上，甚至對於一些不支持==操作運算符的類型也可以工作，因此在一些測試代碼中廣泛地使用該函數。比如下面的代碼是用DeepEqual函數比較兩個字符串數組是否相等。 ```Go func TestSplit(t *testing.T) { got := strings.Split("a:b:c", ":") want := []string{"a", "b", "c"}; if !reflect.DeepEqual(got, want) { /* ... */ } } ``` 盡管DeepEqual函數很方便，而且可以支持任意的數據類型，但是它也有不足之處。例如，它將一個nil值的map和非nil值但是空的map視作不相等，同樣nil值的slice 和非nil但是空的slice也視作不相等。 ```Go var a, b []string = nil, []string{} fmt.Println(reflect.DeepEqual(a, b)) // "false" var c, d map[string]int = nil, make(map[string]int) fmt.Println(reflect.DeepEqual(c, d)) // "false" ``` 我們希望在這里實現一個自己的Equal函數，用於比較類型的值。和DeepEqual函數類似的地方是它也是基於slice和map的每個元素進行遞歸比較，不同之處是它將nil值的slice（map類似）和非nil值但是空的slice視作相等的值。基礎部分的比較可以基於reflect包完成，和12.3章的Display函數的實現方法類似。同樣，我們也定義了一個內部函數equal，用於內部的遞歸比較。讀者目前不用關心seen參數的具體含義。對於每一對需要比較的x和y，equal函數首先檢測它們是否都有效（或都無效），然後檢測它們是否是相同的類型。剩下的部分是一個鉅大的switch分支，用於相同基礎類型的元素比較。因爲頁面空間的限製，我們省略了一些相似的分支。 ```Go gopl.io/ch13/equal func equal(x, y reflect.Value, seen map[comparison]bool) bool { if !x.IsValid() || !y.IsValid() { return x.IsValid() == y.IsValid() } if x.Type() != y.Type() { return false } // ...cycle check omitted (shown later)... switch x.Kind() { case reflect.Bool: return x.Bool() == y.Bool() case reflect.String: return x.String() == y.String() // ...numeric cases omitted for brevity... case reflect.Chan, reflect.UnsafePointer, reflect.Func: return x.Pointer() == y.Pointer() case reflect.Ptr, reflect.Interface: return equal(x.Elem(), y.Elem(), seen) case reflect.Array, reflect.Slice: if x.Len() != y.Len() { return false } for i := 0; i < x.Len(); i++ { if !equal(x.Index(i), y.Index(i), seen) { return false } } return true // ...struct and map cases omitted for brevity... } panic("unreachable") } ``` 和前面的建議一樣，我們併不公開reflect包相關的接口，所以導出的函數需要在內部自己將變量轉爲reflect.Value類型。 ```Go // Equal reports whether x and y are deeply equal. func Equal(x, y interface{}) bool { seen := make(map[comparison]bool) return equal(reflect.ValueOf(x), reflect.ValueOf(y), seen) } type comparison struct { x, y unsafe.Pointer treflect.Type } ``` 爲了確保算法對於有環的數據結構也能正常退出，我們必鬚記録每次已經比較的變量，從而避免進入第二次的比較。Equal函數分配了一組用於比較的結構體，包含每對比較對象的地址（unsafe.Pointer形式保存）和類型。我們要記録類型的原因是，有些不同的變量可能對應相同的地址。例如，如果x和y都是數組類型，那麽x和x[0]將對應相同的地址，y和y[0]也是對應相同的地址，這可以用於區分x與y之間的比較或x[0]與y[0]之間的比較是否進行過了。 ```Go // cycle check if x.CanAddr() && y.CanAddr() { xptr := unsafe.Pointer(x.UnsafeAddr()) yptr := unsafe.Pointer(y.UnsafeAddr()) if xptr == yptr { return true // identical references } c := comparison{xptr, yptr, x.Type()} if seen[c] { return true // already seen } seen[c] = true } ``` 這是Equal函數用法的例子: ```Go fmt.Println(Equal([]int{1, 2, 3}, []int{1, 2, 3})) // "true" fmt.Println(Equal([]string{"foo"}, []string{"bar"})) // "false" fmt.Println(Equal([]string(nil), []string{})) // "true" fmt.Println(Equal(map[string]int(nil), map[string]int{})) // "true" ``` Equal函數甚至可以處理類似12.3章中導致Display陷入陷入死循環的帶有環的數據。 ```Go // Circular linked lists a -> b -> a and c -> c. type link struct { value string tail *link } a, b, c := &link{value: "a"}, &link{value: "b"}, &link{value: "c"} a.tail, b.tail, c.tail = b, a, c fmt.Println(Equal(a, a)) // "true" fmt.Println(Equal(b, b)) // "true" fmt.Println(Equal(c, c)) // "true" fmt.Println(Equal(a, b)) // "false" fmt.Println(Equal(a, c)) // "false" ``` **練習 13.1：** 定義一個深比較函數，對於十億以內的數字比較，忽略類型差異。 **練習 13.2：** 編寫一個函數，報告其參數是否循環數據結構。

## 13.2. unsafe.Pointer 大多數指針類型會寫成`*T`，表示是“一個指向T類型變量的指針”。unsafe.Pointer是特别定義的一種指針類型（譯註：類似C語言中的`void*`類型的指針），它可以包含任意類型變量的地址。當然，我們不可以直接通過`*p`來獲取unsafe.Pointer指針指向的眞實變量的值，因爲我們併不知道變量的具體類型。和普通指針一樣，unsafe.Pointer指針也是可以比較的，併且支持和nil常量比較判斷是否爲空指針。 一個普通的`*T`類型指針可以被轉化爲unsafe.Pointer類型指針，併且一個unsafe.Pointer類型指針也可以被轉迴普通的指針，被轉迴普通的指針類型併不需要和原始的`*T`類型相同。通過將`*float64`類型指針轉化爲`*uint64`類型指針，我們可以査看一個浮點數變量的位模式。 ```Go package math func Float64bits(f float64) uint64 { return *(*uint64)(unsafe.Pointer(&f)) } fmt.Printf("%#016x\n", Float64bits(1.0)) // "0x3ff0000000000000" ``` 通過轉爲新類型指針，我們可以更新浮點數的位模式。通過位模式操作浮點數是可以的，但是更重要的意義是指針轉換語法讓我們可以在不破壞類型繫統的前提下向內存寫入任意的值。 一個unsafe.Pointer指針也可以被轉化爲uintptr類型，然後保存到指針型數值變量中（譯註：這隻是和當前指針相同的一個數字值，併不是一個指針），然後用以做必要的指針數值運算。（第三章內容，uintptr是一個無符號的整型數，足以保存一個地址）這種轉換雖然也是可逆的，但是將uintptr轉爲unsafe.Pointer指針可能會破壞類型繫統，因爲併不是所有的數字都是有效的內存地址。 許多將unsafe.Pointer指針轉爲原生數字，然後再轉迴爲unsafe.Pointer類型指針的操作也是不安全的。比如下面的例子需要將變量x的地址加上b字段地址偏移量轉化爲`*int16`類型指針，然後通過該指針更新x.b： ```Go //gopl.io/ch13/unsafeptr var x struct { a bool b int16 c []int } // 和 pb := &x.b 等價 pb := (*int16)(unsafe.Pointer( uintptr(unsafe.Pointer(&x)) + unsafe.Offsetof(x.b))) *pb = 42 fmt.Println(x.b) // "42" ``` 上面的寫法盡管很繁瑣，但在這里併不是一件壞事，因爲這些功能應該很謹慎地使用。不要試圖引入一個uintptr類型的臨時變量，因爲它可能會破壞代碼的安全性（譯註：這是眞正可以體會unsafe包爲何不安全的例子）。下面段代碼是錯誤的： ```Go // NOTE: subtly incorrect! tmp := uintptr(unsafe.Pointer(&x)) + unsafe.Offsetof(x.b) pb := (*int16)(unsafe.Pointer(tmp)) *pb = 42 ``` 産生錯誤的原因很微妙。有時候垃圾迴收器會移動一些變量以降低內存碎片等問題。這類垃圾迴收器被稱爲移動GC。當一個變量被移動，所有的保存改變量舊地址的指針必鬚同時被更新爲變量移動後的新地址。從垃圾收集器的視角來看，一個unsafe.Pointer是一個指向變量的指針，因此當變量被移動是對應的指針也必鬚被更新；但是uintptr類型的臨時變量隻是一個普通的數字，所以其值不應該被改變。上面錯誤的代碼因爲引入一個非指針的臨時變量tmp，導致垃圾收集器無法正確識别這個是一個指向變量x的指針。當第二個語句執行時，變量x可能已經被轉移，這時候臨時變量tmp也就不再是現在的`&x.b`地址。第三個向之前無效地址空間的賦值語句將徹底摧譭整個程序！ 還有很多類似原因導致的錯誤。例如這條語句： ```Go pT := uintptr(unsafe.Pointer(new(T))) // 提示: 錯誤! ``` 這里併沒有指針引用`new`新創建的變量，因此該語句執行完成之後，垃圾收集器有權馬上迴收其內存空間，所以返迴的pT將是無效的地址。 雖然目前的Go語言實現還沒有使用移動GC（譯註：未來可能實現），但這不該是編寫錯誤代碼僥幸的理由：當前的Go語言實現已經有移動變量的場景。在5.2節我們提到goroutine的棧是根據需要動態增長的。當發送棧動態增長的時候，原來棧中的所以變量可能需要被移動到新的更大的棧中，所以我們併不能確保變量的地址在整個使用週期內是不變的。 在編寫本文時，還沒有清晰的原則來指引Go程序員，什麽樣的unsafe.Pointer和uintptr的轉換是不安全的（參考 [Issue7192](https://github.com/golang/go/issues/7192) ）. 譯註: 該問題已經關閉），因此我們強烈建議按照最壞的方式處理。將所有包含變量地址的uintptr類型變量當作BUG處理，同時減少不必要的unsafe.Pointer類型到uintptr類型的轉換。在第一個例子中，有三個轉換——字段偏移量到uintptr的轉換和轉迴unsafe.Pointer類型的操作——所有的轉換全在一個表達式完成。 當調用一個庫函數，併且返迴的是uintptr類型地址時（譯註：普通方法實現的函數不盡量不要返迴該類型。下面例子是reflect包的函數，reflect包和unsafe包一樣都是采用特殊技術實現的，編譯器可能給它們開了後門），比如下面反射包中的相關函數，返迴的結果應該立卽轉換爲unsafe.Pointer以確保指針指向的是相同的變量。 ```Go package reflect func (Value) Pointer() uintptr func (Value) UnsafeAddr() uintptr func (Value) InterfaceData() [2]uintptr // (index 1) ```

## 13.1. unsafe.Sizeof, Alignof 和 Offsetof unsafe.Sizeof函數返迴操作數在內存中的字節大小，參數可以是任意類型的表達式，但是它併不會對表達式進行求值。一個Sizeof函數調用是一個對應uintptr類型的常量表達式，因此返迴的結果可以用作數組類型的長度大小，或者用作計算其他的常量。 ```Go import "unsafe" fmt.Println(unsafe.Sizeof(float64(0))) // "8" ``` Sizeof函數返迴的大小隻包括數據結構中固定的部分，例如字符串對應結構體中的指針和字符串長度部分，但是併不包含指針指向的字符串的內容。Go語言中非聚合類型通常有一個固定的大小，盡管在不同工具鏈下生成的實際大小可能會有所不同。考慮到可移植性，引用類型或包含引用類型的大小在32位平台上是4個字節，在64位平台上是8個字節。 計算機在加載和保存數據時，如果內存地址合理地對齊的將會更有效率。例如2字節大小的int16類型的變量地址應該是偶數，一個4字節大小的rune類型變量的地址應該是4的倍數，一個8字節大小的float64、uint64或64-bit指針類型變量的地址應該是8字節對齊的。但是對於再大的地址對齊倍數則是不需要的，卽使是complex128等較大的數據類型最多也隻是8字節對齊。 由於地址對齊這個因素，一個聚合類型（結構體或數組）的大小至少是所有字段或元素大小的總和，或者更大因爲可能存在內存空洞。內存空洞是編譯器自動添加的沒有被使用的內存空間，用於保證後面每個字段或元素的地址相對於結構或數組的開始地址能夠合理地對齊（譯註：內存空洞可能會存在一些隨機數據，可能會對用unsafe包直接操作內存的處理産生影響）。 類型 | 大小 ----------------------------- | ---- bool | 1個字節 intN, uintN, floatN, complexN | N/8個字節(例如float64是8個字節) int, uint, uintptr | 1個機器字 *T | 1個機器字 string | 2個機器字(data,len) []T | 3個機器字(data,len,cap) map | 1個機器字 func | 1個機器字 chan | 1個機器字 interface | 2個機器字(type,value) Go語言的規范併沒有要求一個字段的聲明順序和內存中的順序是一致的，所以理論上一個編譯器可以隨意地重新排列每個字段的內存位置，隨然在寫作本書的時候編譯器還沒有這麽做。下面的三個結構體雖然有着相同的字段，但是第一種寫法比另外的兩個需要多50%的內存。 ```Go // 64-bit 32-bit struct{ bool; float64; int16 } // 3 words 4words struct{ float64; int16; bool } // 2 words 3words struct{ bool; int16; float64 } // 2 words 3words ``` 關於內存地址對齊算法的細節超出了本書的范圍，也不是每一個結構體都需要擔心這個問題，不過有效的包裝可以使數據結構更加緊湊（譯註：未來的Go語言編譯器應該會默認優化結構體的順序，當然用於應該也能夠指定具體的內存布局，相同討論請參考 [Issue10014](https://github.com/golang/go/issues/10014) ），內存使用率和性能都可能會受益。 `unsafe.Alignof` 函數返迴對應參數的類型需要對齊的倍數. 和 Sizeof 類似, Alignof 也是返迴一個常量表達式, 對應一個常量. 通常情況下布爾和數字類型需要對齊到它們本身的大小(最多8個字節), 其它的類型對齊到機器字大小. `unsafe.Offsetof` 函數的參數必鬚是一個字段 `x.f`, 然後返迴 `f` 字段相對於 `x` 起始地址的偏移量, 包括可能的空洞. 圖 13.1 顯示了一個結構體變量 x 以及其在32位和64位機器上的典型的內存. 灰色區域是空洞. ```Go var x struct { a bool b int16 c []int } ``` 下面顯示了對x和它的三個字段調用unsafe包相關函數的計算結果：  32位繫統： ``` Sizeof(x) = 16 Alignof(x) = 4 Sizeof(x.a) = 1 Alignof(x.a) = 1 Offsetof(x.a) = 0 Sizeof(x.b) = 2 Alignof(x.b) = 2 Offsetof(x.b) = 2 Sizeof(x.c) = 12 Alignof(x.c) = 4 Offsetof(x.c) = 4 ``` 64位繫統： ``` Sizeof(x) = 32 Alignof(x) = 8 Sizeof(x.a) = 1 Alignof(x.a) = 1 Offsetof(x.a) = 0 Sizeof(x.b) = 2 Alignof(x.b) = 2 Offsetof(x.b) = 2 Sizeof(x.c) = 24 Alignof(x.c) = 8 Offsetof(x.c) = 8 ``` 雖然這幾個函數在不安全的unsafe包，但是這幾個函數調用併不是眞的不安全，特别在需要優化內存空間時它們返迴的結果對於理解原生的內存布局很有幫助。

# 第13章 底層編程 Go語言的設計包含了諸多安全策略，限製了可能導致程序運行出現錯誤的用法。編譯時類型檢査檢査可以發現大多數類型不匹配的操作，例如兩個字符串做減法的錯誤。字符串、map、slice和chan等所有的內置類型，都有嚴格的類型轉換規則。 對於無法靜態檢測到的錯誤，例如數組訪問越界或使用空指針，運行時動態檢測可以保證程序在遇到問題的時候立卽終止併打印相關的錯誤信息。自動內存管理（垃圾內存自動迴收）可以消除大部分野指針和內存洩漏相關的問題。 Go語言的實現刻意隱藏了很多底層細節。我們無法知道一個結構體眞實的內存布局，也無法獲取一個運行時函數對應的機器碼，也無法知道當前的goroutine是運行在哪個操作繫統線程之上。事實上，Go語言的調度器會自己決定是否需要將某個goroutine從一個操作繫統線程轉移到另一個操作繫統線程。一個指向變量的指針也併沒有展示變量眞實的地址。因爲垃圾迴收器可能會根據需要移動變量的內存位置，當然變量對應的地址也會被自動更新。 總的來説，Go語言的這些特性使得Go程序相比較低級的C語言來説更容易預測和理解，程序也不容易崩潰。通過隱藏底層的實現細節，也使得Go語言編寫的程序具有高度的可移植性，因爲語言的語義在很大程度上是獨立於任何編譯器實現、操作繫統和CPU繫統結構的（當然也不是完全絶對獨立：例如int等類型就依賴於CPU機器字的大小，某些表達式求值的具體順序，還有編譯器實現的一些額外的限製等）。 有時候我們可能會放棄使用部分語言特性而優先選擇更好具有更好性能的方法，例如需要與其他語言編寫的庫互操作，或者用純Go語言無法實現的某些函數。 在本章，我們將展示如何使用unsafe包來襬脫Go語言規則帶來的限製，講述如何創建C語言函數庫的綁定，以及如何進行繫統調用。 本章提供的方法不應該輕易使用（譯註：屬於黑魔法，雖然可能功能很強大，但是也容易誤傷到自己）。如果沒有處理好細節，它們可能導致各種不可預測的併且隱晦的錯誤，甚至連有經驗的的C語言程序員也無法理解這些錯誤。使用unsafe包的同時也放棄了Go語言保證與未來版本的兼容性的承諾，因爲它必然會在有意無意中會使用很多實現的細節，而這些實現的細節在未來的Go語言中很可能會被改變。 要註意的是，unsafe包是一個采用特殊方式實現的包。雖然它可以和普通包一樣的導入和使用，但它實際上是由編譯器實現的。它提供了一些訪問語言內部特性的方法，特别是內存布局相關的細節。將這些特性封裝到一個獨立的包中，是爲在極少數情況下需要使用的時候，同時引起人們的註意（譯註：因爲看包的名字就知道使用unsafe包是不安全的）。此外，有一些環境因爲安全的因素可能限製這個包的使用。 不過unsafe包被廣泛地用於比較低級的包, 例如runtime、os、syscall還有net包等，因爲它們需要和操作繫統密切配合，但是對於普通的程序一般是不需要使用unsafe包的。

## 12.9. 幾點忠告 雖然反射提供的API遠多於我們講到的，我們前面的例子主要是給出了一個方向，通過反射可以實現哪些功能。反射是一個強大併富有表達力的工具，但是它應該被小心地使用，原因有三。 第一個原因是，基於反射的代碼是比較脆弱的。對於每一個會導致編譯器報告類型錯誤的問題，在反射中都有與之相對應的問題，不同的是編譯器會在構建時馬上報告錯誤，而反射則是在眞正運行到的時候才會拋出panic異常，可能是寫完代碼很久之後的時候了，而且程序也可能運行了很長的時間。 以前面的readList函數（§12.6）爲例，爲了從輸入讀取字符串併填充int類型的變量而調用的reflect.Value.SetString方法可能導致panic異常。絶大多數使用反射的程序都有類似的風險，需要非常小心地檢査每個reflect.Value的對於值的類型、是否可取地址，還有是否可以被脩改等。 避免這種因反射而導致的脆弱性的問題的最好方法是將所有的反射相關的使用控製在包的內部，如果可能的話避免在包的API中直接暴露reflect.Value類型，這樣可以限製一些非法輸入。如果無法做到這一點，在每個有風險的操作前指向額外的類型檢査。以標準庫中的代碼爲例，當fmt.Printf收到一個非法的操作數是，它併不會拋出panic異常，而是打印相關的錯誤信息。程序雖然還有BUG，但是會更加容易診斷。 ```Go fmt.Printf("%d %s\n", "hello", 42) // "%!d(string=hello) %!s(int=42)" ``` 反射同樣降低了程序的安全性，還影響了自動化重構和分析工具的準確性，因爲它們無法識别運行時才能確認的類型信息。 避免使用反射的第二個原因是，卽使對應類型提供了相同文檔，但是反射的操作不能做靜態類型檢査，而且大量反射的代碼通常難以理解。總是需要小心翼翼地爲每個導出的類型和其它接受interface{}或reflect.Value類型參數的函數維護説明文檔。 第三個原因，基於反射的代碼通常比正常的代碼運行速度慢一到兩個數量級。對於一個典型的項目，大部分函數的性能和程序的整體性能關繫不大，所以使用反射可能會使程序更加清晰。測試是一個特别適合使用反射的場景，因爲每個測試的數據集都很小。但是對於性能關鍵路徑的函數，最好避免使用反射。

## 12.8. 顯示一個類型的方法集 我們的最後一個例子是使用reflect.Type來打印任意值的類型和枚舉它的方法： ```Go gopl.io/ch12/methods // Print prints the method set of the value x. func Print(x interface{}) { v := reflect.ValueOf(x) t := v.Type() fmt.Printf("type %s\n", t) for i := 0; i < v.NumMethod(); i++ { methType := v.Method(i).Type() fmt.Printf("func (%s) %s%s\n", t, t.Method(i).Name, strings.TrimPrefix(methType.String(), "func")) } } ``` reflect.Type和reflect.Value都提供了一個Method方法。每次t.Method(i)調用將一個reflect.Method的實例，對應一個用於描述一個方法的名稱和類型的結構體。每次v.Method(i)方法調用都返迴一個reflect.Value以表示對應的值（§6.4），也就是一個方法是幫到它的接收者的。使用reflect.Value.Call方法（我們之類沒有演示），將可以調用一個Func類型的Value，但是這個例子中隻用到了它的類型。 這是屬於time.Duration和`*strings.Replacer`兩個類型的方法： ```Go methods.Print(time.Hour) // Output: // type time.Duration // func (time.Duration) Hours() float64 // func (time.Duration) Minutes() float64 // func (time.Duration) Nanoseconds() int64 // func (time.Duration) Seconds() float64 // func (time.Duration) String() string methods.Print(new(strings.Replacer)) // Output: // type *strings.Replacer // func (*strings.Replacer) Replace(string) string // func (*strings.Replacer) WriteString(io.Writer, string) (int, error) ````

## 12.7. 獲取結構體字段標識 在4.5節我們使用構體成員標籤用於設置對應JSON對應的名字。其中json成員標籤讓我們可以選擇成員的名字和抑製零值成員的輸出。在本節，我們將看到如果通過反射機製類獲取成員標籤。 對於一個web服務，大部分HTTP處理函數要做的第一件事情就是展開請求中的參數到本地變量中。我們定義了一個工具函數，叫params.Unpack，通過使用結構體成員標籤機製來讓HTTP處理函數解析請求參數更方便。 首先，我們看看如何使用它。下面的search函數是一個HTTP請求處理函數。它定義了一個匿名結構體類型的變量，用結構體的每個成員表示HTTP請求的參數。其中結構體成員標籤指明了對於請求參數的名字，爲了減少UTRL的長度這些參數名通常都是神祕的縮略詞。Unpack將請求參數填充到合適的結構體成員中，這樣我們可以方便地通過合適的類型類來訪問這些參數。 ```Go gopl.io/ch12/search import "gopl.io/ch12/params" // search implements the /search URL endpoint. func search(resp http.ResponseWriter, req *http.Request) { var data struct { Labels []string `http:"l"` MaxResults int `http:"max"` Exact bool `http:"x"` } data.MaxResults = 10 // set default if err := params.Unpack(req, &data); err != nil { http.Error(resp, err.Error(), http.StatusBadRequest) // 400 return } // ...rest of handler... fmt.Fprintf(resp, "Search: %+v\n", data) } ``` 下面的Unpack函數主要完成三件事情。第一，它調用req.ParseForm()來解析HTTP請求。然後，req.Form將包含所有的請求參數，不管HTTP客戶端使用的是GET還是POST請求方法。 下一步，Unpack函數將構建每個結構體成員有效參數名字到成員變量的映射。如果結構體成員有成員標籤的話，有效參數名字可能和實際的成員名字不相同。reflect.Type的Field方法將返迴一個reflect.StructField，里面含有每個成員的名字、類型和可選的成員標籤等信息。其中成員標籤信息對應reflect.StructTag類型的字符串，併且提供了Get方法用於解析和根據特定key提取的子串，例如這里的http:"..."形式的子串。 ```Go gopl.io/ch12/params // Unpack populates the fields of the struct pointed to by ptr // from the HTTP request parameters in req. func Unpack(req *http.Request, ptr interface{}) error { if err := req.ParseForm(); err != nil { return err } // Build map of fields keyed by effective name. fields := make(map[string]reflect.Value) v := reflect.ValueOf(ptr).Elem() // the struct variable for i := 0; i < v.NumField(); i++ { fieldInfo := v.Type().Field(i) // a reflect.StructField tag := fieldInfo.Tag // a reflect.StructTag name := tag.Get("http") if name == "" { name = strings.ToLower(fieldInfo.Name) } fields[name] = v.Field(i) } // Update struct field for each parameter in the request. for name, values := range req.Form { f := fields[name] if !f.IsValid() { continue // ignore unrecognized HTTP parameters } for _, value := range values { if f.Kind() == reflect.Slice { elem := reflect.New(f.Type().Elem()).Elem() if err := populate(elem, value); err != nil { return fmt.Errorf("%s: %v", name, err) } f.Set(reflect.Append(f, elem)) } else { if err := populate(f, value); err != nil { return fmt.Errorf("%s: %v", name, err) } } } } return nil } ``` 最後，Unpack遍歷HTTP請求的name/valu參數鍵值對，併且根據更新相應的結構體成員。迴想一下，同一個名字的參數可能出現多次。如果發生這種情況，併且對應的結構體成員是一個slice，那麽就將所有的參數添加到slice中。其它情況，對應的成員值將被覆蓋，隻有最後一次出現的參數值才是起作用的。 populate函數小心用請求的字符串類型參數值來填充單一的成員v（或者是slice類型成員中的單一的元素）。目前，它僅支持字符串、有符號整數和布爾型。其中其它的類型將留做練習任務。 ```Go func populate(v reflect.Value, value string) error { switch v.Kind() { case reflect.String: v.SetString(value) case reflect.Int: i, err := strconv.ParseInt(value, 10, 64) if err != nil { return err } v.SetInt(i) case reflect.Bool: b, err := strconv.ParseBool(value) if err != nil { return err } v.SetBool(b) default: return fmt.Errorf("unsupported kind %s", v.Type()) } return nil } ``` 如果我們上上面的處理程序添加到一個web服務器，則可以産生以下的會話： ``` $ go build gopl.io/ch12/search $ ./search & $ ./fetch 'http://localhost:12345/search' Search: {Labels:[] MaxResults:10 Exact:false} $ ./fetch 'http://localhost:12345/search?l=golang&l=programming' Search: {Labels:[golang programming] MaxResults:10 Exact:false} $ ./fetch 'http://localhost:12345/search?l=golang&l=programming&max=100' Search: {Labels:[golang programming] MaxResults:100 Exact:false} $ ./fetch 'http://localhost:12345/search?x=true&l=golang&l=programming' Search: {Labels:[golang programming] MaxResults:10 Exact:true} $ ./fetch 'http://localhost:12345/search?q=hello&x=123' x: strconv.ParseBool: parsing "123": invalid syntax $ ./fetch 'http://localhost:12345/search?q=hello&max=lots' max: strconv.ParseInt: parsing "lots": invalid syntax ``` **練習 12.11：** 編寫相應的Pack函數，給定一個結構體值，Pack函數將返迴合併了所有結構體成員和值的URL。 **練習 12.12：** 擴展成員標籤以表示一個請求參數的有效值規則。例如，一個字符串可以是有效的email地址或一個信用卡號碼，還有一個整數可能需要是有效的郵政編碼。脩改Unpack函數以檢査這些規則。 **練習 12.13：** 脩改S表達式的編碼器（§12.4）和解碼器（§12.6），采用和encoding/json包（§4.5）類似的方式使用成員標籤中的sexpr:"..."字串。

## 12.6. 示例: 解碼S表達式 標準庫中encoding/...下每個包中提供的Marshal編碼函數都有一個對應的Unmarshal函數用於解碼。例如，我們在4.5節中看到的，要將包含JSON編碼格式的字節slice數據解碼爲我們自己的Movie類型（§12.3），我們可以這樣做： ```Go data := []byte{/* ... */} var movie Movie err := json.Unmarshal(data, &movie) ``` Unmarshal函數使用了反射機製類脩改movie變量的每個成員，根據輸入的內容爲Movie成員創建對應的map、結構體和slice。 現在讓我們爲S表達式編碼實現一個簡易的Unmarshal，類似於前面的json.Unmarshal標準庫函數，對應我們之前實現的sexpr.Marshal函數的逆操作。我們必鬚提醒一下，一個健壯的和通用的實現通常需要比例子更多的代碼，爲了便於演示我們采用了精簡的實現。我們隻支持S表達式有限的子集，同時處理錯誤的方式也比較粗暴，代碼的目的是爲了演示反射的用法，而不是構造一個實用的S表達式的解碼器。 詞法分析器lexer使用了標準庫中的text/scanner包將輸入流的字節數據解析爲一個個類似註釋、標識符、字符串面值和數字面值之類的標記。輸入掃描器scanner的Scan方法將提前掃描和返迴下一個記號，對於rune類型。大多數記號，比如“(”，對應一個單一rune可表示的Unicode字符，但是text/scanner也可以用小的負數表示記號標識符、字符串等由多個字符組成的記號。調用Scan方法將返迴這些記號的類型，接着調用TokenText方法將返迴記號對應的文本內容。 因爲每個解析器可能需要多次使用當前的記號，但是Scan會一直向前掃描，所有我們包裝了一個lexer掃描器輔助類型，用於跟蹤最近由Scan方法返迴的記號。 ```Go gopl.io/ch12/sexpr type lexer struct { scan scanner.Scanner token rune // the current token } func (lex *lexer) next() { lex.token = lex.scan.Scan() } func (lex *lexer) text() string { return lex.scan.TokenText() } func (lex *lexer) consume(want rune) { if lex.token != want { // NOTE: Not an example of good error handling. panic(fmt.Sprintf("got %q, want %q", lex.text(), want)) } lex.next() } ``` 現在讓我們轉到語法解析器。它主要包含兩個功能。第一個是read函數，用於讀取S表達式的當前標記，然後根據S表達式的當前標記更新可取地址的reflect.Value對應的變量v。 ```Go func read(lex *lexer, v reflect.Value) { switch lex.token { case scanner.Ident: // The only valid identifiers are // "nil" and struct field names. if lex.text() == "nil" { v.Set(reflect.Zero(v.Type())) lex.next() return } case scanner.String: s, _ := strconv.Unquote(lex.text()) // NOTE: ignoring errors v.SetString(s) lex.next() return case scanner.Int: i, _ := strconv.Atoi(lex.text()) // NOTE: ignoring errors v.SetInt(int64(i)) lex.next() return case '(': lex.next() readList(lex, v) lex.next() // consume ')' return } panic(fmt.Sprintf("unexpected token %q", lex.text())) } ``` 我們的S表達式使用標識符區分兩個不同類型，結構體成員名和nil值的指針。read函數值處理nil類型的標識符。當遇到scanner.Ident爲“nil”是，使用reflect.Zero函數將變量v設置爲零值。而其它任何類型的標識符，我們都作爲錯誤處理。後面的readList函數將處理結構體的成員名。 一個“(”標記對應一個列表的開始。第二個函數readList，將一個列表解碼到一個聚合類型中（map、結構體、slice或數組），具體類型依然於傳入待填充變量的類型。每次遇到這種情況，循環繼續解析每個元素直到遇到於開始標記匹配的結束標記“)”，endList函數用於檢測結束標記。 最有趣的部分是遞歸。最簡單的是對數組類型的處理。直到遇到“)”結束標記，我們使用Index函數來獲取數組每個元素的地址，然後遞歸調用read函數處理。和其它錯誤類似，如果輸入數據導致解碼器的引用超出了數組的范圍，解碼器將拋出panic異常。slice也采用類似方法解析，不同的是我們將爲每個元素創建新的變量，然後將元素添加到slice的末尾。 在循環處理結構體和map每個元素時必鬚解碼一個(key value)格式的對應子列表。對於結構體，key部分對於成員的名字。和數組類似，我們使用FieldByName找到結構體對應成員的變量，然後遞歸調用read函數處理。對於map，key可能是任意類型，對元素的處理方式和slice類似，我們創建一個新的變量，然後遞歸填充它，最後將新解析到的key/value對添加到map。 ```Go func readList(lex *lexer, v reflect.Value) { switch v.Kind() { case reflect.Array: // (item ...) for i := 0; !endList(lex); i++ { read(lex, v.Index(i)) } case reflect.Slice: // (item ...) for !endList(lex) { item := reflect.New(v.Type().Elem()).Elem() read(lex, item) v.Set(reflect.Append(v, item)) } case reflect.Struct: // ((name value) ...) for !endList(lex) { lex.consume('(') if lex.token != scanner.Ident { panic(fmt.Sprintf("got token %q, want field name", lex.text())) } name := lex.text() lex.next() read(lex, v.FieldByName(name)) lex.consume(')') } case reflect.Map: // ((key value) ...) v.Set(reflect.MakeMap(v.Type())) for !endList(lex) { lex.consume('(') key := reflect.New(v.Type().Key()).Elem() read(lex, key) value := reflect.New(v.Type().Elem()).Elem() read(lex, value) v.SetMapIndex(key, value) lex.consume(')') } default: panic(fmt.Sprintf("cannot decode list into %v", v.Type())) } } func endList(lex *lexer) bool { switch lex.token { case scanner.EOF: panic("end of file") case ')': return true } return false } ``` 最後，我們將解析器包裝爲導出的Unmarshal解碼函數，隱藏了一些初始化和清理等邊緣處理。內部解析器以panic的方式拋出錯誤，但是Unmarshal函數通過在defer語句調用recover函數來捕獲內部panic（§5.10），然後返迴一個對panic對應的錯誤信息。 ```Go // Unmarshal parses S-expression data and populates the variable // whose address is in the non-nil pointer out. func Unmarshal(data []byte, out interface{}) (err error) { lex := &lexer{scan: scanner.Scanner{Mode: scanner.GoTokens}} lex.scan.Init(bytes.NewReader(data)) lex.next() // get the first token defer func() { // NOTE: this is not an example of ideal error handling. if x := recover(); x != nil { err = fmt.Errorf("error at %s: %v", lex.scan.Position, x) } }() read(lex, reflect.ValueOf(out).Elem()) return nil } ``` 生産實現不應該對任何輸入問題都用panic形式報告，而且應該報告一些錯誤相關的信息，例如出現錯誤輸入的行號和位置等。盡管如此，我們希望通過這個例子來展示類似encoding/json等包底層代碼的實現思路，以及如何使用反射機製來填充數據結構。 **練習 12.8：** sexpr.Unmarshal函數和json.Unmarshal一樣，都要求在解碼前輸入完整的字節slice。定義一個和json.Decoder類似的sexpr.Decoder類型，支持從一個io.Reader流解碼。脩改sexpr.Unmarshal函數，使用這個新的類型實現。 **練習 12.9：** 編寫一個基於標記的API用於解碼S表達式，參考xml.Decoder（7.14）的風格。你將需要五種類型的標記：Symbol、String、Int、StartList和EndList。 **練習 12.10：** 擴展sexpr.Unmarshal函數，支持布爾型、浮點數和interface類型的解碼，使用 **練習 12.3：** 的方案。（提示：要解碼接口，你需要將name映射到每個支持類型的reflect.Type。）

## 12.5. 通過reflect.Value脩改值 到目前爲止，反射還隻是程序中變量的另一種訪問方式。然而，在本節中我們將重點討論如果通過反射機製來脩改變量。 迴想一下，Go語言中類似x、x.f[1]和*p形式的表達式都可以表示變量，但是其它如x + 1和f(2)則不是變量。一個變量就是一個可尋址的內存空間，里面存儲了一個值，併且存儲的值可以通過內存地址來更新。 對於reflect.Values也有類似的區别。有一些reflect.Values是可取地址的；其它一些則不可以。考慮以下的聲明語句： ```Go x := 2 // value type variable? a := reflect.ValueOf(2) // 2 int no b := reflect.ValueOf(x) // 2 int no c := reflect.ValueOf(&x) // &x *int no d := c.Elem() // 2 int yes (x) ``` 其中a對應的變量則不可取地址。因爲a中的值僅僅是整數2的拷貝副本。b中的值也同樣不可取地址。c中的值還是不可取地址，它隻是一個指針`&x`的拷貝。實際上，所有通過reflect.ValueOf(x)返迴的reflect.Value都是不可取地址的。但是對於d，它是c的解引用方式生成的，指向另一個變量，因此是可取地址的。我們可以通過調用reflect.ValueOf(&x).Elem()，來獲取任意變量x對應的可取地址的Value。 我們可以通過調用reflect.Value的CanAddr方法來判斷其是否可以被取地址： ```Go fmt.Println(a.CanAddr()) // "false" fmt.Println(b.CanAddr()) // "false" fmt.Println(c.CanAddr()) // "false" fmt.Println(d.CanAddr()) // "true" ``` 每當我們通過指針間接地獲取的reflect.Value都是可取地址的，卽使開始的是一個不可取地址的Value。在反射機製中，所有關於是否支持取地址的規則都是類似的。例如，slice的索引表達式e[i]將隱式地包含一個指針，它就是可取地址的，卽使開始的e表達式不支持也沒有關繫。以此類推，reflect.ValueOf(e).Index(i)對於的值也是可取地址的，卽使原始的reflect.ValueOf(e)不支持也沒有關繫。 要從變量對應的可取地址的reflect.Value來訪問變量需要三個步驟。第一步是調用Addr()方法，它返迴一個Value，里面保存了指向變量的指針。然後是在Value上調用Interface()方法，也就是返迴一個interface{}，里面通用包含指向變量的指針。最後，如果我們知道變量的類型，我們可以使用類型的斷言機製將得到的interface{}類型的接口強製環爲普通的類型指針。這樣我們就可以通過這個普通指針來更新變量了： ```Go x := 2 d := reflect.ValueOf(&x).Elem() // d refers to the variable x px := d.Addr().Interface().(*int) // px := &x *px = 3 // x = 3 fmt.Println(x) // "3" ``` 或者，不使用指針，而是通過調用可取地址的reflect.Value的reflect.Value.Set方法來更新對於的值： ```Go d.Set(reflect.ValueOf(4)) fmt.Println(x) // "4" ``` Set方法將在運行時執行和編譯時類似的可賦值性約束的檢査。以上代碼，變量和值都是int類型，但是如果變量是int64類型，那麽程序將拋出一個panic異常，所以關鍵問題是要確保改類型的變量可以接受對應的值： ```Go d.Set(reflect.ValueOf(int64(5))) // panic: int64 is not assignable to int ``` 通用對一個不可取地址的reflect.Value調用Set方法也會導致panic異常： ```Go x := 2 b := reflect.ValueOf(x) b.Set(reflect.ValueOf(3)) // panic: Set using unaddressable value ``` 這里有很多用於基本數據類型的Set方法：SetInt、SetUint、SetString和SetFloat等。 ```Go d := reflect.ValueOf(&x).Elem() d.SetInt(3) fmt.Println(x) // "3" ``` 從某種程度上説，這些Set方法總是盡可能地完成任務。以SetInt爲例，隻要變量是某種類型的有符號整數就可以工作，卽使是一些命名的類型，隻要底層數據類型是有符號整數就可以，而且如果對於變量類型值太大的話會被自動截斷。但需要謹慎的是：對於一個引用interface{}類型的reflect.Value調用SetInt會導致panic異常，卽使那個interface{}變量對於整數類型也不行。 ```Go x := 1 rx := reflect.ValueOf(&x).Elem() rx.SetInt(2) // OK, x = 2 rx.Set(reflect.ValueOf(3)) // OK, x = 3 rx.SetString("hello") // panic: string is not assignable to int rx.Set(reflect.ValueOf("hello")) // panic: string is not assignable to int var y interface{} ry := reflect.ValueOf(&y).Elem() ry.SetInt(2) // panic: SetInt called on interface Value ry.Set(reflect.ValueOf(3)) // OK, y = int(3) ry.SetString("hello") // panic: SetString called on interface Value ry.Set(reflect.ValueOf("hello")) // OK, y = "hello" ``` 當我們用Display顯示os.Stdout結構時，我們發現反射可以越過Go語言的導出規則的限製讀取結構體中未導出的成員，比如在類Unix繫統上os.File結構體中的fd int成員。然而，利用反射機製併不能脩改這些未導出的成員： ```Go stdout := reflect.ValueOf(os.Stdout).Elem() // *os.Stdout, an os.File var fmt.Println(stdout.Type()) // "os.File" fd := stdout.FieldByName("fd") fmt.Println(fd.Int()) // "1" fd.SetInt(2) // panic: unexported field ``` 一個可取地址的reflect.Value會記録一個結構體成員是否是未導出成員，如果是的話則拒絶脩改操作。因此，CanAddr方法併不能正確反映一個變量是否是可以被脩改的。另一個相關的方法CanSet是用於檢査對應的reflect.Value是否是可取地址併可被脩改的： ```Go fmt.Println(fd.CanAddr(), fd.CanSet()) // "true false" ```

## 12.4. 示例: 編碼S表達式 Display是一個用於顯示結構化數據的調試工具，但是它併不能將任意的Go語言對象編碼爲通用消息然後用於進程間通信。 正如我們在4.5節中中看到的，Go語言的標準庫支持了包括JSON、XML和ASN.1等多種編碼格式。還有另一種依然被廣泛使用的格式是S表達式格式，采用類似Lisp語言的語法。但是和其他編碼格式不同的是，Go語言自帶的標準庫併不支持S表達式，主要是因爲它沒有一個公認的標準規范。 在本節中，我們將定義一個包用於將Go語言的對象編碼爲S表達式格式，它支持以下結構： ``` 42 integer "hello" string (with Go-style quotation) foo symbol (an unquoted name) (1 2 3) list (zero or more items enclosed in parentheses) ``` 布爾型習慣上使用t符號表示true，空列表或nil符號表示false，但是爲了簡單起見，我們暫時忽略布爾類型。同時忽略的還有chan管道和函數，因爲通過反射併無法知道它們的確切狀態。我們忽略的還浮點數、複數和interface。支持它們是練習12.3的任務。 我們將Go語言的類型編碼爲S表達式的方法如下。整數和字符串以自然的方式編碼。Nil值編碼爲nil符號。數組和slice被編碼爲一個列表。 結構體被編碼爲成員對象的列表，每個成員對象對應一個個僅有兩個元素的子列表，其中子列表的第一個元素是成員的名字，子列表的第二個元素是成員的值。Map被編碼爲鍵值對的列表。傳統上，S表達式使用點狀符號列表(key . value)結構來表示key/value對，而不是用一個含雙元素的列表，不過爲了簡單我們忽略了點狀符號列表。 編碼是由一個encode遞歸函數完成，如下所示。它的結構本質上和前面的Display函數類似： ```Go gopl.io/ch12/sexpr func encode(buf *bytes.Buffer, v reflect.Value) error { switch v.Kind() { case reflect.Invalid: buf.WriteString("nil") case reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.Int64: fmt.Fprintf(buf, "%d", v.Int()) case reflect.Uint, reflect.Uint8, reflect.Uint16, reflect.Uint32, reflect.Uint64, reflect.Uintptr: fmt.Fprintf(buf, "%d", v.Uint()) case reflect.String: fmt.Fprintf(buf, "%q", v.String()) case reflect.Ptr: return encode(buf, v.Elem()) case reflect.Array, reflect.Slice: // (value ...) buf.WriteByte('(') for i := 0; i < v.Len(); i++ { if i > 0 { buf.WriteByte(' ') } if err := encode(buf, v.Index(i)); err != nil { return err } } buf.WriteByte(')') case reflect.Struct: // ((name value) ...) buf.WriteByte('(') for i := 0; i < v.NumField(); i++ { if i > 0 { buf.WriteByte(' ') } fmt.Fprintf(buf, "(%s ", v.Type().Field(i).Name) if err := encode(buf, v.Field(i)); err != nil { return err } buf.WriteByte(')') } buf.WriteByte(')') case reflect.Map: // ((key value) ...) buf.WriteByte('(') for i, key := range v.MapKeys() { if i > 0 { buf.WriteByte(' ') } buf.WriteByte('(') if err := encode(buf, key); err != nil { return err } buf.WriteByte(' ') if err := encode(buf, v.MapIndex(key)); err != nil { return err } buf.WriteByte(')') } buf.WriteByte(')') default: // float, complex, bool, chan, func, interface return fmt.Errorf("unsupported type: %s", v.Type()) } return nil } ``` Marshal函數是對encode的保證，以保持和encoding/...下其它包有着相似的API： ```Go // Marshal encodes a Go value in S-expression form. func Marshal(v interface{}) ([]byte, error) { var buf bytes.Buffer if err := encode(&buf, reflect.ValueOf(v)); err != nil { return nil, err } return buf.Bytes(), nil } ``` 下面是Marshal對12.3節的strangelove變量編碼後的結果： ``` ((Title "Dr. Strangelove") (Subtitle "How I Learned to Stop Worrying and Lo ve the Bomb") (Year 1964) (Actor (("Grp. Capt. Lionel Mandrake" "Peter Sell ers") ("Pres. Merkin Muffley" "Peter Sellers") ("Gen. Buck Turgidson" "Geor ge C. Scott") ("Brig. Gen. Jack D. Ripper" "Sterling Hayden") ("Maj. T.J. \ "King\" Kong" "Slim Pickens") ("Dr. Strangelove" "Peter Sellers"))) (Oscars ("Best Actor (Nomin.)" "Best Adapted Screenplay (Nomin.)" "Best Director (N omin.)" "Best Picture (Nomin.)")) (Sequel nil)) ``` 整個輸出編碼爲一行中以減少輸出的大小，但是也很難閲讀。這里有一個對S表達式格式化的約定。編寫一個S表達式的格式化函數將作爲一個具有挑戰性的練習任務；不過 http://gopl.io 也提供了一個簡單的版本。 ``` ((Title "Dr. Strangelove") (Subtitle "How I Learned to Stop Worrying and Love the Bomb") (Year 1964) (Actor (("Grp. Capt. Lionel Mandrake" "Peter Sellers") ("Pres. Merkin Muffley" "Peter Sellers") ("Gen. Buck Turgidson" "George C. Scott") ("Brig. Gen. Jack D. Ripper" "Sterling Hayden") ("Maj. T.J. \"King\" Kong" "Slim Pickens") ("Dr. Strangelove" "Peter Sellers"))) (Oscars ("Best Actor (Nomin.)" "Best Adapted Screenplay (Nomin.)" "Best Director (Nomin.)" "Best Picture (Nomin.)")) (Sequel nil)) ``` 和fmt.Print、json.Marshal、Display函數類似，sexpr.Marshal函數處理帶環的數據結構也會陷入死循環。 在12.6節中，我們將給出S表達式解碼器的實現步驟，但是在那之前，我們還需要先了解如果通過反射技術來更新程序的變量。 **練習 12.3：** 實現encode函數缺少的分支。將布爾類型編碼爲t和nil，浮點數編碼爲Go語言的格式，複數1+2i編碼爲#C(1.0 2.0)格式。接口編碼爲類型名和值對，例如("[]int" (1 2 3))，但是這個形式可能會造成歧義：reflect.Type.String方法對於不同的類型可能返迴相同的結果。 **練習 12.4：** 脩改encode函數，以上面的格式化形式輸出S表達式。 **練習 12.5：** 脩改encode函數，用JSON格式代替S表達式格式。然後使用標準庫提供的json.Unmarshal解碼器來驗證函數是正確的。 **練習 12.6：** 脩改encode，作爲一個優化，忽略對是零值對象的編碼。 **練習 12.7：** 創建一個基於流式的API，用於S表達式的解碼，和json.Decoder(§4.5)函數功能類似。

## 12.3. Display遞歸打印 接下來，讓我們看看如何改善聚合數據類型的顯示。我們併不想完全剋隆一個fmt.Sprint函數，我們隻是像構建一個用於調式用的Display函數，給定一個聚合類型x，打印這個值對應的完整的結構，同時記録每個發現的每個元素的路徑。讓我們從一個例子開始。 ```Go e, _ := eval.Parse("sqrt(A / pi)") Display("e", e) ``` 在上面的調用中，傳入Display函數的參數是在7.9節一個表達式求值函數返迴的語法樹。Display函數的輸出如下： ```Go Display e (eval.call): e.fn = "sqrt" e.args[0].type = eval.binary e.args[0].value.op = 47 e.args[0].value.x.type = eval.Var e.args[0].value.x.value = "A" e.args[0].value.y.type = eval.Var e.args[0].value.y.value = "pi" ``` 在可能的情況下，你應該避免在一個包中暴露和反射相關的接口。我們將定義一個未導出的display函數用於遞歸處理工作，導出的是Display函數，它隻是display函數簡單的包裝以接受interface{}類型的參數： ```Go gopl.io/ch12/display func Display(name string, x interface{}) { fmt.Printf("Display %s (%T):\n", name, x) display(name, reflect.ValueOf(x)) } ``` 在display函數中，我們使用了前面定義的打印基礎類型——基本類型、函數和chan等——元素值的formatAtom函數，但是我們會使用reflect.Value的方法來遞歸顯示聚合類型的每一個成員或元素。在遞歸下降過程中，path字符串，從最開始傳入的起始值（這里是“e”），將逐步增長以表示如何達到當前值（例如“e.args[0].value”）。 因爲我們不再模擬fmt.Sprint函數，我們將直接使用fmt包來簡化我們的例子實現。 ```Go func display(path string, v reflect.Value) { switch v.Kind() { case reflect.Invalid: fmt.Printf("%s = invalid\n", path) case reflect.Slice, reflect.Array: for i := 0; i < v.Len(); i++ { display(fmt.Sprintf("%s[%d]", path, i), v.Index(i)) } case reflect.Struct: for i := 0; i < v.NumField(); i++ { fieldPath := fmt.Sprintf("%s.%s", path, v.Type().Field(i).Name) display(fieldPath, v.Field(i)) } case reflect.Map: for _, key := range v.MapKeys() { display(fmt.Sprintf("%s[%s]", path, formatAtom(key)), v.MapIndex(key)) } case reflect.Ptr: if v.IsNil() { fmt.Printf("%s = nil\n", path) } else { display(fmt.Sprintf("(*%s)", path), v.Elem()) } case reflect.Interface: if v.IsNil() { fmt.Printf("%s = nil\n", path) } else { fmt.Printf("%s.type = %s\n", path, v.Elem().Type()) display(path+".value", v.Elem()) } default: // basic types, channels, funcs fmt.Printf("%s = %s\n", path, formatAtom(v)) } } ``` 讓我們針對不同類型分别討論。 **Slice和數組：** 兩種的處理邏輯是一樣的。Len方法返迴slice或數組值中的元素個數，Index(i)活動索引i對應的元素，返迴的也是一個reflect.Value類型的值；如果索引i超出范圍的話將導致panic異常，這些行爲和數組或slice類型內建的len(a)和a[i]等操作類似。display針對序列中的每個元素遞歸調用自身處理，我們通過在遞歸處理時向path附加“[i]”來表示訪問路徑。 雖然reflect.Value類型帶有很多方法，但是隻有少數的方法對任意值都是可以安全調用的。例如，Index方法隻能對Slice、數組或字符串類型的值調用，其它類型如果調用將導致panic異常。 **結構體：** NumField方法報告結構體中成員的數量，Field(i)以reflect.Value類型返迴第i個成員的值。成員列表包含了匿名成員在內的全部成員。通過在path添加“.f”來表示成員路徑，我們必鬚獲得結構體對應的reflect.Type類型信息，包含結構體類型和第i個成員的名字。 **Maps:** MapKeys方法返迴一個reflect.Value類型的slice，每一個都對應map的可以。和往常一樣，遍歷map時順序是隨機的。MapIndex(key)返迴map中key對應的value。我們向path添加“[key]”來表示訪問路徑。（我們這里有一個未完成的工作。其實map的key的類型併不局限於formatAtom能完美處理的類型；數組、結構體和接口都可以作爲map的key。針對這種類型，完善key的顯示信息是練習12.1的任務。） **指針：** Elem方法返迴指針指向的變量，還是reflect.Value類型。技術指針是nil，這個操作也是安全的，在這種情況下指針是Invalid無效類型，但是我們可以用IsNil方法來顯式地測試一個空指針，這樣我們可以打印更合適的信息。我們在path前面添加“*”，併用括弧包含以避免歧義。 **接口：** 再一次，我們使用IsNil方法來測試接口是否是nil，如果不是，我們可以調用v.Elem()來獲取接口對應的動態值，併且打印對應的類型和值。 現在我們的Display函數總算完工了，讓我們看看它的表現吧。下面的Movie類型是在4.5節的電影類型上演變來的： ```Go type Movie struct { Title, Subtitle string Year int Color bool Actor map[string]string Oscars []string Sequel *string } ``` 讓我們聲明一個該類型的變量，然後看看Display函數如何顯示它： ```Go strangelove := Movie{ Title: "Dr. Strangelove", Subtitle: "How I Learned to Stop Worrying and Love the Bomb", Year: 1964, Color: false, Actor: map[string]string{ "Dr. Strangelove": "Peter Sellers", "Grp. Capt. Lionel Mandrake": "Peter Sellers", "Pres. Merkin Muffley": "Peter Sellers", "Gen. Buck Turgidson": "George C. Scott", "Brig. Gen. Jack D. Ripper": "Sterling Hayden", `Maj. T.J. "King" Kong`: "Slim Pickens", }, Oscars: []string{ "Best Actor (Nomin.)", "Best Adapted Screenplay (Nomin.)", "Best Director (Nomin.)", "Best Picture (Nomin.)", }, } ``` Display("strangelove", strangelove)調用將顯示（strangelove電影對應的中文名是《奇愛博士》）： ```Go Display strangelove (display.Movie): strangelove.Title = "Dr. Strangelove" strangelove.Subtitle = "How I Learned to Stop Worrying and Love the Bomb" strangelove.Year = 1964 strangelove.Color = false strangelove.Actor["Gen. Buck Turgidson"] = "George C. Scott" strangelove.Actor["Brig. Gen. Jack D. Ripper"] = "Sterling Hayden" strangelove.Actor["Maj. T.J. \"King\" Kong"] = "Slim Pickens" strangelove.Actor["Dr. Strangelove"] = "Peter Sellers" strangelove.Actor["Grp. Capt. Lionel Mandrake"] = "Peter Sellers" strangelove.Actor["Pres. Merkin Muffley"] = "Peter Sellers" strangelove.Oscars[0] = "Best Actor (Nomin.)" strangelove.Oscars[1] = "Best Adapted Screenplay (Nomin.)" strangelove.Oscars[2] = "Best Director (Nomin.)" strangelove.Oscars[3] = "Best Picture (Nomin.)" strangelove.Sequel = nil ``` 我們也可以使用Display函數來顯示標準庫中類型的內部結構，例如`*os.File`類型： ```Go Display("os.Stderr", os.Stderr) // Output: // Display os.Stderr (*os.File): // (*(*os.Stderr).file).fd = 2 // (*(*os.Stderr).file).name = "/dev/stderr" // (*(*os.Stderr).file).nepipe = 0 ``` 要註意的是，結構體中未導出的成員對反射也是可見的。需要當心的是這個例子的輸出在不同操作繫統上可能是不同的，併且隨着標準庫的發展也可能導致結果不同。（這也是將這些成員定義爲私有成員的原因之一！）我們深圳可以用Display函數來顯示reflect.Value，來査看`*os.File`類型的內部表示方式。`Display("rV", reflect.ValueOf(os.Stderr))`調用的輸出如下，當然不同環境得到的結果可能有差異： ```Go Display rV (reflect.Value): (*rV.typ).size = 8 (*rV.typ).hash = 871609668 (*rV.typ).align = 8 (*rV.typ).fieldAlign = 8 (*rV.typ).kind = 22 (*(*rV.typ).string) = "*os.File" (*(*(*rV.typ).uncommonType).methods[0].name) = "Chdir" (*(*(*(*rV.typ).uncommonType).methods[0].mtyp).string) = "func() error" (*(*(*(*rV.typ).uncommonType).methods[0].typ).string) = "func(*os.File) error" ... ``` 觀察下面兩個例子的區别： ```Go var i interface{} = 3 Display("i", i) // Output: // Display i (int): // i = 3 Display("&i", &i) // Output: // Display &i (*interface {}): // (*&i).type = int // (*&i).value = 3 ``` 在第一個例子中，Display函數將調用reflect.ValueOf(i)，它返迴一個Int類型的值。正如我們在12.2節中提到的，reflect.ValueOf總是返迴一個值的具體類型，因爲它是從一個接口值提取的內容。 在第二個例子中，Display函數調用的是reflect.ValueOf(&i)，它返迴一個指向i的指針，對應Ptr類型。在switch的Ptr分支中，通過調用Elem來返迴這個值，返迴一個Value來表示i，對應Interface類型。一個間接獲得的Value，就像這一個，可能代表任意類型的值，包括接口類型。內部的display函數遞歸調用自身，這次它將打印接口的動態類型和值。 目前的實現，Display如果顯示一個帶環的數據結構將會陷入死循環，例如首位項鏈的鏈表： ```Go // a struct that points to itself type Cycle struct{ Value int; Tail *Cycle } var c Cycle c = Cycle{42, &c} Display("c", c) ``` Display會永遠不停地進行深度遞歸打印： ```Go Display c (display.Cycle): c.Value = 42 (*c.Tail).Value = 42 (*(*c.Tail).Tail).Value = 42 (*(*(*c.Tail).Tail).Tail).Value = 42 ...ad infinitum... ``` 許多Go語言程序都包含了一些循環的數據結果。Display支持這類帶環的數據結構是比較棘手的，需要增加一個額外的記録訪問的路徑；代價是昂貴的。一般的解決方案是采用不安全的語言特性，我們將在13.3節看到具體的解決方案。 帶環的數據結構很少會對fmt.Sprint函數造成問題，因爲它很少嚐試打印完整的數據結構。例如，當它遇到一個指針的時候，它隻是簡單第打印指針的數值。雖然，在打印包含自身的slice或map時可能遇到睏難，但是不保證處理這種是罕見情況卻可以避免額外的麻煩。 **練習 12.1：** 擴展Displayhans，以便它可以顯示包含以結構體或數組作爲map的key類型的值。 **練習 12.2：** 增強display函數的穩健性，通過記録邊界的步數來確保在超出一定限製前放棄遞歸。（在13.3節，我們會看到另一種探測數據結構是否存在環的技術。）

## 12.2. reflect.Type和reflect.Value 反射是由 reflect 包提供支持. 它定義了兩個重要的類型, Type 和 Value. 一個 Type 表示一個Go類型. 它是一個接口, 有許多方法來區分類型和檢査它們的組件, 例如一個結構體的成員或一個函數的參數等. 唯一能反映 reflect.Type 實現的是接口的類型描述信息(§7.5), 同樣的實體標識了動態類型的接口值. 函數 reflect.TypeOf 接受任意的 interface{} 類型, 併返迴對應動態類型的reflect.Type: ```Go t := reflect.TypeOf(3) // a reflect.Type fmt.Println(t.String()) // "int" fmt.Println(t) // "int" ``` 其中 TypeOf(3) 調用將值 3 作爲 interface{} 類型參數傳入. 迴到 7.5節 的將一個具體的值轉爲接口類型會有一個隱式的接口轉換操作, 它會創建一個包含兩個信息的接口值: 操作數的動態類型(這里是int)和它的動態的值(這里是3). 因爲 reflect.TypeOf 返迴的是一個動態類型的接口值, 它總是返迴具體的類型. 因此, 下面的代碼將打印 "*os.File" 而不是 "io.Writer". 稍後, 我們將看到 reflect.Type 是具有識别接口類型的表達方式功能的. ```Go var w io.Writer = os.Stdout fmt.Println(reflect.TypeOf(w)) // "*os.File" ``` 要註意的是 reflect.Type 接口是滿足 fmt.Stringer 接口的. 因爲打印動態類型值對於調試和日誌是有幫助的, fmt.Printf 提供了一個簡短的 %T 標誌參數, 內部使用 reflect.TypeOf 的結果輸出: ```Go fmt.Printf("%T\n", 3) // "int" ``` reflect 包中另一個重要的類型是 Value. 一個 reflect.Value 可以持有一個任意類型的值. 函數 reflect.ValueOf 接受任意的 interface{} 類型, 併返迴對應動態類型的reflect.Value. 和 reflect.TypeOf 類似, reflect.ValueOf 返迴的結果也是對於具體的類型, 但是 reflect.Value 也可以持有一個接口值. ```Go v := reflect.ValueOf(3) // a reflect.Value fmt.Println(v) // "3" fmt.Printf("%v\n", v) // "3" fmt.Println(v.String()) // NOTE: "" ``` 和 reflect.Type 類似, reflect.Value 也滿足 fmt.Stringer 接口, 但是除非 Value 持有的是字符串, 否則 String 隻是返迴具體的類型. 相同, 使用 fmt 包的 %v 標誌參數, 將使用 reflect.Values 的結果格式化. 調用 Value 的 Type 方法將返迴具體類型所對應的 reflect.Type: ```Go t := v.Type() // a reflect.Type fmt.Println(t.String()) // "int" ``` 逆操作是調用 reflect.ValueOf 對應的 reflect.Value.Interface 方法. 它返迴一個 interface{} 類型表示 reflect.Value 對應類型的具體值: ```Go v := reflect.ValueOf(3) // a reflect.Value x := v.Interface() // an interface{} i := x.(int) // an int fmt.Printf("%d\n", i) // "3" ``` 一個 reflect.Value 和 interface{} 都能保存任意的值. 所不同的是, 一個空的接口隱藏了值對應的表示方式和所有的公開的方法, 因此隻有我們知道具體的動態類型才能使用類型斷言來訪問內部的值(就像上面那樣), 對於內部值併沒有特别可做的事情. 相比之下, 一個 Value 則有很多方法來檢査其內容, 無論它的具體類型是什麽. 讓我們再次嚐試實現我們的格式化函數 format.Any. 我們使用 reflect.Value 的 Kind 方法來替代之前的類型 switch. 雖然還是有無窮多的類型, 但是它們的kinds類型卻是有限的: Bool, String 和 所有數字類型的基礎類型; Array 和 Struct 對應的聚合類型; Chan, Func, Ptr, Slice, 和 Map 對應的引用類似; 接口類型; 還有表示空值的無效類型. (空的 reflect.Value 對應 Invalid 無效類型.) ```Go gopl.io/ch12/format package format import ( "reflect" "strconv" ) // Any formats any value as a string. func Any(value interface{}) string { return formatAtom(reflect.ValueOf(value)) } // formatAtom formats a value without inspecting its internal structure. func formatAtom(v reflect.Value) string { switch v.Kind() { case reflect.Invalid: return "invalid" case reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.Int64: return strconv.FormatInt(v.Int(), 10) case reflect.Uint, reflect.Uint8, reflect.Uint16, reflect.Uint32, reflect.Uint64, reflect.Uintptr: return strconv.FormatUint(v.Uint(), 10) // ...floating-point and complex cases omitted for brevity... case reflect.Bool: return strconv.FormatBool(v.Bool()) case reflect.String: return strconv.Quote(v.String()) case reflect.Chan, reflect.Func, reflect.Ptr, reflect.Slice, reflect.Map: return v.Type().String() + " 0x" + strconv.FormatUint(uint64(v.Pointer()), 16) default: // reflect.Array, reflect.Struct, reflect.Interface return v.Type().String() + " value" } } ``` 到目前未知, 我們的函數將每個值視作一個不可分割沒有內部結構的, 因此它叫 formatAtom. 對於聚合類型(結構體和數組)個接口隻是打印類型的值, 對於引用類型(channels, functions, pointers, slices, 和 maps), 它十六進製打印類型的引用地址. 雖然還不夠理想, 但是依然是一個重大的進步, 併且 Kind 隻關心底層表示, format.Any 也支持新命名的類型. 例如: ```Go var x int64 = 1 var d time.Duration = 1 * time.Nanosecond fmt.Println(format.Any(x)) // "1" fmt.Println(format.Any(d)) // "1" fmt.Println(format.Any([]int64{x})) // "[]int64 0x8202b87b0" fmt.Println(format.Any([]time.Duration{d})) // "[]time.Duration 0x8202b87e0" ```

## 12.1. 爲何需要反射? 有時候我們需要編寫一個函數能夠處理一類併不滿足普通公共接口的類型的值, 也可能它們併沒有確定的表示方式, 或者在我們設計該函數的時候還這些類型可能還不存在, 各種情況都有可能. 一個大家熟悉的例子是 fmt.Fprintf 函數提供的字符串格式化處理邏輯, 它可以用例對任意類型的值格式化打印, 甚至是用戶自定義的類型. 讓我們來嚐試實現一個類似功能的函數. 簡單起見, 我們的函數隻接收一個參數, 然後返迴和 fmt.Sprint 類似的格式化後的字符串, 我們的函數名也叫 Sprint. 我們使用了 switch 分支首先來測試輸入參數是否實現了 String 方法, 如果是的話就使用該方法. 然後繼續增加測試分支, 檢査是否是每個基於 string, int, bool 等基礎類型的動態類型, 併在每種情況下執行適當的格式化操作. ```Go func Sprint(x interface{}) string { type stringer interface { String() string } switch x := x.(type) { case stringer: return x.String() case string: return x case int: return strconv.Itoa(x) // ...similar cases for int16, uint32, and so on... case bool: if x { return "true" } return "false" default: // array, chan, func, map, pointer, slice, struct return "???" } } ``` 但是我們如何處理其它類似 []float64, map[string][]string 等類型呢? 我們當然可以添加更多的測試分支, 但是這些組合類型的數目基本是無窮的. 還有如何處理 url.Values 等命令的類型呢? 雖然類型分支可以識别出底層的基礎類型是 map[string][]string, 但是它併不匹配 url.Values 類型, 因爲這是兩種不同的類型, 而且 switch 分支也不可能包含每個類似 url.Values 的類型, 這會導致對這些庫的依賴. 沒有一種方法來檢査未知類型的表示方式, 我們被卡住了. 這就是我們爲何需要反射的原因.

# 第十二章 反射 Go提供了一種機製在運行時更新變量和檢査它們的值, 調用它們的方法, 和它們支持的內在操作, 但是在編譯時併不知道這些變量的類型. 這種機製被稱爲反射. 反射也可以讓我們將類型本身作爲第一類的值類型處理. 在本章, 我們將探討Go語言的反射特性, 看看它可以給語言增加哪些表達力, 以及在兩個至關重要的API是如何用反射機製的: 一個是 fmt 包提供的字符串格式功能, 另一個是類似 encoding/json 和 encoding/xml 提供的針對特定協議的編解碼功能. 對於我們在4.6節中看到過的 text/template 和 html/template 包, 它們的實現也是依賴反射技術的. 然後, 反射是一個複雜的內省技術, 而應該隨意使用, 因此, 盡管上面這些包都是用反射技術實現的, 但是它們自己的API都沒有公開反射相關的接口.

## 11.6. 示例函數 第三種 `go test` 特别處理的函數是示例函數, 以 Example 爲函數名開頭. 示例函數沒有函數參數和返迴值. 下面是 IsPalindrome 函數對應的示例函數: ```Go func ExampleIsPalindrome() { fmt.Println(IsPalindrome("A man, a plan, a canal: Panama")) fmt.Println(IsPalindrome("palindrome")) // Output: // true // false } ``` 示例函數有三個用處. 最主要的一個是用於文檔: 一個包的例子可以更簡潔直觀的方式來演示函數的用法, 會文字描述會更直接易懂, 特别是作爲一個提醒或快速參考時. 一個例子函數也可以方便展示屬於同一個接口的幾種類型或函數直接的關繫, 所有的文檔都必鬚關聯到一個地方, 就像一個類型或函數聲明都統一到包一樣. 同時, 示例函數和註釋併不一樣, 示例函數是完整眞是的Go代碼, 需要介紹編譯器的編譯時檢査, 這樣可以保證示例代碼不會腐爛成不能使用的舊代碼. 根據示例函數的後綴名部分, godoc 的web文檔會將一個示例函數關聯到某個具體函數或包本身, 因此 ExampleIsPalindrome 示例函數將是 IsPalindrome 函數文檔的一部分, Example 示例函數將是包文檔的一部分. 示例文檔的第二個用處是在 `go test` 執行測試的時候也運行示例函數測試. 如果示例函數內含有類似上面例子中的 `/ Output:` 這樣的註釋, 那麽測試工具會執行這個示例函數, 然後檢測這個示例函數的標準輸出和註釋是否匹配. 示例函數的第三個目的提供一個眞實的演練場. golang.org 是由 dogoc 提供的服務, 它使用了 Go Playground 技術讓用戶可以在瀏覽器中在線編輯和運行每個示例函數, 就像 圖 11.4 所示的那樣. 這通常是學習函數使用或Go語言特性的最快方式.  本書最後的兩掌是討論 reflect 和 unsafe 包, 一般的Go用於很少需要使用它們. 因此, 如果你還沒有寫過任何眞是的Go程序的話, 現在可以忽略剩餘部分而直接編碼了.

## 11.5. 剖析 測量基準對於衡量特定操作的性能是有幫助的, 但是, 當我們視圖讓程序跑的更快的時候, 我們通常併不知道從哪里開始優化. 每個碼農都應該知道 Donald Knuth 在1974年的 ‘‘Structured Programming with go to Statements’’ 上所説的格言. 雖然經常被解讀爲不重視性能的意思, 但是從原文我們可以看到不同的含義: > 毫無疑問, 效率會導致各種濫用. 程序員需要浪費大量的時間思考, 或者擔心, 被部分程序的速度所榦擾, 實際上這些嚐試提陞效率的行爲可能産生強烈的負面影響, 特别是當調試和維護的時候. 我們不應該過度糾結於細節的優化, 應該説約97%的場景: 過早的優化是萬惡之源. > > 我們當然不應該放棄那關鍵的3%的機會. 一個好的程序員不會因爲這個理由而滿足, 他們會明智地觀察和識别哪些是關鍵的代碼; 但是隻有在關鍵代碼已經被確認的前提下才會進行優化. 對於判斷哪些部分是關鍵代碼是經常容易犯經驗性錯誤的地方, 因此程序員普通使用的測量工具, 使得他們的直覺很不靠譜. 當我們想仔細觀察我們程序的運行速度的時候, 最好的技術是如何識别關鍵代碼. 自動化的剖析技術是基於程序執行期間一些抽樣數據, 然後推斷後面的執行狀態; 最終産生一個運行時間的統計數據文件. Go語言支持多種類型的剖析性能分析, 每一種關註不同的方面, 但它們都涉及到每個采樣記録的感興趣的一繫列事件消息, 每個事件都包含函數調用時函數調用堆棧的信息. 內建的 `go test` 工具對幾種分析方式都提供了支持. CPU分析文件標識了函數執行時所需要的CPU時間. 當前運行的繫統線程在每隔幾毫秒都會遇到操作繫統的中斷事件, 每次中斷時都會記録一個分析文件然後恢複正常的運行. 堆分析則記録了程序的內存使用情況. 每個內存分配操作都會觸發內部平均內存分配例程, 每個 512KB 的內存申請都會觸發一個事件. 阻塞分析則記録了goroutine最大的阻塞操作, 例如繫統調用, 管道發送和接收, 還有獲取鎖等. 分析庫會記録每個goroutine被阻塞時的相關操作. 在測試環境下隻需要一個標誌參數就可以生成各種分析文件. 當一次使用多個標誌參數時需要當心, 因爲分析操作本身也可能會影像程序的運行. ``` $ go test -cpuprofile=cpu.out $ go test -blockprofile=block.out $ go test -memprofile=mem.out ``` 對於一些非測試程序也很容易支持分析的特性, 具體的實現方式和程序是短時間運行的小工具還是長時間運行的服務會有很大不同, 因此Go的runtim運行時包提供了程序運行時控製分析特性的接口. 一旦我們已經收集到了用於分析的采樣數據, 我們就可以使用 pprof 據來分析這些數據. 這是Go工具箱自帶的一個工具, 但併不是一個日常工具, 它對應 `go tool pprof` 命令. 該命令有許多特性和選項, 但是最重要的有兩個, 就是生成這個概要文件的可執行程序和對於的分析日誌文件. 爲了提高分析效率和減少空間, 分析日誌本身併不包含函數的名字; 它隻包含函數對應的地址. 也就是説pprof需要和分析日誌對於的可執行程序. 雖然 `go test` 命令通常會丟棄臨時用的測試程序, 但是在啟用分析的時候會將測試程序保存爲 foo.test 文件, 其中 foo 部分對於測試包的名字. 下面的命令演示了如何生成一個CPU分析文件. 我們選擇 `net/http` 包的一個基準測試. 通常是基於一個已經確定了是關鍵代碼的部分進行基準測試. 基準測試會默認包含單元測試, 這里我們用 -run=NONE 禁止單元測試. ``` $ go test -run=NONE -bench=ClientServerParallelTLS64 \ -cpuprofile=cpu.log net/http PASS BenchmarkClientServerParallelTLS64-8 1000 3141325 ns/op 143010 B/op 1747 allocs/op ok net/http 3.395s $ go tool pprof -text -nodecount=10 ./http.test cpu.log 2570ms of 3590ms total (71.59%) Dropped 129 nodes (cum <= 17.95ms) Showing top 10 nodes out of 166 (cum >= 60ms) flat flat% sum% cum cum% 1730ms 48.19% 48.19% 1750ms 48.75% crypto/elliptic.p256ReduceDegree 230ms 6.41% 54.60% 250ms 6.96% crypto/elliptic.p256Diff 120ms 3.34% 57.94% 120ms 3.34% math/big.addMulVVW 110ms 3.06% 61.00% 110ms 3.06% syscall.Syscall 90ms 2.51% 63.51% 1130ms 31.48% crypto/elliptic.p256Square 70ms 1.95% 65.46% 120ms 3.34% runtime.scanobject 60ms 1.67% 67.13% 830ms 23.12% crypto/elliptic.p256Mul 60ms 1.67% 68.80% 190ms 5.29% math/big.nat.montgomery 50ms 1.39% 70.19% 50ms 1.39% crypto/elliptic.p256ReduceCarry 50ms 1.39% 71.59% 60ms 1.67% crypto/elliptic.p256Sum ``` 參數 `-text` 標誌參數用於指定輸出格式, 在這里每行是一個函數, 根據使用CPU的時間來排序. 其中 `-nodecount=10` 標誌參數限製了隻輸出前10行的結果. 對於嚴重的性能問題, 這個文本格式基本可以幫助査明原因了. 這個概要文件告訴我們, HTTPS基準測試中 `crypto/elliptic.p256ReduceDegree` 函數占用了將近一般的CPU資源. 相比之下, 如果一個概要文件中主要是runtime包的內存分配的函數, 那麽減少內存消耗可能是一個值得嚐試的優化策略. 對於一些更微妙的問題, 你可能需要使用 pprof 的圖形顯示功能. 這個需要安裝 GraphViz 工具, 可以從 www.graphviz.org 下載. 參數 `-web` 用於生成一個有向圖文件, 包含CPU的使用和最特點的函數等信息. 這一節我們隻是簡單看了下Go語言的分析據工具. 如果想了解更多, 可以閲讀 Go官方博客的 ‘‘Profiling Go Programs’’ 一文.

## 11.4. 基準測試 基準測試是測量一個程序在固定工作負載下的性能. 在Go語言中, 基準測試函數和普通測試函數類似, 但是以Benchmark爲前綴名, 併且帶有一個 `*testing.B` 類型的參數; `*testing.B` 除了提供和 `*testing.T` 類似的方法, 還有額外一些和性能測量相關的方法. 它還提供了一個整數N, 用於指定操作執行的循環次數. 下面是 IsPalindrome 函數的基準測試, 其中循環將執行N次. ```Go import "testing" func BenchmarkIsPalindrome(b *testing.B) { for i := 0; i < b.N; i++ { IsPalindrome("A man, a plan, a canal: Panama") } } ``` 我們用下面的命令運行基準測試. 和普通測試不同的是, 默認情況下不運行任何基準測試. 我們需要通過 `-bench` 命令行標誌參數手工指定要運行的基準測試函數. 該參數是一個正則表達式, 用於匹配要執行的基準測試函數的名字, 默認值是空的. 其中 ‘‘.’’ 模式將可以匹配所有基準測試函數, 但是這里總共隻有一個基準測試函數, 因此 和 `-bench=IsPalindrome` 參數是等價的效果. ``` $ cd $GOPATH/src/gopl.io/ch11/word2 $ go test -bench=. PASS BenchmarkIsPalindrome-8 1000000 1035 ns/op ok gopl.io/ch11/word2 2.179s ``` 基準測試名的數字後綴部分, 這里是8, 表示運行時對應的 GOMAXPROCS 的值, 這對於一些和併發相關的基準測試是重要的信息. 報告顯示每次調用 IsPalindrome 函數花費 1.035微秒, 是執行 1,000,000 次的平均時間. 因爲基準測試驅動器併不知道每個基準測試函數運行所花的時候, 它會嚐試在眞正運行基準測試前先嚐試用較小的 N 運行測試來估算基準測試函數所需要的時間, 然後推斷一個較大的時間保證穩定的測量結果. 循環在基準測試函數內實現, 而不是放在基準測試框架內實現, 這樣可以讓每個基準測試函數有機會在循環啟動前執行初始化代碼, 這樣併不會顯著影響每次迭代的平均運行時間. 如果還是擔心初始化代碼部分對測量時間帶來榦擾, 那麽可以通過 testing.B 參數的方法來臨時關閉或重置計時器, 不過這些一般很少會用到. 現在我們有了一個基準測試和普通測試, 我們可以很容易測試新的讓程序運行更快的想法. 也許最明顯的優化是在 IsPalindrome 函數中第二個循環的停止檢査, 這樣可以避免每個比較都做兩次: ```Go n := len(letters)/2 for i := 0; i < n; i++ { if letters[i] != letters[len(letters)-1-i] { return false } } return true ``` 不過很多情況下, 一個明顯的優化併不一定就能代碼預期的效果. 這個改進在基準測試中值帶來了 4% 的性能提陞. ``` $ go test -bench=. PASS BenchmarkIsPalindrome-8 1000000 992 ns/op ok gopl.io/ch11/word2 2.093s ``` 另一個改進想法是在開始爲每個字符預先分配一個足夠大的數組, 這樣就可以避免在 append 調用時可能會導致內存的多次重新分配. 聲明一個 letters 數組變量, 併指定合適的大小, 像這樣, ```Go letters := make([]rune, 0, len(s)) for _, r := range s { if unicode.IsLetter(r) { letters = append(letters, unicode.ToLower(r)) } } ``` 這個改進提陞性能約 35%, 報告結果是基於 2,000,000 次迭代的平均運行時間統計. ``` $ go test -bench=. PASS BenchmarkIsPalindrome-8 2000000 697 ns/op ok gopl.io/ch11/word2 1.468s ``` 如這個例子所示, 快的程序往往是有很少的內存分配. `-benchmem` 命令行標誌參數將在報告中包含內存的分配數據統計. 我們可以比較優化前後內存的分配情況: ``` $ go test -bench=. -benchmem PASS BenchmarkIsPalindrome 1000000 1026 ns/op 304 B/op 4 allocs/op ``` 這是優化之後的結果: ``` $ go test -bench=. -benchmem PASS BenchmarkIsPalindrome 2000000 807 ns/op 128 B/op 1 allocs/op ``` 一次內存分配代替多次的內存分配節省了75%的分配調用次數和減少近一半的內存需求. 這個基準測試告訴我們所需的絶對時間依賴給定的具體操作, 兩個不同的操作所需時間的差異也是和不同環境相關的. 例如, 如果一個函數需要 1ms 處理 1,000 個元素, 那麽處理 10000 或 1百萬 將需要多少時間呢? 這樣的比較揭示了漸近增長函數的運行時間. 另一個例子: I/O 緩存該設置爲多大呢? 基準測試可以幫助我們選擇較小的緩存但能帶來滿意的性能. 第三個例子: 對於一個確定的工作那種算法更好? 基準測試可以評估兩種不同算法對於相同的輸入在不同的場景和負載下的優缺點. 比較基準測試都是結構類似的代碼. 它們通常是采用一個參數的函數, 從幾個標誌的基準測試函數入口調用, 就像這樣: ```Go func benchmark(b *testing.B, size int) { /* ... */ } func Benchmark10(b *testing.B) { benchmark(b, 10) } func Benchmark100(b *testing.B) { benchmark(b, 100) } func Benchmark1000(b *testing.B) { benchmark(b, 1000) } ``` 通過函數參數來指定輸入的大小, 但是參數變量對於每個具體的基準測試都是固定的. 要避免直接脩改 b.N 來控製輸入的大小. 除非你將它作爲一個固定大小的迭代計算輸入, 否則基準測試的結果將毫無意義. 基準測試對於編寫代碼是很有幫助的, 但是卽使工作完成了應應當保存基準測試代碼. 因爲隨着項目的發展, 或者是輸入的增加, 或者是部署到新的操作繫統或不同的處理器, 我們可以再次用基準測試來幫助我們改進設計. **練習 11.6:** 爲 2.6.2節 的 練習 2.4 和 練習 2.5 的 PopCount 函數編寫基準測試. 看看基於表格算法在不同情況下的性能. **練習 11.7:** 爲 *IntSet (§6.5) 的 Add, UnionWith 和 其他方法編寫基準測試, 使用大量隨機出入. 你可以讓這些方法跑多快? 選擇字的大小對於性能的影響如何? IntSet 和基於內建 map 的實現相比有多快?