大家好，我是程序員幽鬼。分享一篇關于 map 和“內存泄露”的文章。

摘要：map 總是可以在內存中增長；它從不收縮。因此，如果它導致一些內存問題，你可以嘗試不同的選項，例如強制 Go 重新創建 map 或使用指針。

在 Go 中使用 map 時，我們需要了解 map 如何增長和收縮的一些重要特征。讓我們深入研究一下，以防止可能導致內存泄漏的問題。

首先，要查看此問題的具體示例，讓我們設計一個場景，其中我們將使用以下 map：

每個m值都是一個 128 字節的數組。我們將執行以下操作：

• 分配一個空的 map。
• 添加 100 萬個元素。
• 刪除所有元素，并運行垃圾收集（GC）。

在每一步之后，我們都要打印堆的大小（使用printAlloc實用程序函數）。它向我們展示了此示例的內存行為：

() {
    n := 1_000_000
    m := make([][128])
    printAlloc()

     i := 0; i < n; i++ { // Adds 1 million elements
        m[i] = [128]{}
    }
    printAlloc()

     i := 0; i < n; i++ { // Deletes 1 million elements
        delete(m, i)
    }

    runtime.GC() // Triggers a manual GC
    printAlloc()
    runtime.KeepAlive(m) // Keeps a reference to m so that the map isn’t collected
}

 () {
     m runtime.MemStats
    runtime.ReadMemStats(&m)
    fmt.Printf("%d KB\n", m.Alloc/1024)
}

我們分配一個空 map，添加 100 萬個元素，刪除 100 萬個元素，然后運行 GC。我們還確保使用 [1] 保持對 map 的引用，這樣 map 就不會被垃圾收集了。讓我們運行這個示例：

0 MB <-- m 被分配后
461 MB <-- 我們增加 100 萬個元素后
293 MB <-- 我們刪除 100 萬個元素后

我們能觀察到什么？首先，堆大小是最小的。然后，在向 map 添加了100萬個元素后，它會顯著增長。但是，如果我們預期在刪除所有元素后堆大小會減小，那么這并不是 map 在Go中的工作方式。最后，即使 GC 已經收集了所有元素，堆大小仍然是 293 MB。因此，內存雖然縮小了，但并不像我們預期的那樣。原因是什么？我們需要深入研究 map 在Go中的工作原理。

map 提供了鍵-值對的無序集合，其中所有鍵都是不同的。在 Go 中，map 基于哈希表數據結構：一個數組，其中每個元素都是指向一個鍵值對桶的指針，如圖 1 所示。

圖1— 一個哈希表示例，重點放在 bucket 0 上。

每個 bucket 是一個由八個元素組成的固定大小數組。如果插入到已經滿了的 bucket 中（bucket 溢出），Go 會創建另一個包含八個元素的 buckets，并將前一個元素鏈接到該bucket。圖 2 顯示了一個示例：

圖 2 — 如果 bucket 溢出，Go 會分配一個新的 bucket，并將前一個 bucket 鏈接到該bucket。

在底層，Go map 是指向 [2] 結構體的指針。此結構體包含多個字段，包括一個 B 字段，用于提供 map 中的存儲桶數：

hmap  {
    B  // log_2 of # of buckets
            // (can hold up to loadFactor * 2^B items)
    // ...
}

添加 100 萬個元素后，B 的值等于 18，即 21? = 262144 個桶。當我們移除 100 萬個元素時，B 的值是多少？仍然是18。因此，map 仍然包含相同數量的桶。

原因是 map 中的存儲桶數無法縮減。因此，從 map 中刪除元素不會影響現有存儲桶的數量；它只是將桶中的槽清零。map 只能增長并有更多的桶；它從不收縮。

在前一個示例中，我們從 461MB 到 293MB，因為垃圾收集了元素，但運行 GC 不會影響 map 本身。即使額外的存儲桶數（由于溢出而創建的存儲桶）也保持不變。

讓我們后退一步，討論 map 不能收縮的事實何時會成為問題。想象一下，使用 map[int][128]byte 構建緩存。此 map 包含每個客戶 ID（int 類型），一個 128 字節的序列。現在，假設我們想保留最后 1000 名客戶。map 大小將保持不變，因此我們不必擔心 map 無法收縮的事實。

然而，假設我們要存儲一小時的數據。與此同時，我們公司決定對黑色星期五進行一次大促銷：一個小時后，我們的系統可能會連接到數百萬客戶。但在黑色星期五之后的幾天，我們的 map 將包含與高峰時段相同數量的桶。這就解釋了為什么在這種情況下，我們可以體驗到內存消耗很高，但沒有顯著減少。

如果我們不想手動重啟服務來清理 map 消耗的內存量，有什么解決方案？一種解決方案可以是定期重新創建當前 map 的副本。例如，每小時，我們可以構建一個新 map，復制所有元素，然后發布上一個元素。此選項的主要缺點是，在復制之后直到下一次垃圾回收之前，我們可能會在短時間內消耗兩倍于當前內存的內存。

另一個解決方案是更改 map 類型以存儲數組指針：map[int]*[128]byte。這并不能解決我們將擁有大量桶的事實；然而，每個 bucket 條目將為該值保留指針的大小，而不是 128 字節（64 位系統為 8 字節，32 位系統為 4 字節）。

回到最初的場景，讓我們在每個步驟之后比較每個 map 類型的內存消耗。下表顯示了比較。

正如我們所看到的，刪除所有元素后，使用map[int]*[128]byte類型所需的內存量明顯減少。此外，在這種情況下，由于進行了一些優化以減少所消耗的內存，在峰值時間內所需的內存量不太重要。

注意: 如果一個鍵或值超過 128 字節，Go 不會將其直接存儲在 map bucket 中。相反，Go 存儲一個指針來引用鍵或值。

結論

正如我們所看到的，將 n 個元素添加到 map 中，然后刪除所有元素意味著在內存中保留相同數量的 bucket。因此，我們必須記住，因為 Go map 只能增加大小，所以它的內存消耗也會增加。沒有自動化的策略來縮小它。如果這導致高內存消耗，我們可以嘗試不同的選項，例如強制 Go 重新創建 map 或使用指針檢查是否可以優化。

原文鏈接：https://teivah.medium.com/maps-and-memory-leaks-in-go-a85ebe6e7e69。

參考資料

[1]runtime.KeepAlive: https://pkg.go.dev/runtime#KeepAlive

[2]runtime.hmap: https://github.com/golang/go/blob/f983a9340d5660a9655b63a371966b5df69be8c5/src/runtime/map.go#L116