1. 什麼是邊界檢查？
邊界檢查，英文名 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" demo.go
# command-line-arguments
./demo.go:4:7: Found IsInBounds
./demo.go:5:7: Found IsInBounds
./demo.go:6:7: Found IsInBounds
2. 邊界檢查的條件？
並不是所有的對陣列、切片進行索引操作都需要邊界檢查。
比如下面這個示例，就不需要進行邊界檢查，因為編譯器根據上下文已經得知，s 這個切片的長度是多少，你的終止索引是多少，立馬就能判斷到底有沒有越界，因此是不需要再進行邊界檢查，因為在編譯的時候就已經知道這個地方會不會 panic。
package main
func f1() {
s := []int{1, 2, 3, 4}
_ = s[:9] // 不需要邊界檢查
}
func main() {}
因此可以得出結論: 對於在編譯階段無法判斷是否會越界的索引操作才會需要邊界檢查
比如這樣子
package main
func f(s []int) {
_ = s[:9] // 需要邊界檢查
}
func main() {}
3. 邊界檢查的特殊案例
3.1 案例一
在如下示例程式碼中，由於索引 2 在最前面已經檢查過會不會越界，因此聰明的編譯器可以推斷出後面的索引 0 和 1 不用再檢查啦
package main
func f(s []int) {
_ = s[2] // 檢查一次
_ = s[1] // 不會檢查
_ = s[0] // 不會檢查
}
func main() {}
3.2 案例二
在下面這個示例中，可以在邏輯上保證不會越界的程式碼，同樣是不會進行越界檢查的。
package main
func f(s []int) {
for index, _ := range s {
_ = s[index]
_ = s[:index+1]
_ = s[index:len(s)]
}
}
func main() {}
3.3 案例三
在如下示例程式碼中，雖然陣列的長度和容量可以確定，但是索引是通過 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:] 也成立，因為要檢查兩次才可以
3.4 案例四
有了上面的鋪墊，再來看下面這個示例，由於陣列是呼叫者傳入的引數，所以編譯器的編譯的時候無法得知陣列的長度和容量是否相等，因此只能保險一點，兩個都檢查。
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() {}
3.5. 主動消除邊界檢查
雖然編譯器已經非常努力去消除一些應該消除的邊界檢查，但難免會有一些遺漏。
這就需要”警民合作”，對於那些編譯器還未考慮到的場景，但開發者又極力追求程式的執行效率的，可以使用一些小技巧給出一些暗示，告訴編譯器哪些地方可以不用做邊界檢查。
比如下面這個示例，從程式碼的邏輯上來說，是完全沒有必要做邊界檢查的，但是編譯器並沒有那麼智慧，實際上每個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() {}
3.6 邊界檢查對效能的影響
一直在討論邊界檢查對效能的影響，但是到底影響有多大呢？ 不妨以上面的例子做一個基準測試
package main
import "testing"
func f4(is []int, bs []byte) {
if len(is) >= 256 {
for _, n := range bs {
_ = is[n] // 每個迴圈都要邊界檢查
}
}
}
func f5(is []int, bs []byte) {
if len(is) >= 256 {
for _, n := range bs {
is = is[:256]
_ = is[n] // 每個迴圈都要邊界檢查
}
}
}
func BenchmarkFunc_f4_test(b *testing.B) {
s := make([]int, 1000, 10000000)
bs := []byte{'b', 'a', 'c', 'd', 'e', 'g', 'h', 'j'}
for i := 0; i < b.N; i++ {
f4(s, bs)
}
}
func BenchmarkFunc_f5_test(b *testing.B) {
s := make([]int, 1000, 10000000)
bs := []byte{'b', 'a', 'c', 'd', 'e', 'g', 'h', 'j'}
for i := 0; i < b.N; i++ {
f5(s, bs)
}
}
執行基準測試結果如下：
go test -bench=. -benchmem
goos: linux
goarch: amd64
pkg: Go_base/daily_test/bce_demo
BenchmarkFunc_f4_test-8 179074254 6.33 ns/op 0 B/op 0 allocs/op
BenchmarkFunc_f5_test-8 208692784 5.82 ns/op 0 B/op 0 allocs/op
PASS
ok Go_base/daily_test/bce_demo 3.253s
如上結果，隨著for迴圈次數的增加，其效能有了明顯的差異，對於小的切片，陣列操作時可能效果並不是很明顯，但是如果涉及到資料比較大，或者效能比較嚴苛的地方，避免邊界檢查還是很有必要的。