大家好,我是煎鱼。
Go1.18 过几周(3月份)就要发布了,先前我们已经更新了好几期新版本特性,今天给大家带来一个新的优化类的内容,是与 strings 和 bytes 标准库有关。
背景
想要更快捷复制
在日常编程中,字节 []byte
是经常需要复制的。需要写以下代码:
dup := make([]byte, len(data))
copy(dup, data)
@Ilia Choly 觉得这就太麻烦了,毕竟每次都得写一遍,又或是自己封装成如下函数:
// Clone returns a copy of b
func Clone(b []byte) []byte {
b2 := make([]byte, len(b))
copy(b2, b)
return b2
}
为此想要增加一个快捷方法,不过这显然站不住脚,熟悉语法的同学会发现有现成的方式:
b2 := append([]byte(nil), b...)
一行就能实现效果,甚至更快,因为分配的切片不会被初始化为零值。
复制会共享内存
许多 Go 开发者,在写应用程序要复制切片(Slice)时,会发现复制出来的切片 s1 和原始的 s0 有内存上的关联,其本质原因在于其底层的数据结构导致,这会导致许多隐藏的问题。
示例代码如下:
import (
"fmt"
"reflect"
"unsafe"
)
func main() {
s0 := "脑子进煎鱼了"
s1 := s0[:3]
s0h := (*reflect.StringHeader)(unsafe.Pointer(&s0))
s1h := (*reflect.StringHeader)(unsafe.Pointer(&s1))
fmt.Printf("Len is equal: %t\n", s0h.Len == s1h.Len)
fmt.Printf("Data is equa: %t\n", s0h.Data == s1h.Data)
}
从上述程序来看,你认为变量 s0 和 s1 相比,他们的 Len 相等吗?Data 相等吗?
输出结果如下:
Len is equal: false
Data is equa: true
咋一看,好像没问题。Len 不相等,毕竟是按索引复制的。但 Data 竟然就相等了,这为什么,是 Go 出 BUG 了吗?
这实际是与 Go 在 String 和 Slice 的底层数据结构有关的,例如 String 的运行时表现是 StringHeader。
他的底层结构如下:
type StringHeader struct {
Data uintptr
Len int
}
- Data: 指向具体的底层数组。
- Len:代表字符串切片的长度。
关键就在于 Data,本质上是一个指向底层数据的指针地址,因此在复制时,会将其也复制过去。造成不必要的复制和 “脏” 数据,引发各种奇怪的 BUG。
这个问题,正在新特性的痛点。
新特性
在 Go1.18 的新特性中,strings 和 bytes 增加了一个 Clone 方法,来解决前面提到的 2 个问题点。
源代码如下:
func Clone(s string) string {
if len(s) == 0 {
return ""
}
b := make([]byte, len(s))
copy(b, s)
return *(*string)(unsafe.Pointer(&b))
}
- 通过
copy
函数对原始字符串进行复制,得到一份新的[]byte
数据。 - 通过
*(*string)(unsafe.Pointer(&b))
进行指针操作,实现byte
到string
的零内存复制转换。
至此,通过非常巧妙地方式解决了背景中的两个问题。大家也不用一直去重复写类似的代码了。
总结
一直以来,Go 中的 string 和 slice 因为底层数组指向和扩缩容机制等原因饱受争议,在末尾也给出一些公众号之前介绍过的一些 “坑”,有兴趣的读者可以看看。
本次的 1.18 新方法更新,是有一定功能作用的,在学习上也能够明确的知道 Clone 他的作用和定义,会留个心眼。
你的项目中有类似的代码吗?
若有任何疑问欢迎评论区反馈和交流,最好的关系是互相成就,各位的点赞就是煎鱼创作的最大动力,感谢支持。
往期推荐
参考
- bytes, strings: add Clone
- [test: add test that we don't optimize string([]byte(string))](https://github.com/golang/go/...)
- proposal: provide std lib pkg Clone function to copy a string efficiently without memory sharing