目录
前言
当我们使用go进行数据序列化或反序列化操作时，可能经常涉及到字符串和字节数组的转换。例如：
1
2
3
4
5
6
7
8
9
ifstr, err := json.Marshal(from); err != nil {panic(err)}else{returnstring(str)}json序列化后为[]byte类型，需要将其转换为字符串类型。当数据量小时，类型间转换的开销可以忽略不计，但当数据量增大后，可能成为性能瓶颈，使用高效的转换方法能减少这方面的开销
数据结构
在了解其如何转换前，需要了解其底层数据结构
本文基于go 1.13.12
string：
1
2
3
4
5
6
7
type stringStructstruct{str unsafe.Pointerlenint}slice：
1
2
3
4
5
6
7
8
9
type slice struct {array unsafe.Pointerlenintcapint}与slice的结构相比，string缺少一个表示容量的cap字段，因此不能对string遍历使用内置的cap()函数那为什么string不需要cap字段呢？因为go中string被设计为不可变类型（当然在很多其他语言中也是）,由于其不可像slice一样追加元素，也就不需要cap字段判断是否超出底层数组的容量，来决定是否扩容
只有len属性不影响for-range等读取操作，因为for-range操作只根据len决定是否跳出循环
那为什么字符串要设定为不可变呢？因为这样能保证字符串的底层数组不发生改变
举个例子，map中以string为键，如果底层字符数组改变，则计算出的哈希值也会发生变化，这样再从map中定位时就找不到之前的value，因此其不可变特性能避免这种情况发生，string也适合作为map的键。除此之外，不可变特性也能保障数据的线程安全
常规实现
字符串不可变有很多好处，为了维持其不可变特性，字符串和字节数组互转一般是通过数据拷贝的方式实现：
1
2
3
4
5
var a string ="hello world"var b []byte = []byte(a)// string转[]bytea = string(b)// []byte转string这种方式实现简单，但是通过底层数据复制实现的，在编译期间分别转换成对slicebytetostring和stringtoslicebyte的函数调用
string转[]byte
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
func stringtoslicebyte(buf *tmpBuf, s string) []byte {var b []byteifbuf != nil && len(s) <= len(buf) {*buf = tmpBuf{}b = buf[:len(s)]}else{// 申请内存b = rawbyteslice(len(s))}// 复制数据copy(b, s)returnb}其根据返回值是否逃逸到堆上，以及buf的长度是否足够，判断选择使用buf还是调用rawbyteslice申请一个slice。但不管是哪种，都会执行一次copy拷贝底层数据
[]byte转string
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
func slicebytetostring(buf *tmpBuf, b []byte) (str string) {l := len(b)ifl == 0 {return""}ifl == 1 {stringStructOf(&str).str = unsafe.Pointer(&staticbytes[b[0]])stringStructOf(&str).len = 1return}var p unsafe.Pointerifbuf != 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)// 拷贝数据memmovereturn}首先处理长度为0或1的情况，再判断使用buf还是通过mallocgc新申请一段内存，但无论哪种方式，最后都要拷贝数据
这里设置了转换后字符串的len属性
高效实现
如果程序保证不对底层数据进行修改，那么只转换类型，不拷贝数据，是否可以提高性能？
unsafe.Pointer，int，uintpt这三种类型占用的内存大小相同
1
2
3
4
5
6
7
8
9
10
11
var v1 unsafe.Pointervar v2intvar v3 uintptrfmt.Println(unsafe.Sizeof(v1))// 8fmt.Println(unsafe.Sizeof(v2))// 8fmt.Println(unsafe.Sizeof(v3))// 8因此从底层结构上来看string可以看做[2]uintptr，[]byte切片类型可以看做 [3]uintptr
那么从string转[]byte只需构建出 [3]uintptr{ptr,len,len}
这里我们为slice结构生成了cap字段，其实这里不生成cap字段对读取操作没有影响，但如果要往转换后的slice append元素可能有问题，原因如下：
这样做slice的cap属性是随机的，可能是大于len的值，那么append时就不会新开辟一段内存存放元素，而是在原数组后面追加，如果后面的内存不可写就会panic
[]byte转string更简单，直接转换指针类型即可，忽略cap字段
实现如下：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
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来转换不同类型的指针，没有底层数据的拷贝
性能测试
接下来对高效实现进行性能测试，这里选用长度为100的字符串或字节数组进行转换
分别测试以下4个方法：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
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 {returnstring(bytes)}测试结果如下：
BenchmarkStringToByteSliceOld-12 28637332 42.0 ns/opBenchmarkStringToByteSliceNew-12 1000000000 0.496 ns/op
BenchmarkByteSliceToStringOld-12 32595271 36.0 ns/op
BenchmarkByteSliceToStringNew-12 1000000000 0.256 ns/op
可以看出性能差距比较大，如果需要转换的字符串或字节数组长度更长，性能提升更加明显
总结
本文介绍了字符串和数组的底层数据结构，以及高效的互转方法，需要注意的是，其适用于程序能保证不对底层数据进行修改的场景。若不能保证，且底层数据被修改可能引发异常，则还是使用拷贝的方式
您可能感兴趣的文章:
原网址: 访问
创建于: 2022-09-13 20:55:47
目录: default
标签: 无