正文

除非您正在對服務進行原型設計，否則您可能會關心應用程序的內(nèi)存使用情況。占用更小的內(nèi)存，會使基礎設施成本降低，擴展變得更容易。盡管 Go 以不消耗大量內(nèi)存而聞名，但仍有一些方法可以進一步減少消耗。其中一些需要大量重構，但很多都很容易做到。

預先分配切片

要理解這種優(yōu)化，我們必須了解切片在 Go 中是如何工作的，為此我們必須首先了解數(shù)組。

go.dev 上有一篇非常好的關于這個主題的文章。

數(shù)組是具有連續(xù)內(nèi)存的相同類型的集合。數(shù)組類型定義時要指定長度和元素類型。

因為數(shù)組的長度是它們類型的一部分，數(shù)組的主要問題是它們大小固定，不能調(diào)整。

與數(shù)組類型不同，切片類型無需指定長度。切片的聲明方式與數(shù)組相同，但沒有數(shù)量元素。

切片是數(shù)組的包裝器，它們不擁有任何數(shù)據(jù)——它們是對數(shù)組的引用。它們由指向數(shù)組的指針、長度及其容量（底層數(shù)組中的元素數(shù)）組成。

當您向沒有足夠容量的切片添加一個新值時 - 會創(chuàng)建一個具有更大容量的新數(shù)組，并將當前數(shù)組中的值復制到新數(shù)組中。這會導致不必要的內(nèi)存分配和 CPU 周期。

為了更好地理解這一點，讓我們看一下以下代碼段：

func?main()?{
????var?ints?[]int
????for?i?:=?0;?i?<?5;?i++?{
????????ints?=?append(ints,?i)
????????fmt.Printf("Address:?%p,?Length:?%d,?Capacity:?%d,?Values:?%v\n",
????????????ints,?len(ints),?cap(ints),?ints)
????}
}

輸出：

Address: 0xc000018030, Length: 1, Capacity: 1, Values: [0]
Address: 0xc000018050, Length: 2, Capacity: 2, Values: [0 1]
Address: 0xc000082020, Length: 3, Capacity: 4, Values: [0 1 2]
Address: 0xc000082020, Length: 4, Capacity: 4, Values: [0 1 2 3]
Address: 0xc000084040, Length: 5, Capacity: 8, Values: [0 1 2 3 4]

憑借輸出結果我們可以得出結論，無論何時必須增加容量（增加 2 倍），都必須創(chuàng)建一個新的底層數(shù)組（新的內(nèi)存地址）并將值復制到新數(shù)組中。

有趣是，當容量<1024 時會漲為之前的 2 倍，當容量>=1024時會以 1.25 倍增長。從 Go 1.18 開始，這已經(jīng)變得更加線性。

Address:?0xc000018030,?Length:?1,?Capacity:?1,?Values:?[0]
Address:?0xc000018050,?Length:?2,?Capacity:?2,?Values:?[0?1]
Address:?0xc000082020,?Length:?3,?Capacity:?4,?Values:?[0?1?2]
Address:?0xc000082020,?Length:?4,?Capacity:?4,?Values:?[0?1?2?3]
Address:?0xc000084040,?Length:?5,?Capacity:?8,?Values:?[0?1?2?3?4]func?BenchmarkAppend(b?*testing.B)?{
????var?ints?[]int
????for?i?:=?0;?i?<?b.N;?i++?{
????????ints?=?append(ints,?i)
????}
}
func?BenchmarkPreallocAssign(b?*testing.B)?{
????ints?:=?make([]int,?b.N)
????for?i?:=?0;?i?<?b.N;?i++?{
????????ints[i]?=?i
????}
}
func?BenchmarkAppend(b?*testing.B)?{
????var?ints?[]int
????for?i?:=?0;?i?<?b.N;?i++?{
????????ints?=?append(ints,?i)
????}
}
func?BenchmarkPreallocAssign(b?*testing.B)?{
????ints?:=?make([]int,?b.N)
????for?i?:=?0;?i?<?b.N;?i++?{
????????ints[i]?=?i
????}
}

name               time/op
Append-10          3.81ns ± 0%
PreallocAssign-10  0.41ns ± 0%

name               alloc/op
Append-10           45.0B ± 0%
PreallocAssign-10   8.00B ± 0%

name               allocs/op
Append-10            0.00
PreallocAssign-10    0.00

由上述基準，我們可以得出結論，將值分配給預分配的切片和將值追加到切片之間是存在很大差異的。

兩個工具有助于切片的預分配：

• prealloc: 一個靜態(tài)分析工具，用于查找可能被預分配的切片聲明。
• makezero: 一個靜態(tài)分析工具，用于查找未以零長度初始化且稍后有追加的切片聲明。

結構體中的字段順序

您之前可能沒有想到這一點，但結構體中字段的順序對內(nèi)存消耗有很大影響。

以下面的結構體為例：

type?Post?struct?{
????IsDraft?????bool??????//?1?byte
????Title???????string????//?16?bytes
????ID??????????int64?????//?8?bytes
????Description?string????//?16?bytes
????IsDeleted???bool??????//?1?byte
????Author??????string????//?16?bytes
????CreatedAt???time.Time?//?24?bytes
}
func?main(){
????p?:=?Post{}
????fmt.Println(unsafe.Sizeof(p))
}

上述的輸出為 96 字節(jié)，而所有字段相加為 82 字節(jié)。那額外的 14 個字節(jié)是來自哪里呢？

現(xiàn)代 64 位 CPU 以 64 位（8 字節(jié)）的塊獲取數(shù)據(jù)。如果我們有一個較舊的 32 位 CPU，它將以 32 位（4 字節(jié)）的塊進行。

第一個周期占用 8 個字節(jié)，拉取“IsDraft”字段占用了 1 個字節(jié)并且產(chǎn)生 7 個未使用字節(jié)。它不能占用“一半”的字段。

第二個和第三個周期取 Title 字符串，第四個周期取 ID，依此類推。到取 IsDeleted 字段時，它使用 1 個字節(jié)并有 7 個字節(jié)未使用。

對內(nèi)存節(jié)省的關鍵是按字段占用大小從上到下對字段進行排序。對上述結構進行排序，大小可減少到 88 個字節(jié)。最后兩個字段 IsDraft 和 IsDeleted 被放在同一個塊中，從而將未使用的字節(jié)數(shù)從 14 (2x7) 減少到 6 (1 x 6)，在此過程中節(jié)省了 8 個字節(jié)。

type?Post?struct?{
????CreatedAt???time.Time?//?24?bytes
????Title???????string????//?16?bytes
????Description?string????//?16?bytes
????Author??????string????//?16?bytes
????ID??????????int64?????//?8?bytes
????IsDraft?????bool??????//?1?byte
????IsDeleted???bool??????//?1?byte
}
func?main(){
????p?:=?Post{}
????fmt.Println(unsafe.Sizeof(p))
}

在 64 位架構上占用小于 8 字節(jié)的 Go 類型：

• bool: 1 個字節(jié)
• int8/uint8: 1 個字節(jié)
• int16/uint16: 2 個字節(jié)
• int32/uint32/rune: 4 個字節(jié)
• float32: 4 個字節(jié)
• byte: 1 個字節(jié)

不需要手動檢查您的結構體并按大小對其進行排序，而是使用 工具找到這些結構并報告“正確”的排序。

• maligned - 已棄用，用于報告未對齊的結構并打印出正確排序的字段。它在一年前被棄用，但您仍然可以安裝舊版本并使用它。
• govet/fieldalignment: gotools 和 govet 的一部分工具，fieldalignment 可打印出未對齊的結構和結構的當前/理想大小。

安裝和運行 fieldalignment：

go?install?golang.org/x/tools/go/analysis/passes/fieldalignment/cmd/fieldalignment@latest
fieldalignment?-fix?<package_path>

對上面的代碼使用 govet/fieldalignment：

fieldalignment:?struct?of?size?96?could?be?88?(govet)

使用 map[string]struct{} 而不是 map[string]bool

Go 沒有內(nèi)置的集合，通常使用 map[string]bool{} 表示集合。盡管它更具可讀性（這非常重要），但將其作為一個集合使用是錯誤的，因為它具有兩種狀態(tài)（假/真）并且與空結構體相比使用了額外的內(nèi)存。

空結構體 (struct{}) 是沒有額外字段的結構類型，占用零字節(jié)的存儲空間。Dave Chaney 有一篇關于空結構的詳細博客 。

除非您的 map/set 包含大量值并且需要獲得額外的內(nèi)存，否則我建議使用 map[string]struct{}。

100 000 000 次 map 寫入的極端示例：

func?BenchmarkBool(b?*testing.B)?{
????m?:=?make(map[uint]bool)
????for?i?:=?uint(0);?i?<?100_000_000;?i++?{
????????m[i]?=?true
????}
}
func?BenchmarkEmptyStruct(b?*testing.B)?{
????m?:=?make(map[uint]struct{})
????for?i?:=?uint(0);?i?<?100_000_000;?i++?{
????????m[i]?=?struct{}{}
????}
}

多次運行程序得到的結果一致（MBP 14 2021，10C M1 Pro）：

name            time/op
Bool          12.4s ± 0%
EmptyStruct   12.0s ± 0%

name            alloc/op
Bool         3.78GB ± 0%
EmptyStruct  3.43GB ± 0%

name            allocs/op
Bool          3.91M ± 0%
EmptyStruct   3.90M ± 0%

通過這些數(shù)字，我們可以得出結論，使用空結構映射的寫入速度提高了 3.2%，分配的內(nèi)存減少了 10%。

此外，使用map[type]struct{}是實現(xiàn)集合的正確解決方法，因為每個鍵都有一個值。map[type]bool 每個鍵有兩個可能的值，這不是一個集合，如果目標是創(chuàng)建一個集合，則可能會被濫用。

然而，可讀性大多數(shù)時候比（可忽略的）內(nèi)存改進更重要。與空結構體相比，使用布爾值更容易查找：

m?:=?make(map[string]bool{})
if?m["key"]{
?//?Do?something
}
v?:=?make(map[string]struct{}{})
if?_,?ok?:=?v["key"];?ok{
????//?Do?something
}

以上就是Go內(nèi)存節(jié)省技巧簡單實現(xiàn)詳解的詳細內(nèi)容，更多關于Go 內(nèi)存節(jié)省的資料請關注腳本之家其它相關文章！

最新評論