边界检查,英文名 Bounds Check Elimination,简称为 BCE。它是 Go 语言中防止数组、切片越界而导致内存不安全的检查手段。如果检查下标已经越界了,就会产生 Panic。
创新互联公司是一家集网站建设,普宁企业网站建设,普宁品牌网站建设,网站定制,普宁网站建设报价,网络营销,网络优化,普宁网站推广为一体的创新建站企业,帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿,时刻以成就客户成长自我,坚持不断学习、思考、沉淀、净化自己,让我们为更多的企业打造出实用型网站。
边界检查使得我们的代码能够安全地运行,但是另一方面,也使得我们的代码运行效率略微降低。
比如下面这段代码,会进行三次的边界检查
- package main
- func f(s []int) {
- _ = s[0] // 检查第一次
- _ = s[1] // 检查第二次
- _ = s[2] // 检查第三次
- }
- func main() {}
你可能会好奇了,三次?我是怎么知道它要检查三次的。
实际上,你只要在编译的时候,加上参数即可,命令如下
- $ go build -gcflags="-d=ssa/check_bce/debug=1" main.go
- # command-line-arguments
- ./main.go:4:7: Found IsInBounds
- ./main.go:5:7: Found IsInBounds
- ./main.go:6:7: Found IsInBounds
并不是所有的对数组、切片进行索引操作都需要边界检查。
比如下面这个示例,就不需要进行边界检查,因为编译器根据上下文已经得知,s 这个切片的长度是多少,你的终止索引是多少,立马就能判断到底有没有越界,因此是不需要再进行边界检查,因为在编译的时候就已经知道这个地方会不会 panic。
- package main
- func f() {
- s := []int{1,2,3,4}
- _ = s[:9] // 不需要边界检查
- }
- func main() {}
因此可以得出结论,对于在编译阶段无法判断是否会越界的索引操作才会需要边界检查,比如这样子
- package main
- func f(s []int) {
- _ = s[:9] // 需要边界检查
- }
- func main() {}
在如下示例代码中,由于索引 2 在最前面已经检查过会不会越界,因此聪明的编译器可以推断出后面的索引 0 和 1 不用再检查啦
- package main
- func f(s []int) {
- _ = s[2] // 检查一次
- _ = s[1] // 不会检查
- _ = s[0] // 不会检查
- }
- func main() {}
在下面这个示例中,可以在逻辑上保证不会越界的代码,同样是不会进行越界检查的。
- package main
- func f(s []int) {
- for index, _ := range s {
- _ = s[index]
- _ = s[:index+1]
- _ = s[index:len(s)]
- }
- }
- func main() {}
在如下示例代码中,虽然数组的长度和容量可以确定,但是索引是通过 rand.Intn() 函数取得的随机数,在编译器看来这个索引值是不确定的,它有可能大于数组的长度,也有可能小于数组的长度。
因此第一次是需要进行检查的,有了第一次检查后,第二次索引从逻辑上就能推断,所以不会再进行边界检查。
- package main
- import (
- "math/rand"
- )
- func f() {
- s := make([]int, 3, 3)
- index := rand.Intn(3)
- _ = s[:index] // 第一次检查
- _ = s[index:] // 不会检查
- }
- func main() {}
但如果把上面的代码稍微改一下,让切片的长度和容量变得不一样,结果又会变得不一样了。
- package main
- import (
- "math/rand"
- )
- func f() {
- s := make([]int, 3, 5)
- index := rand.Intn(3)
- _ = s[:index] // 第一次检查
- _ = s[index:] // 第二次检查
- }
- func main() {}
我们只有当数组的长度和容量相等时, :index 成立,才能一定能推出 index: 也成立,这样的话,只要做一次检查即可
一旦数组的长度和容量不相等,那么 index 在编译器看来是有可能大于数组长度的,甚至大于数组的容量。
我们假设 index 取得的随机数为 4,那么它大于数组长度,此时 s[:index] 虽然可以成功,但是 s[index:] 是要失败的,因此第二次边界的检查是有必要的。
你可能会说, index 不是最大值为 3 吗?怎么可能是 4呢?
要知道编译器在编译的时候,并不知道 index 的最大值是 3 呢。
小结一下
当数组的长度和容量相等时,s[:index] 成立能够保证 s[index:] 也成立,因为只要检查一次即可
当数组的长度和容量不等时,s[:index] 成立不能保证 s[index:] 也成立,因为要检查两次才可以
有了上面的铺垫,再来看下面这个示例,由于数组是调用者传入的参数,所以编译器的编译的时候无法得知数组的长度和容量是否相等,因此只能保险一点,两个都检查。
- package main
- import (
- "math/rand"
- )
- func f(s []int, index int) {
- _ = s[:index] // 第一次检查
- _ = s[index:] // 第二次检查
- }
- func main() {}
但是如果把两个表达式的顺序反过来,就只要做一次检查就行了,原因我就不赘述了。
- package main
- import (
- "math/rand"
- )
- func f(s []int, index int) {
- _ = s[index:] // 第一次检查
- _ = s[:index] // 不用检查
- }
- func main() {}
虽然编译器已经非常努力去消除一些应该消除的边界检查,但难免会有一些遗漏。
这就需要"警民合作",对于那些编译器还未考虑到的场景,但开发者又极力追求程序的运行效率的,可以使用一些小技巧给出一些暗示,告诉编译器哪些地方可以不用做边界检查。
比如下面这个示例,从代码的逻辑上来说,是完全没有必要做边界检查的,但是编译器并没有那么智能,实际上每个for循环,它都要做一次边界的检查,非常的浪费性能。
- package main
- func f(is []int, bs []byte) {
- if len(is) >= 256 {
- for _, n := range bs {
- _ = is[n] // 每个循环都要边界检查
- }
- }
- }
- func main() {}
可以试着在 for 循环前加上这么一句 is = is[:256] 来告诉编译器新 is 的长度为 256,最大索引值为 255,不会超过 byte 的最大值,因为 is[n] 从逻辑上来说是一定不会越界的。
- package main
- func f(is []int, bs []byte) {
- if len(is) >= 256 {
- is = is[:256]
- for _, n := range bs {
- _ = is[n] // 不需要做边界检查
- }
- }
- }
- func main() {}
本文上面列出的例子并没有涵盖标准编译器支持的所有边界检查消除的情形。本文列出的仅仅是一些常见的情形。
尽管标准编译器中的边界检查消除特性依然不是100%完美,但是对很多常见的情形,它确实很有效。自从标准编译器支持此特性以来,在每个版本更新中,此特性都在不断地改进增强。无需质疑,在以后的版本中,标准编译器会更加得智能,以至于上面第5个例子中提供给编译器的暗示有可能将变得不再必要。谢谢Go语言开发团队出色的工作!
https://gfw.go101.org/article/bounds-check-elimination.html
本文转载自微信公众号「Go编程时光」,作者写代码的明哥。转载本文请联系Go编程时光公众号。
文章题目:这Go的边界检查,简直让人抓狂~
分享路径:http://www.shufengxianlan.com/qtweb/news16/115066.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联