大家好，期盼已久的 Go1.18 上周已经发布，今天给大家带来一个 1.18 版本新特性中的优化相关的内容，是与 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 他的作用和定义，会留个心眼。
你的项目中有类似的代码吗？
往期推荐
关注煎鱼，获取业内第一手消息和知识 ?
文章评论