Go结构体SliceHeader及StringHeader作用详解
来源:脚本之家
时间:2022-12-23 19:12:17 145浏览 收藏
对于一个Golang开发者来说,牢固扎实的基础是十分重要的,golang学习网就来带大家一点点的掌握基础知识点。今天本篇文章带大家了解《Go结构体SliceHeader及StringHeader作用详解》,主要介绍了结构体、SliceHeader、StringHeader,希望对大家的知识积累有所帮助,快点收藏起来吧,否则需要时就找不到了!
引言
在 Go 语言中总是有一些看上去奇奇怪怪的东西,咋一眼一看感觉很熟悉,但又不理解其在 Go 代码中的实际意义,面试官却爱问...
今天要给大家介绍的是 SliceHeader 和 StringHeader 结构体,了解清楚他到底是什么,又有什么用,并且会在最后给大家介绍 0 拷贝转换的内容。
一起愉快地开始吸鱼之路。
SliceHeader
SliceHeader 如其名,Slice + Header,看上去很直观,实际上是 Go Slice(切片)的运行时表现。
SliceHeader 的定义如下:
type SliceHeader struct { Data uintptr Len int Cap int }
- Data:指向具体的底层数组。
- Len:代表切片的长度。
- Cap:代表切片的容量。
既然知道了切片的运行时表现,那是不是就意味着我们可以自己造一个?
在日常程序中,可以利用标准库 reflect
提供的 SliceHeader
结构体造一个:
func main() { // 初始化底层数组 s := [4]string{"脑子", "进", "煎鱼", "了"} s1 := s[0:1] s2 := s[:] // 构造 SliceHeader sh1 := (*reflect.SliceHeader)(unsafe.Pointer(&s1)) sh2 := (*reflect.SliceHeader)(unsafe.Pointer(&s2)) fmt.Println(sh1.Len, sh1.Cap, sh1.Data) fmt.Println(sh2.Len, sh2.Cap, sh2.Data) }
你认为输出结果是什么,这两个新切片会指向同一个底层数组的内存地址吗?
输出结果:
1 4 824634330936
4 4 824634330936
两个切片的 Data 属性所指向的底层数组是一致的,Len 属性的值不一样,sh1 和 sh2 分别是两个切片。
疑问
为什么两个新切片所指向的 Data 是同一个地址的呢?
这其实是 Go 语言本身为了减少内存占用,提高整体的性能才这么设计的。
将切片复制到任意函数的时候,对底层数组大小都不会影响。复制时只会复制切片本身(值传递),不会涉及底层数组。
也就是在函数间传递切片,其只拷贝 24 个字节(指针字段 8 个字节,长度和容量分别需要 8 个字节),效率很高。
坑
这种设计也引出了新的问题,在平时通过 s[i:j]
所生成的新切片,两个切片底层指向的是同一个底层数组。
假设在没有超过容量(cap)的情况下,对第二个切片操作会影响第一个切片。
这是很多 Go 开发常会碰到的一个大 “坑”,不清楚的排查了很久的都不得而终。
StringHeader
除了 SliceHeader 外,Go 语言中还有一个典型代表,那就是字符串(string)的运行时表现。
StringHeader 的定义如下:
type StringHeader struct { Data uintptr Len int }
- Data:存放指针,其指向具体的存储数据的内存区域。
- Len:字符串的长度。
可得知 “Hello” 字符串的底层数据如下:
var data = [...]byte{ 'h', 'e', 'l', 'l', 'o', }
底层的存储示意图如下:
图来自网络
真实演示例子如下:
func main() { s := "脑子进煎鱼了" s1 := "脑子进煎鱼了" s2 := "脑子进煎鱼了"[7:] fmt.Printf("%d \n", (*reflect.StringHeader)(unsafe.Pointer(&s)).Data) fmt.Printf("%d \n", (*reflect.StringHeader)(unsafe.Pointer(&s1)).Data) fmt.Printf("%d \n", (*reflect.StringHeader)(unsafe.Pointer(&s2)).Data) }
你认为输出结果是什么,变量 s 和 s1、s2 会指向同一个底层内存空间吗?
输出结果:
17608227
17608227
17608234
从输出结果来看,变量 s 和 s1 指向同一个内存地址。变量 s2 虽稍有偏差,但本质上也是指向同一块。
因为其是字符串的切片操作,是从第 7 位索引开始,因此正好的 17608234-17608227 = 7。也就是三个变量都是指向同一块内存空间,这是为什么呢?
这是因为在 Go 语言中,字符串都是只读的,为了节省内存,相同字面量的字符串通常对应于同一字符串常量,因此指向同一个底层数组。
0 拷贝转换
为什么会有人关注到 SliceHeader、StringHeader 这类运行时细节呢,一大部分原因是业内会有开发者,希望利用其实现零拷贝的 string 到 bytes 的转换。
常见转换代码如下:
func string2bytes(s string) []byte { stringHeader := (*reflect.StringHeader)(unsafe.Pointer(&s)) bh := reflect.SliceHeader{ Data: stringHeader.Data, Len: stringHeader.Len, Cap: stringHeader.Len, } return *(*[]byte)(unsafe.Pointer(&bh)) }
但这其实是错误的,官方明确表示:
the Data field is not sufficient to guarantee the data it references will not be garbage collected, so programs must keep a separate, correctly typed pointer to the underlying data.
SliceHeader、StringHeader 的 Data 字段是一个 uintptr
类型。由于 Go 语言只有值传递。
因此在上述代码中会出现将 Data
作为值拷贝的情况,这就会导致无法保证它所引用的数据不会被垃圾回收(GC)。
应该使用如下转换方式:
func main() { s := "脑子进煎鱼了" v := string2bytes1(s) fmt.Println(v) } func string2bytes1(s string) []byte { stringHeader := (*reflect.StringHeader)(unsafe.Pointer(&s)) var b []byte pbytes := (*reflect.SliceHeader)(unsafe.Pointer(&b)) pbytes.Data = stringHeader.Data pbytes.Len = stringHeader.Len pbytes.Cap = stringHeader.Len return b }
在程序必须保留一个单独的、正确类型的指向底层数据的指针。
在性能方面,若只是期望单纯的转换,对容量(cap)等字段值不敏感,也可以使用以下方式:
func string2bytes2(s string) []byte { return *(*[]byte)(unsafe.Pointer(&s)) }
性能对比:
string2bytes1-1000-4 3.746 ns/op 0 allocs/op string2bytes1-1000-4 3.713 ns/op 0 allocs/op string2bytes1-1000-4 3.969 ns/op 0 allocs/op string2bytes2-1000-4 2.445 ns/op 0 allocs/op string2bytes2-1000-4 2.451 ns/op 0 allocs/op string2bytes2-1000-4 2.455 ns/op 0 allocs/op
会相当标准的转换性能会稍快一些,这种强转也会导致一个小问题。
代码如下:
func main() { s := "脑子进煎鱼了" v := string2bytes2(s) println(len(v), cap(v)) } func string2bytes2(s string) []byte { return *(*[]byte)(unsafe.Pointer(&s)) }
输出结果:
18 824633927632
这种强转其会导致 byte 的切片容量非常大,需要特别注意。一般还是推荐使用标准的 SliceHeader、StringHeader 方式就好了,也便于后来的维护者理解。
总结
在这篇文章中,我们介绍了字符串(string)和切片(slice)的两个运行时表现,分别是 StringHeader 和 SliceHeader。
同时了解到其运行时表现后,我们还针对其两者的地址指向,常见坑进行了说明。
最后我们进一步深入,面向 0 拷贝转换的场景进行了介绍和性能分析。
参考
- Go语言slice的本质-SliceHeader
- 数组、字符串和切片
- 零拷贝实现string 和bytes的转换疑问
今天带大家了解了结构体、SliceHeader、StringHeader的相关知识,希望对你有所帮助;关于Golang的技术知识我们会一点点深入介绍,欢迎大家关注golang学习网公众号,一起学习编程~
-
377 收藏
-
125 收藏
-
201 收藏
-
183 收藏
-
440 收藏
-
367 收藏
-
419 收藏
-
234 收藏
-
155 收藏
-
457 收藏
-
309 收藏
-
- 前端进阶之JavaScript设计模式
- 设计模式是开发人员在软件开发过程中面临一般问题时的解决方案,代表了最佳的实践。本课程的主打内容包括JS常见设计模式以及具体应用场景,打造一站式知识长龙服务,适合有JS基础的同学学习。
- 立即学习 542次学习
-
- GO语言核心编程课程
- 本课程采用真实案例,全面具体可落地,从理论到实践,一步一步将GO核心编程技术、编程思想、底层实现融会贯通,使学习者贴近时代脉搏,做IT互联网时代的弄潮儿。
- 立即学习 507次学习
-
- 简单聊聊mysql8与网络通信
- 如有问题加微信:Le-studyg;在课程中,我们将首先介绍MySQL8的新特性,包括性能优化、安全增强、新数据类型等,帮助学生快速熟悉MySQL8的最新功能。接着,我们将深入解析MySQL的网络通信机制,包括协议、连接管理、数据传输等,让
- 立即学习 497次学习
-
- JavaScript正则表达式基础与实战
- 在任何一门编程语言中,正则表达式,都是一项重要的知识,它提供了高效的字符串匹配与捕获机制,可以极大的简化程序设计。
- 立即学习 487次学习
-
- 从零制作响应式网站—Grid布局
- 本系列教程将展示从零制作一个假想的网络科技公司官网,分为导航,轮播,关于我们,成功案例,服务流程,团队介绍,数据部分,公司动态,底部信息等内容区块。网站整体采用CSSGrid布局,支持响应式,有流畅过渡和展现动画。
- 立即学习 484次学习
-
- 热心的玫瑰
- 这篇博文真是及时雨啊,很详细,写的不错,收藏了,关注楼主了!希望楼主能多写Golang相关的文章。
- 2023-01-11 04:15:06
-
- 包容的雪糕
- 很有用,一直没懂这个问题,但其实工作中常常有遇到...不过今天到这,看完之后很有帮助,总算是懂了,感谢作者大大分享技术文章!
- 2023-01-09 19:50:32
-
- 现实的小笼包
- 感谢大佬分享,一直没懂这个问题,但其实工作中常常有遇到...不过今天到这,帮助很大,总算是懂了,感谢老哥分享技术文章!
- 2023-01-01 06:07:16
-
- 贤惠的蜻蜓
- 这篇技术文章真是及时雨啊,太细致了,感谢大佬分享,收藏了,关注老哥了!希望老哥能多写Golang相关的文章。
- 2023-01-01 05:52:43
-
- 纯情的热狗
- 这篇技术贴真是及时雨啊,作者大大加油!
- 2022-12-30 02:21:50
-
- 甜蜜的水壶
- 这篇博文出现的刚刚好,好细啊,很有用,mark,关注作者了!希望作者能多写Golang相关的文章。
- 2022-12-28 06:43:56
-
- 能干的外套
- 太细致了,已收藏,感谢up主的这篇博文,我会继续支持!
- 2022-12-27 16:34:06
-
- 清脆的中心
- 很好,一直没懂这个问题,但其实工作中常常有遇到...不过今天到这,看完之后很有帮助,总算是懂了,感谢作者分享博文!
- 2022-12-27 12:22:18
-
- 生动的小鸭子
- 这篇博文太及时了,太详细了,很棒,mark,关注老哥了!希望老哥能多写Golang相关的文章。
- 2022-12-27 10:01:17
-
- 微笑的长颈鹿
- 这篇技术文章太及时了,太全面了,赞 👍👍,码住,关注大佬了!希望大佬能多写Golang相关的文章。
- 2022-12-26 09:51:09
-
- 大气的花卷
- 受益颇多,一直没懂这个问题,但其实工作中常常有遇到...不过今天到这,帮助很大,总算是懂了,感谢作者分享博文!
- 2022-12-25 09:07:15
-
- 曾经的滑板
- 太细致了,mark,感谢up主的这篇技术文章,我会继续支持!
- 2022-12-24 01:29:20