在這篇博客文章中，我們將討論如何通過了解切片在內存中的表示方式以及這對垃圾收集器的影響，更有效地使用slices包中提供的函數。我們還將介紹我們最近如何調整這些函數，使它們變得不那么令人驚訝。

借助類型參數，我們可以為所有類型的切片編寫像slices.Index這樣的函數：

// Index 返回s中v首次出現的索引，
// 如果不存在，則返回-1。
func Index[S ~[]E, E comparable](s S, v E) int {
    for i := range s {
        if v == s[i] {
            return i
        }
    }
    return -1
}

不再需要為每種不同類型的元素再次實現Index。

slices包包含許多這樣的助手函數，用于對切片執行常見操作：

s := []string{"Bat", "Fox", "Owl", "Fox"}
    s2 := slices.Clone(s)
    slices.Sort(s2)
    fmt.Println(s2) // [Bat Fox Fox Owl]
    s2 = slices.Compact(s2)
    fmt.Println(s2)                  // [Bat Fox Owl]
    fmt.Println(slices.Equal(s, s2)) // false

一些新函數（Insert、Replace、Delete等）修改切片。要了解它們是如何工作的，以及如何正確使用它們，我們需要檢查切片的底層結構。

切片是數組一部分的視圖。在內部，切片包含一個指針、一個長度和一個容量。兩個切片可以有相同的底層數組，并且可以查看重疊的部分。

例如，這個切片s是對大小為 6 的數組中 4 個元素的視圖：

如果函數更改了作為參數傳遞的切片的長度，則需要將新的切片返回給調用者。如果不需要增長，底層數組可能保持不變。這解釋了為什么append和slices.Compact返回一個值，但slices.Sort，僅重新排序元素，不返回值。

考慮刪除切片一部分的任務。在泛型出現之前，從切片s中刪除部分s[2:5]的標準方法是調用append函數將結尾部分復制到中間部分：

s = append(s[:2], s[5:]...)

語法復雜且容易出錯，涉及到子切片和可變參數。我們添加了slice.Delete來簡化元素的刪除：

func Delete[S ~[]E, E any](s S, i, j int) S {
       return append(s[:i], s[j:]...)
}

一行函數Delete更清晰地表達了程序員的意圖。考慮長度為 6、容量為 8 的切片s，包含指針：

這個調用從切片s中刪除了s[2]、s[3]、s[4]的元素：

s = slices.Delete(s, 2, 5)

通過向左移動元素s[5]來填補索引 2、3、4 處的空隙，并將新的長度設置為3。

Delete不需要分配新數組，因為它就地移動元素。像append一樣，它返回一個新切片。slices包中的許多其他函數也遵循這種模式，包括Compact、CompactFunc、DeleteFunc、Grow、Insert和Replace。

調用這些函數時，我們必須認為原始切片無效，因為底層數組已經被修改。調用函數但忽略返回值將是一個錯誤：

slices.Delete(s, 2, 5) // 不正確！
    // s的長度仍然相同，但內容被修改了

不希望的生存期問題

在 Go 1.22 之前，slices.Delete并沒有修改新舊切片長度之間的元素。雖然返回的切片不包括這些元素，但在原始的、現在無效的切片的末尾創建的“空隙”繼續保留它們。這些元素可能包含指向大對象（20MB 圖像）的指針，垃圾收集器不會釋放與這些對象關聯的內存。這導致內存泄漏，可能導致嚴重的性能問題。

在上述示例中，我們成功地從s[2:5]中刪除了指針p2、p3、p4，通過將一個元素向左移動。但是p3和p4仍然存在于底層數組中，超出s的新長度。垃圾收集器不會回收它們。更不明顯的是，p5不是被刪除的元素之一，但是由于數組灰色部分保留的p5指針，其內存可能仍然泄漏。

對于開發者來說，如果他們不知道“不可見”的元素仍在占用內存，這可能會令人困惑。

因此，我們有兩個選擇：

? 保持Delete的高效實現。如果用戶想確保指向的值可以被釋放，讓用戶自己將過時的指針設置為nil。

? 或者更改Delete，始終將過時的元素設置為零。這是額外的工作，使得Delete稍微效率低一些。將指針置零（設置為nil）可以在它們變得不可達時啟用對象的垃圾收集。

哪個選項最好并不明顯。第一個默認提供性能，第二個默認提供內存節儉。

解決方案

一個關鍵觀察是，“將過時的指針設置為nil”并不像看起來那么容易。事實上，這項任務是如此容易出錯，以至于我們不應該讓用戶承擔編寫它的負擔。出于實用主義，我們選擇修改Compact、CompactFunc、Delete、DeleteFunc、Replace五個函數的實現，以“清除尾部”。一個好的副作用是，認知負擔減少了，用戶現在不需要擔心這些內存泄漏了。

在 Go 1.22 中，調用 Delete 后，內存看起來像這樣：

五個函數中的代碼改動使用了新的內置函數clear（Go 1.21）將過時元素設置為s元素類型的零值：

當E是指針、切片、映射、通道或接口的類型時，E的零值是nil。

測試失敗

這一變化導致了一些在 Go1.21 中通過的測試在 Go 1.22 中失敗，當切片函數被不正確使用時。這是個好消息。當你有一個 bug 時，測試應該讓你知道。

如果你忽略了Delete的返回值：

slices.Delete(s, 2, 3)  // !! 不正確 !!

那么你可能錯誤地假設s不包含任何 nil 指針。在 Go Playground 中的示例。

如果你忽略了Compact的返回值：

slices.Sort(s) // 正確
slices.Compact(s) // !! 不正確 !!

那么你可能錯誤地假設s已正確排序并壓縮。示例。

如果你將Delete的返回值分配給另一個變量，并繼續使用原始切片：

u := slices.Delete(s, 2, 3)  // !! 不正確，如果你繼續使用s !!

那么你可能錯誤地假設s不包含任何 nil 指針。示例。

如果你意外地遮蔽了切片變量，并繼續使用原始切片：

s := slices.Delete(s, 2, 3)  // !! 不正確，使用:=而不是= !!

那么你可能錯誤地假設s不包含任何 nil 指針。示例。

結論

slices包的 API 相比傳統的預泛型語法來刪除或插入元素有所改進。

我們鼓勵開發者使用新函數，同時避免上述列出的“陷阱”。

得益于最近實現的變更，一類內存泄漏被自動避免，無需對 API 進行任何更改，也不需要開發者做額外工作。