【Go】string 優化誤區及建議

原文鏈接： https://blog.thinkeridea.com/201902/go/string_ye_shi_yin_yong_lei_xing.html

本文原標題為 《string 也是引用類型》，經過 郝林 大佬指點原標題存在誘導性，這里解釋一下 "引用類型" 有兩個特征：1、多個變量引用一塊內存數據，不創建變量的副本，2、修改任意變量的數據，其它變量可見。顯然字符串只滿足了 "引用類型" 的第一個特點，不能滿足第二個特點，顧不能說字符串是引用類型，感謝大佬指正。

初學 Go 語言的朋友總會在傳 []byte 和 string 之間有着很多糾結，實際上是沒有了解 string 與 slice 的本質，而且讀了一些程序源碼，也發現很多與之相關的問題，下面類似的代碼估計很多初學者都寫過，也充分說明了作者當時內心的糾結：

package main

import "bytes"

func xx(s []byte) []byte{
    ....
    
    return s
}

func main(){
    s := "xxx"
    
    s = string(xx([]byte(s)))
    
    s = string(bytes.Replace([]byte(s), []byte("x"), []byte(""), -1))
}

雖然這樣的代碼並不是來自真實的項目，但是確實有人這樣設計，單從設計上看就很糟糕了，這樣設計的原因很多人說：“slice 是引用類型，傳遞引用類型效率高呀”，主要原因不了解兩者的本質。

上面這個例子如果覺得有點基礎和可愛，下面這個例子貌似並不那么容易說明其存在的問題了吧。

package main

func xx(s *string) *string{
    ....
    return s
}

func main(){
    s := "xx"
    
    s = *xx(&s)
    
    ss :=[]*string{}
    
    ss = append(ss, &s)
}

指針效率高，我就用指針多好，可以減少內存分配呀，設計函數都接收指針變量，程序性能會有很大提升，在實際的項目中這種例子也不少見，我想通過這篇文檔來幫助初學者走出誤區，減少適得其反的優化技巧。

slice 的定義

在之前 “【Go】深入剖析slice和array” 一文中說了 slice 在內存中的存儲模式，slice 本身包含一個指向底層數組的指針，一個 int 類型的長度和一個 int 類型的容量， 這就是 slice 的本質， []byte 本身也是一個 slice，只是底層數組存儲的元素是 byte。下面這個圖就是 slice 的在內存中的狀態：

看一下 reflect.SliceHeader 如何定義 slice 在內存中的結構吧：

type SliceHeader struct {
	Data uintptr
	Len  int
	Cap  int
}

slice 是引用類型是 slice 本身會包含一個地址，在傳遞 slice 時只需要分配 SliceHeader 就好了， 而 SliceHeader 只包含了三個 int 類型，相當於傳遞一個 slice 就只需要拷貝 SliceHeader，而不用拷貝整個底層數組，所以才說 slice 是引用類型的。

那么字符串呢，計算機中我們處理的大多數問題都和字符串有關，難道傳遞字符串真的需要那么高的成本，需要借助 slice 和指針來減少內存開銷嗎。

string 的定義

reflect 包里面也定義了一個 StringHeader 看一下吧：

type StringHeader struct {
	Data uintptr
	Len  int
}

字符串只包含了兩個 int 類型的數據，其中一個是指針，一個是字符串的長度，從 StringHeader 定義來看 string 並不會發生拷貝的，傳遞 string 只會拷貝 StringHeader 而已。

借助 unsafe 來分析一下情況是不是這樣吧：

package main

import (
	"reflect"
	"unsafe"

	"github.com/davecgh/go-spew/spew"
)

func xx(s string) {
	sh := *(*reflect.StringHeader)(unsafe.Pointer(&s))
	spew.Dump(sh)
}

func main() {
	s := "xx"

	sh := *(*reflect.StringHeader)(unsafe.Pointer(&s))
	spew.Dump(sh)

	xx(s)
	xx(s[:1])
	xx(s[1:])
}

上面這段代碼的輸出如下：

(reflect.StringHeader) {
 Data: (uintptr) 0x10f5ee0,
 Len: (int) 2
}
(reflect.StringHeader) {
 Data: (uintptr) 0x10f5ee0,
 Len: (int) 2
}
(reflect.StringHeader) {
 Data: (uintptr) 0x10f5ee0,
 Len: (int) 1
}
(reflect.StringHeader) {
 Data: (uintptr) 0x10f5ee1,
 Len: (int) 1
}

可以發現前三個輸出的指針都是同一個地址，第四個的地址發生了一個字節的偏移，分析來看傳遞字符串確實沒有分配新的內存，同時和 slice 一樣即使傳遞字符串的子串也不會分配新的內存空間，而是指向原字符串的中的一個位置。

這樣說來把 string 轉成 []byte 還浪費的一個 int 的空間呢，需要分配更多的內存，真是適得其反呀，而且類型轉換會發生內存拷貝，從 string 轉為 []byte 才是真的把 string 底層數據全部拷貝一遍呢，真是得不償失呀。

string 的兩個小特性

字符串還有兩個小特性，針對字面量(就是直接寫在程序中的字符串)，會創建在只讀空間上，並且被復用，看一下下面的一個小例子：

package main

import (
	"reflect"
	"unsafe"

	"github.com/davecgh/go-spew/spew"
)

func main() {
	a := "xx"
	b := "xx"
	c := "xxx"
	spew.Dump(*(*reflect.StringHeader)(unsafe.Pointer(&a)))
	spew.Dump(*(*reflect.StringHeader)(unsafe.Pointer(&b)))
	spew.Dump(*(*reflect.StringHeader)(unsafe.Pointer(&c)))
}

從輸出可以了解到，相同的字面量會被復用，但是子串是不會復用空間的，這就是編譯器給我們帶來的福利了，可以減少字面量字符串占用的內存空間。

(reflect.StringHeader) {
 Data: (uintptr) 0x10f5ea0,
 Len: (int) 2
}
(reflect.StringHeader) {
 Data: (uintptr) 0x10f5ea0,
 Len: (int) 2
}
(reflect.StringHeader) {
 Data: (uintptr) 0x10f5f2e,
 Len: (int) 3
}

另一個小特性大家都知道，就是字符串是不能修改的，如果我們不希望調用函數修改我們的數據，最好傳遞字符串，高效有安全。

不過有了 unsafe 這個黑魔法，字符串的這一個特性也就不那么可靠了。

package main

import (
	"fmt"
	"reflect"
	"strings"
	"unsafe"
)

func main() {
	a := strings.Repeat("x", 10)

	fmt.Println(a)
	strHeader := *(*reflect.StringHeader)(unsafe.Pointer(&a))

	sliceHeader := reflect.SliceHeader{
		Data: strHeader.Data,
		Len:  strHeader.Len,
		Cap:  strHeader.Len,
	}

	b := *(*[]byte)(unsafe.Pointer(&sliceHeader))

	b[1] = 'a'

	fmt.Println(a)
}

從輸出里面居然發現字符串被修改了, 我們沒有辦法直接修改字符串，但是可以利用 slice 和 string 本身結構的特性，創建一個 slice 讓它的指針指向 string 的指針位置，然后借助 unsafe 把這個 SliceHeader 轉成 []byte 來修改字符串，字符串確實被修改了。

xxxxxxxxxx
xaxxxxxxxx

看了上面的例子是不是開始擔心把字符串傳給其它函數真的不會更改嗎？感覺很不放心的樣子，難道使用任何函數都要了解它的內部實現嗎，其實這種情況極少發生，還記得之前說的那個字符串特性嗎，字面量字符串會放到只讀空間中，這個很重要，可以保證不是任何函數想修改我們的字符串就可以修改的。

package main

import (
	"reflect"
	"unsafe"
)

func main() {
	defer func() {
		recover()
	}()

	a := "xx"

	strHeader := *(*reflect.StringHeader)(unsafe.Pointer(&a))
	sliceHeader := reflect.SliceHeader{
		Data: strHeader.Data,
		Len:  strHeader.Len,
		Cap:  strHeader.Len,
	}
	b := *(*[]byte)(unsafe.Pointer(&sliceHeader))
	b[1] = 'a'
}

運行上面的代碼發生了一個運行時不可修復的錯誤，就是這個特性其它函數不能確保輸入字符串是否是字面量，也是不會惡意修改我們字符串的了。

unexpected fault address 0x1095dd5
fatal error: fault
[signal SIGBUS: bus error code=0x2 addr=0x1095dd5 pc=0x106c804]

goroutine 1 [running]:
runtime.throw(0x1095fde, 0x5)
	/usr/local/go/src/runtime/panic.go:608 +0x72 fp=0xc000040700 sp=0xc0000406d0 pc=0x10248d2
runtime.sigpanic()
	/usr/local/go/src/runtime/signal_unix.go:387 +0x2d7 fp=0xc000040750 sp=0xc000040700 pc=0x1037677
main.main()
	/Users/qiyin/project/go/src/github.com/yumimobi/test/a.go:22 +0x84 fp=0xc000040798 sp=0xc000040750 pc=0x106c804
runtime.main()
	/usr/local/go/src/runtime/proc.go:201 +0x207 fp=0xc0000407e0 sp=0xc000040798 pc=0x1026247
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1333 +0x1 fp=0xc0000407e8 sp=0xc0000407e0 pc=0x104da51

關於字符串轉 []byte 在 go-extend 擴展包中有直接的實現，這種用法在 go-extend 內部方法實現中也有大量使用， 實際上因為原數據類型和處理數據的函數類型不一致，使用這種方法轉換字符串和 []byte 可以極大的提升程序性能

• exbytes.ToString 零成本的把 []byte 轉為 string。
• exstrings.UnsafeToBytes 零成本的把 []byte 轉為 string。

上面這兩個函數用的好，可以極大的提升我們程序的性能，關於 exstrings.UnsafeToBytes 我們轉換不確定是否是字面量的字符串時就需要確保調用的函數不會修改我們的數據，這往常在調用 bytes 里面的方法十分有效。

傳字符串和字符串指針的區別

之前分析了傳遞 slice 並沒有 string 高效，何況轉換數據類型本身就會發生數據拷貝。

那么在這篇文章的第二個例子，為什么說傳遞字符串指針也不好呢，要了解指針在底層就是一個 int 類型的數據，而我們字符串只是兩個 int 而已，另外如果了解 GC 的話，GC 只處理堆上的數據，傳遞指針字符串會導致數據逃逸到堆上，閱讀標准庫的代碼會有很多注釋說明避免逃逸到堆上，這樣會極大的增加 GC 的開銷，GC 的成本可謂是很高的呀。

疑惑

這篇文章說 “傳遞 slice 並沒有 string 高效”，為什么還會有 bytes 包的存在呢，其中很多函數的功能和 strings 包的功能一致，只是把 string 換成了 []byte， 既然傳遞 []byte 沒有 string 效率好，這個包存在的意義是什么呢。

我們想一下轉換數據類型是會發生數據拷貝，這個成本可是大的多呀，如果我們數據本身就是 []byte 類型，使用 strings 包就需要轉換數據類型了。

另外我們對比兩個函數來看下一下即使傳遞 []byte 沒有 string 效率好，但是標准庫實現上卻會導致兩個函數有很大的性能差異的。

strings.Repeat 函數：

func Repeat(s string, count int) string {
	// Since we cannot return an error on overflow,
	// we should panic if the repeat will generate
	// an overflow.
	// See Issue golang.org/issue/16237
	if count < 0 {
		panic("strings: negative Repeat count")
	} else if count > 0 && len(s)*count/count != len(s) {
		panic("strings: Repeat count causes overflow")
	}

	b := make([]byte, len(s)*count)
	bp := copy(b, s)
	for bp < len(b) {
		copy(b[bp:], b[:bp])
		bp *= 2
	}
	return string(b)
}

bytes.Repeat 函數：

func Repeat(b []byte, count int) []byte {
	// Since we cannot return an error on overflow,
	// we should panic if the repeat will generate
	// an overflow.
	// See Issue golang.org/issue/16237.
	if count < 0 {
		panic("bytes: negative Repeat count")
	} else if count > 0 && len(b)*count/count != len(b) {
		panic("bytes: Repeat count causes overflow")
	}

	nb := make([]byte, len(b)*count)
	bp := copy(nb, b)
	for bp < len(nb) {
		copy(nb[bp:], nb[:bp])
		bp *= 2
	}
	return nb
}

上面兩個函數的實現非常相似，除了類型不同 strings 包在處理完數據發生了一次類型轉換，使用 bytes 只有一次內存分配，而 strings 是兩次。

我們可以借助 exbytes.ToString 函數把 bytes.Repeat 的返回沒有任何成本的轉換會我們需要的字符串，如果我們輸入也是一個字符串的話，還可以借助 exstrings.UnsafeToBytes 來轉換輸入的數據類型。

例如：

s := exbytes.ToString(bytes.Repeat(exstrings.UnsafeToBytes("x"), 10))

不過這樣寫有點太麻煩了，實際上 exstrings 包里面正在修改 strings 里面一些類似函數的問題，所有的實現基本和標准庫一致，只是把其中類型轉換的部分用 exbytes.ToString 優化了一下，可以提升性能，也能提升開發效率。

exstrings.UnsafeRepeat 函數：

func UnsafeRepeat(s string, count int) string {
	// Since we cannot return an error on overflow,
	// we should panic if the repeat will generate
	// an overflow.
	// See Issue golang.org/issue/16237
	if count < 0 {
		panic("strings: negative Repeat count")
	} else if count > 0 && len(s)*count/count != len(s) {
		panic("strings: Repeat count causes overflow")
	}

	b := make([]byte, len(s)*count)
	bp := copy(b, s)
	for bp < len(b) {
		copy(b[bp:], b[:bp])
		bp *= 2
	}
	return exbytes.ToString(b)
}

如果用上面的函數只需要下面這樣寫就可以了：

s:=exstrings.UnsafeRepeat("x", 10)

go-extend 里面還收錄了很多實用的方法，大家也可以多關注。

總結

• 千萬不要為了使用 []byte 來優化 string 傳遞，類型轉換成本很高，且 slice 本身也比 string 更大一些。
• 程序中是使用 string 還是 []byte 需要根據數據來源和處理數據的函數來決定，一定要減少類型轉換。
• 關於使用 strings 還是 bytes 包的問題，主要關注點是數據原始類型以及想獲得的數據類型來選擇。
• 減少使用字符串指針來優化字符串，這會增加 GC 的開銷，具體可以參考 大堆中避免大量的GC開銷 一文。

轉載：

本文作者： 戚銀（thinkeridea）

本文鏈接： https://blog.thinkeridea.com/201902/go/string_ye_shi_yin_yong_lei_xing.html

版權聲明： 本博客所有文章除特別聲明外，均采用 CC BY 4.0 CN協議 許可協議。轉載請注明出處！