原文鏈接:https://blog.thinkeridea.com/...
初學 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
是引用類型,傳遞引用類型效率高呀”,主要原因不瞭解兩者的本質,加上文檔上說 Go
的引用類型有兩種:slice
和 map
,這個在面試中也是經常遇到的吧。
上面這個例子如果覺得有點基礎和可愛,下面這個例子貌似並不那麼容易說明其存在的問題了吧。
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
類型的數據,其中一個是指針,一個是字符串的長度,從定義上來看 string
也是引用類型。
藉助 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 優化了一下,可以提升性能,也能提升開發效率。
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協議 許可協議。轉載請註明出處!