為什麼 Go 中 `unsafe.Sizeof()` 在 `map[string]bool` 和 `map[string]string` 之間沒有顯示記憶體差異？

Go 中的字串記憶體使用

許多開發人員在優化Go 中涉及映射和字串的程式碼時遇到了令人驚訝的觀察。映射是 Go 中的基本資料結構，值類型的選擇會顯著影響效能。

在映射儲存大量元素（5000 萬）的場景中，每個元素的值可以是“ A”或“B”，在map[string]string 上使用map[string]bool 似乎是合乎邏輯的。然而，與預期相反，使用 unsafe.Sizeof() 測量這些映射的記憶體消耗並沒有發現任何差異。

理解結果

解開這個謎團的關鍵明顯的悖論在於理解 unsafe.Sizeof() 在 Go 中如何運作。 unsafe.Sizeof() 測量值的淺層大小，這意味著它只考慮值本身的大小，而不考慮值引用的任何記憶體。

在 Go 中，映射是作為指標實現的，這解釋了unsafe.Sizeof() 報告的map[string]bool 和map[string]string 的大小一致。兩個映射都只是保存一個指向包含鍵值對的實際資料結構的指標。

Go 中的字串比較複雜。它們由包含指向底層位元組序列及其長度的指標的標頭表示。 unsafe.Sizeof() 測量此標頭的大小，無論字串的長度如何，它都保持不變。

深入研究記憶體消耗

取得更多要準確測量一張地圖的記憶體需求，就必須深入研究資料結構。這可以透過反射來實現，如 StackOverflow 線程「Go 映射保留多少記憶體？」所示。

對於字串，實際的記憶體使用量可以計算為字串的位元組長度與字串的位元組長度總和。字串頭的大小。

最佳化字串記憶體

考慮由於記憶體浪費的可能性是至關重要的到字串切片。建立字串切片時，它會繼承對原始字串的支援數組的參考。因此，即使不再使用原始字串，後備數組仍保留在記憶體中以支援字串切片。

總之，優化 Go 中的字串記憶體使用涉及了解映射和字串的底層記憶體佈局，並採用盡量減少不必要的記憶保留的技術。

以上是為什麼 Go 中 `unsafe.Sizeof()` 在 `map[string]bool` 和 `map[string]string` 之間沒有顯示記憶體差異？的詳細內容。更多資訊請關注PHP中文網其他相關文章！