Go 數(shù)組比切片好在哪？
本文轉(zhuǎn)載自微信公眾號「腦子進(jìn)煎魚了」，作者陳煎魚。轉(zhuǎn)載本文請聯(lián)系腦子進(jìn)煎魚了公眾號。
大家好，我是煎魚。
前段時(shí)間有播放一條快訊，就是 Go1.17 會正式支持切片(Slice)轉(zhuǎn)換到數(shù)據(jù)(Array)，不再需要用以前那種騷辦法了，安全了許多。
但是也有同學(xué)提出了新的疑惑，在 Go 語言中，數(shù)組其實(shí)是用的相對較少的，甚至?xí)型瑢W(xué)認(rèn)為在 Go 里可以把數(shù)組給去掉。
數(shù)組相較切片到底有什么優(yōu)勢，我們又應(yīng)該在什么場景下使用呢?
這是一個(gè)我們需要深究的問題，因此今天就跟大家一起來一探究竟，本文會先簡單介紹數(shù)組和切片是什么，再進(jìn)一步對數(shù)組的使用場景剖析。
一起愉快地開始吸魚之路。
數(shù)組是什么
Go 語言中有一種基本數(shù)據(jù)類型，叫數(shù)組。其格式為：[n]T。是一個(gè)包含 N 個(gè)類型 T 的值的數(shù)組。
基本聲明格式為：
- var a [10]int
代表的是聲明了一個(gè)變量 a 是一個(gè)包含 10 個(gè)整數(shù)的數(shù)組。數(shù)組的長度是其類型的一部分，所以數(shù)組不能被隨意調(diào)整大小。
在使用例子上：
- func main() {
- var a [2]string
- a[0] = "腦子進(jìn)"
- a[1] = "煎魚了"
- fmt.Println(a[0], a[1])
- fmt.Println(a)
- primes := [6]int{2, 3, 5, 7, 11, 13}
- fmt.Println(primes)
- }
輸出結(jié)果：
- 腦子進(jìn) 煎魚了
- [腦子進(jìn) 煎魚了]
- [2 3 5 7 11 13]
在賦值和訪問上，數(shù)組可以針對不同的索引，進(jìn)行單獨(dú)操作。在內(nèi)存布局上，數(shù)組的索引 0 和 1...是會在相鄰區(qū)域，可直接訪問。
切片是什么
為什么數(shù)組在業(yè)務(wù)代碼似乎用的很少。因?yàn)?Go 語言有一個(gè)切片的數(shù)據(jù)類型：
基本聲明格式為：
- var a []T
代表的是變量 a 是帶有類型元素的切片T。通過指定兩個(gè)索引(下限和上限)并用冒號隔開來形成切片：
- a[low : high]
在使用例子上：
- func main() {
- primes := [3]string{"煎魚", "搞", "Go"}
- var s []string = primes[1:3]
- fmt.Println(s)
- }
輸出結(jié)果：
- [搞 Go]
切片支持動態(tài)的擴(kuò)縮容，不需要用戶側(cè)去關(guān)注，非常便利。更重要的一點(diǎn)是，切片的底層數(shù)據(jù)結(jié)構(gòu)中本身就包含了數(shù)組：
- type slice struct {
- array unsafe.Pointer
- len int
- cap int
- }
也就很多人笑稱：在 Go 語言中數(shù)組已經(jīng)可以下崗了，用切片就完事了...
你怎么看待這個(gè)說法的呢，快速思考你心中的答案。
數(shù)組的優(yōu)勢
在風(fēng)塵仆仆介紹完數(shù)組和切片的基本場景后，在數(shù)組的優(yōu)勢方面，先了解一下官方的自述：
Arrays are useful when planning the detailed layout of memory and sometimes can help avoid allocation, but primarily they are a building block for slices.
非常粗暴間接：在規(guī)劃內(nèi)存的詳細(xì)布局時(shí)，數(shù)組是很有用的，有時(shí)可以幫助避免分配，但主要是它們是分片的構(gòu)建塊。
我們再進(jìn)一步解讀，看看官方這股 “密文” 具體指的是什么，我們將該密文解讀為以下內(nèi)容進(jìn)行講解：
- 可比較。
- 編譯安全。
- 長度是類型。
- 規(guī)劃內(nèi)存布局。
- 訪問速度。
可比較
數(shù)組是固定長度的，它們之間是可以進(jìn)行比較的，數(shù)組是值對象(不是引用或指針類型)，你不會遇到 interface 等比較的誤判：
- func main() {
- a1 := [3]string{"腦子", "進(jìn)", "煎魚了"}
- a2 := [3]string{"煎魚", "進(jìn)", "腦子了"}
- a3 := [3]string{"腦子", "進(jìn)", "煎魚了"}
- fmt.Println(a1 == a2, a1 == a3)
- }
輸出結(jié)果：
- false true
另一方面，切片不可以直接比較，也不能用于判斷：
- func main() {
- a1 := []string{"腦子", "進(jìn)", "煎魚了"}
- a2 := []string{"煎魚", "進(jìn)", "腦子了"}
- a3 := []string{"腦子", "進(jìn)", "煎魚了"}
- fmt.Println(a1 == a2, a1 == a3)
- }
輸出結(jié)果：
- # command-line-arguments
- ./main.go:10:17: invalid operation: a1 == a2 (slice can only be compared to nil)
- ./main.go:10:27: invalid operation: a1 == a3 (slice can only be compared to nil)
同時(shí)數(shù)組可以作為 map 的 k(鍵)，而切片不行，切片并沒有實(shí)現(xiàn)平等運(yùn)算符(equality operator)，需要考慮的問題有非常多，例如：
- 涉及淺層與深層比較。
- 指針與值比較。
- 如何處理遞歸類型。
平等是為結(jié)構(gòu)體和數(shù)組定義的，所以這類類型可以作為 map 鍵使用。切片沒有平等的定義，有著非常根本的差距。
數(shù)組的可比較和平等，切片做不到。
編譯安全
數(shù)組可以提供更高的編譯時(shí)安全，可以在編譯時(shí)檢查索引范圍。如下：
- s := make([]int, 3)
- s[3] = 3 // "Only" a runtime panic: runtime error: index out of range
- a := [3]int{}
- a[3] = 3 // Compile-time error: invalid array index 3 (out of bounds for 3-element array)
這個(gè)編譯檢查的幫助雖 “小”，但其實(shí)非常有意義。我是日常看到各大切片越界的告警，感覺都能背下來了...
萬一這個(gè)越界是在 hot path 上，影響大量用戶，分分鐘背個(gè)事故，再來個(gè) 3.25，豈不夢中驚醒?
數(shù)組的編譯安全，切片做不到。
長度是類型
數(shù)組的長度是數(shù)組類型聲明的一部分，因此長度不同的數(shù)組是不同的類型，兩個(gè)就不是一個(gè) “東西”。
當(dāng)然，這是一把雙刃劍。其優(yōu)勢在于：可用于顯式指定所需數(shù)組的長度。
例如：你在業(yè)務(wù)代碼中想編寫一個(gè)使用 IPv4 地址的函數(shù)?？梢月暶?type [4]byte。使用數(shù)組有以下意識：
有了編譯時(shí)的保證，也就是達(dá)到傳遞給你的函數(shù)的值將恰好具有4個(gè)字節(jié)，不多也不少的效果。
如果長度不對，也就可以認(rèn)為是無效的 IPv4 地址，非常方便。
同時(shí)數(shù)組的長度，也可以用做記錄目的：
MD5 類型，在 crypto/md5包中，md5.Sum 方法返回類型為的值，[Size]byte 其中 md5.Size 一個(gè)常量為16：MD5 校驗(yàn)和的長度。
IPv4 類型，所聲明的 [4]byte 正確記錄了有 4 個(gè)字節(jié)。
RGB 類型，所聲明的 [3]byte 告訴有對每個(gè)顏色成分 1 個(gè)字節(jié)。
在特定業(yè)務(wù)場景上，使用數(shù)組更好。
規(guī)劃內(nèi)存布局
數(shù)組可以更好地控制內(nèi)存布局，因?yàn)椴荒苤苯釉趲в星衅慕Y(jié)構(gòu)中分配空間，所以可以使用數(shù)組來解決。
例如：
- type Foo struct {
- buf [64]byte
- }
不知道你是否有在一些 Go 圖形庫上見過這種不明所以的操作，例子如下：
- type TGIHeader struct {
- _ uint16 // Reserved
- _ uint16 // Reserved
- Width uint32
- Height uint32
- _ [15]uint32 // 15 "don't care" dwords
- SaveTime int64
- }
因?yàn)闃I(yè)務(wù)需求，我們需要實(shí)現(xiàn)一個(gè)格式，其中格式是 "TGI"(理論上的Go Image)，頭包含這樣的字段：
- 有 2 個(gè)保留字(每個(gè)16位)。
- 有 1 個(gè)字的圖像寬度。
- 有 1 個(gè)字的圖像高度。
- 有 15 個(gè)業(yè)務(wù) "不在乎 "的字節(jié)。
- 有 1 個(gè)保存時(shí)間，圖像的保存時(shí)間為8字節(jié)，是自1970年1月1日UTC以來的納秒數(shù)。
這么一看，也就不難理解數(shù)組的在這個(gè)場景下的優(yōu)勢了。定長，可控的內(nèi)存，在計(jì)劃內(nèi)存布局時(shí)非常有用。
訪問速度
使用數(shù)組時(shí)，其訪問(單個(gè))數(shù)組元素比訪問切片元素更高效，時(shí)間復(fù)雜度是 O(1)。例如：
- var a [2]string
- a[0] = "腦子進(jìn)"
- a[1] = "煎魚了"
- fmt.Println(a[0], a[1])
切片就沒那么方便了，訪問某個(gè)位置上的索引值，需要：
- var a []int{0, 1, 2, 3, 4, 5}
- number := numbers[1:3]
相對復(fù)雜些的，刪除指定索引位上的值，可能還有小伙伴糾結(jié)半天，甚至在找第三方開源庫想快速實(shí)現(xiàn)。
無論在訪問速度和開發(fā)效率上，數(shù)組都占一定的優(yōu)勢，這是切片所無法直接對比的。
總結(jié)
經(jīng)過一輪的探討，我們對 Go 語言的數(shù)組有了更深入的理解。總結(jié)如下：
數(shù)組是值對象，可以進(jìn)行比較，可以將數(shù)組用作 map 的映射鍵。而這些，切片都不可以，不能比較，無法作為 map 的映射鍵。
數(shù)組有編譯安全的檢查，可以在早起就避免越界行為。切片是在運(yùn)行時(shí)會出現(xiàn)越界的 panic，階段不同。
數(shù)組可以更好地控制內(nèi)存布局，若拿切片替換，會發(fā)現(xiàn)不能直接在帶有切片的結(jié)構(gòu)中分配空間，數(shù)組可以。
數(shù)組在訪問單個(gè)元素時(shí)，性能比切片好。
數(shù)組的長度，是類型的一部分。在特定場景下具有一定的意義。
數(shù)組是切片的基礎(chǔ)，每個(gè)數(shù)組都可以是一個(gè)切片，但并非每個(gè)切片都可以是一個(gè)數(shù)組。如果值是固定大小，可以通過使用數(shù)組來獲得較小的性能提升(至少節(jié)省 slice 頭占用的空間)。
與你心目中的數(shù)組的優(yōu)勢是否一致呢，歡迎大家在評論區(qū)進(jìn)行討論和交流。
我是煎魚，咱們下期再見：)
參考
In GO programming language what are the benefits of using Arrays over Slices?
Why have arrays in Go?
