Go中string與[]byte高效互轉的方法實例

更新時間：2021年09月20日 12:16:42 作者：亞洲第一中鋒_哈達迪

string與[]byte經常需要互相轉化,普通轉化會發(fā)生底層數(shù)據的復制,下面這篇文章主要給大家介紹了關于Go中string與[]byte高效互轉的相關資料,文中通過示例代碼介紹的非常詳細,需要的朋友可以參考下

前言

當我們使用go進行數(shù)據序列化或反序列化操作時，可能經常涉及到字符串和字節(jié)數(shù)組的轉換。例如：

if str, err := json.Marshal(from); err != nil {

    panic(err)

} else {

    return string(str)

}

json序列化后為[]byte類型，需要將其轉換為字符串類型。當數(shù)據量小時，類型間轉換的開銷可以忽略不計，但當數(shù)據量增大后，可能成為性能瓶頸，使用高效的轉換方法能減少這方面的開銷

數(shù)據結構

在了解其如何轉換前，需要了解其底層數(shù)據結構

本文基于go 1.13.12

string：

type stringStruct struct {

   str unsafe.Pointer

   len int

}

slice：

type slice struct {

   array unsafe.Pointer

   len   int

   cap   int

}

與slice的結構相比，string缺少一個表示容量的cap字段，因此不能對string遍歷使用內置的cap()函數(shù)那為什么string不需要cap字段呢？因為go中string被設計為不可變類型（當然在很多其他語言中也是）,由于其不可像slice一樣追加元素，也就不需要cap字段判斷是否超出底層數(shù)組的容量，來決定是否擴容

只有l(wèi)en屬性不影響for-range等讀取操作，因為for-range操作只根據len決定是否跳出循環(huán)

那為什么字符串要設定為不可變呢？因為這樣能保證字符串的底層數(shù)組不發(fā)生改變

舉個例子，map中以string為鍵，如果底層字符數(shù)組改變，則計算出的哈希值也會發(fā)生變化，這樣再從map中定位時就找不到之前的value，因此其不可變特性能避免這種情況發(fā)生，string也適合作為map的鍵。除此之外，不可變特性也能保障數(shù)據的線程安全

常規(guī)實現(xiàn)

字符串不可變有很多好處，為了維持其不可變特性，字符串和字節(jié)數(shù)組互轉一般是通過數(shù)據拷貝的方式實現(xiàn)：

var a string = "hello world"

var b []byte = []byte(a)  // string轉[]byte

a = string(b)             // []byte轉string

這種方式實現(xiàn)簡單，但是通過底層數(shù)據復制實現(xiàn)的，在編譯期間分別轉換成對slicebytetostring和stringtoslicebyte的函數(shù)調用

string轉[]byte

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))

   }

   // 復制數(shù)據

   copy(b, s)

   return b

}

其根據返回值是否逃逸到堆上，以及buf的長度是否足夠，判斷選擇使用buf還是調用rawbyteslice申請一個slice。但不管是哪種，都會執(zhí)行一次copy拷貝底層數(shù)據

[]byte轉string

func slicebytetostring(buf *tmpBuf, b []byte) (str string) {

   l := len(b)

   if l == 0 {

 return ""

   }

   if l == 1 {

      stringStructOf(&str).str = unsafe.Pointer(&staticbytes[b[0]])

      stringStructOf(&str).len = 1

      return

   }



   var p unsafe.Pointer

   if buf != nil && len(b) <= len(buf) {

      p = unsafe.Pointer(buf)

   } else {

      p = mallocgc(uintptr(len(b)), nil, false)

   }

   // 賦值底層指針

   stringStructOf(&str).str = p

   // 賦值長度

   stringStructOf(&str).len = len(b)

   // 拷貝數(shù)據

   memmove(p, (*(*slice)(unsafe.Pointer(&b))).array, uintptr(len(b)))

   return

}

首先處理長度為0或1的情況，再判斷使用buf還是通過mallocgc新申請一段內存，但無論哪種方式，最后都要拷貝數(shù)據
這里設置了轉換后字符串的len屬性

高效實現(xiàn)

如果程序保證不對底層數(shù)據進行修改，那么只轉換類型，不拷貝數(shù)據，是否可以提高性能？

unsafe.Pointer，int，uintpt這三種類型占用的內存大小相同

var v1 unsafe.Pointer

var v2 int

var v3 uintptr

fmt.Println(unsafe.Sizeof(v1)) // 8

fmt.Println(unsafe.Sizeof(v2)) // 8

fmt.Println(unsafe.Sizeof(v3)) // 8

因此從底層結構上來看string可以看做[2]uintptr，[]byte切片類型可以看做 [3]uintptr

那么從string轉[]byte只需構建出 [3]uintptr{ptr,len,len}

這里我們?yōu)閟lice結構生成了cap字段，其實這里不生成cap字段對讀取操作沒有影響，但如果要往轉換后的slice append元素可能有問題，原因如下：

這樣做slice的cap屬性是隨機的，可能是大于len的值，那么append時就不會新開辟一段內存存放元素，而是在原數(shù)組后面追加，如果后面的內存不可寫就會panic

[]byte轉string更簡單，直接轉換指針類型即可，忽略cap字段

實現(xiàn)如下：

func stringTobyteSlice(s string) []byte {

   tmp1 := (*[2]uintptr)(unsafe.Pointer(&s))

   tmp2 := [3]uintptr{tmp1[0], tmp1[1], tmp1[1]}

   return *(*[]byte)(unsafe.Pointer(&tmp2))

}



func byteSliceToString(bytes []byte) string {

   return *(*string)(unsafe.Pointer(&bytes))

}

這里使用unsafe.Pointer來轉換不同類型的指針，沒有底層數(shù)據的拷貝

性能測試

接下來對高效實現(xiàn)進行性能測試，這里選用長度為100的字符串或字節(jié)數(shù)組進行轉換

分別測試以下4個方法：

func stringTobyteSlice(s string) []byte {

   tmp1 := (*[2]uintptr)(unsafe.Pointer(&s))

   tmp2 := [3]uintptr{tmp1[0], tmp1[1], tmp1[1]}

   return *(*[]byte)(unsafe.Pointer(&tmp2))

}



func stringTobyteSliceOld(s string) []byte {

   return []byte(s)

}



func byteSliceToString(bytes []byte) string {

   return *(*string)(unsafe.Pointer(&bytes))

}



func byteSliceToStringOld(bytes []byte) string {

   return string(bytes)

}

測試結果如下：

BenchmarkStringToByteSliceOld-12            28637332                42.0 ns/op

BenchmarkStringToByteSliceNew-12            1000000000                 0.496 ns/op

BenchmarkByteSliceToStringOld-12            32595271                36.0 ns/op

BenchmarkByteSliceToStringNew-12            1000000000                 0.256 ns/op

可以看出性能差距比較大，如果需要轉換的字符串或字節(jié)數(shù)組長度更長，性能提升更加明顯