Go中string轉[]byte的陷阱

原文:https://www.cnblogs.com/mushroom/p/8998538.html

• 1. 背景
• 2. slice
  • 2.1 內部結構
  • 2.2 覆蓋前值
• 3. string
  • 3.1 重新分配
  • 3.2 二者轉換
• 4. 逃逸分析
  • 4.1 提高性能
  • 4.2 逃到堆上
  • 4.3 逃逸分配
  • 4.4 大小分配
• 5. 版本差異
• 6. 結論
  • 6.1 參考

1. 背景

上周四小伙伴發了Go社區一個帖子下hej8875的回復，如下：

package main
import "fmt"
func main() {
s := []byte("")
s1 := append(s, 'a')
s2 := append(s, 'b')
//fmt.Println(s1, "==========", s2)
fmt.Println(string(s1), "==========", string(s2))
}
// 出現個讓我理解不了的現象, 注釋時候輸出是 b ========== b
// 取消注釋輸出是 [97] ========== [98] a ========== b 

這個回復比原貼有意思，也很有迷惑性。作者測試了下，確實如此，於是和小伙伴們討論深究下。開始以為應該挺簡單的，理解后，發現涉及挺多知識點，值得跟大家分享下過程。

2. slice

2.1 內部結構

先拋去注釋的這行代碼//fmt.Println(s1, "==========", s2)，后面在講。 當輸出 b ========== b時，已經不符合預期結果a和b了。我們知道slice內部並不會存儲真實的值，而是對數組片段的引用，其內部結構是:

type slice struct {
    data uintptr
    len int
    cap int
}

其中data是指向數組元素的指針，len是指slice要引用數組中的元素數量。cap是指要引用數組中（從data指向開始計算）剩余的元素數量，這個數量減去len，就是還能向這個slice(數組)添加多少元素，如果超出就會發生數據的復制。slice的示意圖：

s := make([]byte, 5)// 下圖

s = s[2:4] //會重新生成新的slice，並賦值給s。與底層數組的引用也發生了改變

2.2 覆蓋前值

回到問題上，由此可以推斷出：s := []byte("") 這行代碼中的s實際引用了一個 byte 的數組。

其capacity 是32，length是 0：

s := []byte("")
fmt.Println(cap(s), len(s))
//輸出： 32 0

關鍵點在於下面代碼s1 := append(s, 'a')中的append，並沒有在原slice修改，當然也沒辦法修改，因為在Go中都是值傳遞的。當把s傳入append函數內時，已經復制出一份s1，然后在s1上追加 a，s1長度是增加了1，但s長度仍然是0：

s := []byte("")
fmt.Println(cap(s), len(s))
s1 := append(s, 'a')
fmt.Println(cap(s1), len(s1))
// 輸出
// 32 0
// 32 1

由於s，s1指向同一份數組，所以在s1上進行append a操作時（底層數組[0]=a），也是s所指向數組的操作，但s本身不會有任何變化。這也是Go中append的寫法都是：

s = append(s,'a')

append函數會返回s1，需要重新賦值給s。 如果不賦值的話，s本身記錄的數據就滯后了，再次對其append，就會從滯后的數據開始操作。雖然看起是append，實際上確是把上一次append的值給覆蓋了。

所以問題的答案是：后append的b，把上次append的a給覆蓋了，所以才會輸出b b。

假設底層數組是arr，如注釋：

s := []byte("")
s1 := append(s, 'a') // 等同於 arr[0] = 'a'
s2 := append(s, 'b') // 等同於 arr[0] = 'b'
fmt.Println(string(s1), "==========", string(s2)) // 只是把同一份數組打印出來了

3. string

3.1 重新分配

老濕，能不能再給力一點？可以，我們繼續，先來看個題：

s := []byte{}
s1 := append(s, 'a') 
s2 := append(s, 'b') 
fmt.Println(string(s1), ",", string(s2))
fmt.Println(cap(s), len(s))

猜猜輸出什么？

答案是：a , b 和 0 0，符合預期。

上面2.2章節例子中輸出的是：32，0。看來問題關鍵在這里，兩者差別在於一個是默認[]byte{}，另外個是空字符串轉的[]byte("")。其長度都是0，比較好理解，但為什么容量是32就不符合預期輸出了？

因為 capacity 是數組還能添加多少的容量，在能滿足的情況，不會重新分配。所以 capacity-length=32，是足夠appenda，b的。我們用make來驗證下：

// append 內會重新分配，輸出a，b
s := make([]byte, 0, 0)
// append 內不會重新分配，輸出b，b，因為容量為1，足夠append
s := make([]byte, 0, 1)
s1 := append(s, 'a')
s2 := append(s, 'b')
fmt.Println(string(s1), ",", string(s2))

重新分配指的是：append 會檢查slice大小，如果容量不夠，會重新創建個更大的slice，並把原數組復制一份出來。在make([]byte,0,0)這樣情況下，s容量肯定不夠用，所以s1，s2使用的都是各自從s復制出來的數組，結果也自然符合預期a，b了。

測試重新分配后的容量變大，打印s1:

s := make([]byte, 0, 0)
s1 := append(s, 'a')
fmt.Println(cap(s1), len(s1))
// 輸出 8，1。重新分配后擴大了

3.2 二者轉換

那為什么空字符串轉的slice的容量是32？而不是0或者8呢？

只好祭出殺手鐧了，翻源碼。Go官方提供的工具，可以查到編譯后調用的匯編信息，不然在大片源碼中搜索也很累。

-gcflags 是傳遞參數給Go編譯器，-S -S是打印匯編調用信息和數據，-S只打印調用信息。

go run -gcflags '-S -S' main.go

下面是輸出：

    0x0000 00000 ()    TEXT    "".main(SB), $264-0
    0x003e 00062 ()   MOVQ    AX, (SP)
    0x0042 00066 ()   XORPS   X0, X0
    0x0045 00069 ()   MOVUPS  X0, 8(SP)
    0x004a 00074 ()   PCDATA  $0, $0
    0x004a 00074 ()   CALL    runtime.stringtoslicebyte(SB)
    0x004f 00079 ()   MOVQ    32(SP), AX
    b , b

Go使用的是plan9匯編語法，雖然整體有些不好理解，但也能看出我們需要的關鍵點：

CALL    runtime.stringtoslicebyte(SB)

定位源碼到src\runtime\string.go:

從stringtoslicebyte函數中可以看出容量32的源頭，見注釋：

const tmpStringBufSize = 32
type tmpBuf [tmpStringBufSize]byte
func stringtoslicebyte(buf *tmpBuf, s string) []byte {
    var b []byte  
    if buf != nil && len(s) <= len(buf) {
        *buf = tmpBuf{}   // tmpBuf的默認容量是32
        b = buf[:len(s)]  // 創建個容量為32，長度為0的新slice，賦值給b。
    } else {
        b = rawbyteslice(len(s))
    }
    copy(b, s)  // s是空字符串，復制過去也是長度0
    return b
}

那為什么不是走else中rawbyteslice函數？

func rawbyteslice(size int) (b []byte) {
    cap := roundupsize(uintptr(size))
    p := mallocgc(cap, nil, false)
    if cap != uintptr(size) {
        memclrNoHeapPointers(add(p, uintptr(size)), cap-uintptr(size))
    }

    *(*slice)(unsafe.Pointer(&b)) = slice{p, size, int(cap)}
    return
}

如果走else的話，容量就不是32了。假如走的話，也不影響得出的結論(覆蓋)，可以測試下：

    s := []byte(strings.Repeat("c", 33))
    s1 := append(s, 'a')
    s2 := append(s, 'b')
    fmt.Println(string(s1), ",", string(s2))
    // cccccccccccccccccccccccccccccccccb , cccccccccccccccccccccccccccccccccb

4. 逃逸分析

老濕，能不能再給力一點？什么時候該走else？老濕你說了大半天，坑還沒填，為啥加上注釋就符合預期輸出a，b? 還有加上注釋為啥連容量都變了？

s := []byte("")
fmt.Println(cap(s), len(s))
s1 := append(s, 'a') 
s2 := append(s, 'b') 
fmt.Println(s1, ",", s2)
fmt.Println(string(s1), ",", string(s2))
//輸出
// 0 0
// [97] ========== [98]
// a , b

如果用逃逸分析來解釋的話，就比較好理解了，先看看什么是逃逸分析。

4.1 提高性能

如果一個函數或子程序內有局部對象，返回時返回該對象的指針，那這個指針可能在任何其他地方會被引用，就可以說該指針就成功“逃逸”了 。 而逃逸分析（escape analysis）就是分析這類指針范圍的方法，這樣做的好處是提高性能：

• 最大的好處應該是減少gc的壓力，不逃逸的對象分配在棧上，當函數返回時就回收了資源，不需要gc標記清除。
• 因為逃逸分析完后可以確定哪些變量可以分配在棧上，棧的分配比堆快，性能好
• 同步消除，如果定義的對象的方法上有同步鎖，但在運行時，卻只有一個線程在訪問，此時逃逸分析后的機器碼，會去掉同步鎖運行。

Go在編譯的時候進行逃逸分析，來決定一個對象放棧上還是放堆上，不逃逸的對象放棧上，可能逃逸的放堆上 。

4.2 逃到堆上

取消注釋情況下：Go編譯程序進行逃逸分析時，檢測到fmt.Println有引用到s，所以在決定堆上分配s下的數組。在進行string轉[]byte時，如果分配到棧上就會有個默認32的容量，分配堆上則沒有。

用下面命令執行，可以得到逃逸信息，這個命令只編譯程序不運行，上面用的go run -gcflags是傳遞參數到編譯器並運行程序。

go tool compile -m main.go

取消注釋fmt.Println(s1, ",", s2) 后 ([]byte)("")會逃逸到堆上：

main.go:23:13: s1 escapes to heap
main.go:20:13: ([]byte)("") escapes to heap  // 逃逸到堆上
main.go:23:18: "," escapes to heap
main.go:23:18: s2 escapes to heap
main.go:24:20: string(s1) escapes to heap
main.go:24:20: string(s1) escapes to heap
main.go:24:26: "," escapes to heap
main.go:24:37: string(s2) escapes to heap
main.go:24:37: string(s2) escapes to heap
main.go:23:13: main ... argument does not escape
main.go:24:13: main ... argument does not escape

加上注釋//fmt.Println(s1, ",", s2)不會逃逸到堆上：

go tool compile -m main.go
main.go:24:20: string(s1) escapes to heap
main.go:24:20: string(s1) escapes to heap
main.go:24:26: "," escapes to heap
main.go:24:37: string(s2) escapes to heap
main.go:24:37: string(s2) escapes to heap
main.go:20:13: main ([]byte)("") does not escape  //不逃逸
main.go:24:13: main ... argument does not escape

4.3 逃逸分配

接着繼續定位調用stringtoslicebyte的地方，在src\cmd\compile\internal\gc\walk.go 文件。 為了便於理解，下面代碼進行了匯總：

const (
    EscUnknown        = iota
    EscNone           // 結果或參數不逃逸堆上.
 )  
case OSTRARRAYBYTE:
        a := nodnil()   //默認數組為空
        if n.Esc == EscNone {
            // 在棧上為slice創建臨時數組
            t := types.NewArray(types.Types[TUINT8], tmpstringbufsize)
            a = nod(OADDR, temp(t), nil)
        }
        n = mkcall("stringtoslicebyte", n.Type, init, a, conv(n.Left, types.Types[TSTRING]))

不逃逸情況下會分配個32字節的數組 t。逃逸情況下不分配，數組設置為 nil，所以s的容量是0。接着從s上append a，b到s1，s2，其必然會發生復制，所以不會發生覆蓋前值，也符合預期結果a，b 。再看stringtoslicebyte就很清晰了。

func stringtoslicebyte(buf *tmpBuf, s string) []byte {
    var b []byte
    if buf != nil && len(s) <= len(buf) { 
        *buf = tmpBuf{}
        b = buf[:len(s)]
    } else {
        b = rawbyteslice(len(s))
    }
    copy(b, s)
    return b
}

4.4 大小分配

不逃逸情況下默認32。那逃逸情況下分配策略是？

s := []byte("a")
fmt.Println(cap(s))
s1 := append(s, 'a')
s2 := append(s, 'b')
fmt.Print(s1, s2)

如果是空字符串它的輸出：0。”a“字符串時輸出：8。

大小取決於src\runtime\size.go 中的roundupsize 函數和 class_to_size 變量。

這些增加大小的變化，是由 src\runtime\mksizeclasses.go生成的。

5. 版本差異

老濕，能不能再給力一點？ 老濕你講的全是錯誤的，我跑的結果和你是反的。對，你沒錯，作者也沒錯，畢竟我們在用Go寫程序，如果Go底層發生變化了，肯定結果不一樣。作者在調研過程中，發現另外博客得到的stringtoslicebyte源碼是：

func stringtoslicebyte(s String) (b Slice) {
    b.array = runtime·mallocgc(s.len, 0, FlagNoScan|FlagNoZero);
    b.len = s.len;
    b.cap = s.len;
    runtime·memmove(b.array, s.str, s.len);
}

上面版本的源碼，得到的結果，也是符合預期的，因為不會默認分配32字節的數組。

繼續翻舊版代碼，到1.3.2版是這樣:

func stringtoslicebyte(s String) (b Slice) {
    uintptr cap;
    cap = runtime·roundupsize(s.len);
    b.array = runtime·mallocgc(cap, 0, FlagNoScan|FlagNoZero);
    b.len = s.len;
    b.cap = cap;
    runtime·memmove(b.array, s.str, s.len);
    if(cap != b.len)
        runtime·memclr(b.array+b.len, cap-b.len);
}

1.6.4版:

func stringtoslicebyte(buf *tmpBuf, s string) []byte {
    var b []byte
    if buf != nil && len(s) <= len(buf) {
        b = buf[:len(s):len(s)]
    } else {
        b = rawbyteslice(len(s))
    }
    copy(b, s)
    return b
}

更古老的：

struct __go_open_array
__go_string_to_byte_array (String str)
{
  uintptr cap;
  unsigned char *data;
  struct __go_open_array ret;

  cap = runtime_roundupsize (str.len);
  data = (unsigned char *) runtime_mallocgc (cap, 0, FlagNoScan | FlagNoZero);
  __builtin_memcpy (data, str.str, str.len);
  if (cap != (uintptr) str.len)
    __builtin_memset (data + str.len, 0, cap - (uintptr) str.len);
  ret.__values = (void *) data;
  ret.__count = str.len;
  ret.__capacity = str.len;
  return ret;
}

作者在1.6.4版本上測試，得到的結果確實是反的，注釋了反而得到預期結果 a, b。 本文中使用的是1.10.2

6. 結論

老濕，能不能再給力一點？🐶，再繼續一天時間都沒了。

總結下：

1. 注釋時輸出b，b。是因為沒有逃逸，所以分配了默認32字節大小的數組，2次append都是在數組[0]賦值，后值覆蓋前值，所以才是b，b。
2. 取消注釋時輸出a，b。是因為fmt.Println引用了s，逃逸分析時發現需要逃逸並且是空字符串，所以分配了空數組。2次append都是操作各自重新分配后的新slice，所以輸出a，b。

注意：

1. 源碼目錄中的gc是Go compiler的意思，而不是Garbage Collection，gcflags中的gc也是同樣意思。
2. 另外這種寫法是沒意義的，也極不推薦。應該把 []byte("string")當成只讀的來用，不然就容易出現難排查的bug。

6.1 參考

原帖是：https://gocn.io/question/1852

https://gocn.io/article/355

https://go-review.googlesource.com/c/gofrontend/+/30827

http://golang-examples.tumblr.com/post/86403044869/conversion-between-byte-and-string-dont-share