Golang 中的内存管理简单技巧

举报
宇宙之一粟 发表于 2022/08/31 14:47:36 2022/08/31
【摘要】 除非您正在对服务进行原型设计,否则您可能会关心应用程序的内存使用情况。内存占用更小,基础设施成本降低,扩展变得更容易/延迟。尽管 Go 以不消耗大量内存而闻名,但仍有一些方法可以进一步减少消耗。其中一些需要大量重构,但很多都很容易做到。 预先分配切片数组是具有连续内存的相同类型的集合。数组类型定义指定长度和元素类型。数组的主要问题是它们的大小是固定的——它们不能调整大小,因为数组的长度是它们...

除非您正在对服务进行原型设计,否则您可能会关心应用程序的内存使用情况。内存占用更小,基础设施成本降低,扩展变得更容易/延迟。尽管 Go 以不消耗大量内存而闻名,但仍有一些方法可以进一步减少消耗。其中一些需要大量重构,但很多都很容易做到。

预先分配切片

数组是具有连续内存的相同类型的集合。数组类型定义指定长度和元素类型。数组的主要问题是它们的大小是固定的——它们不能调整大小,因为数组的长度是它们类型的一部分。

与数组类型不同,切片类型没有指定长度。切片的声明方式与数组相同,但没有元素计数。

切片是数组的包装器,它们不拥有任何数据——它们是对数组的引用。它们由指向数组的指针、段的长度及其容量(底层数组中的元素数)组成。

当您追加到一个没有新值容量的切片时 - 会创建一个具有更大容量的新数组,并将当前数组中的值复制到新数组中。这会导致不必要的分配和 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: 0xc0000160c8, Length: 1, Capacity: 1, Values: [0]
Address: 0xc0000160f0, Length: 2, Capacity: 2, Values: [0 1]
Address: 0xc00001e080, Length: 3, Capacity: 4, Values: [0 1 2]
Address: 0xc00001e080, Length: 4, Capacity: 4, Values: [0 1 2 3]
Address: 0xc00001a140, Length: 5, Capacity: 8, Values: [0 1 2 3 4]

查看输出,我们可以得出结论,无论何时必须增加容量(增加 2 倍),都必须创建一个新的底层数组(新的内存地址)并将值复制到新数组中。

有趣的事实是,容量增长的因素曾经是容量 <1024 的 2 倍,以及 >= 1024 的 1.25 倍。从 Go 1.18 开始,这已经变得更加线性

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

查看上述基准,我们可以得出结论,将值分配给预分配的切片和将值附加到切片之间存在很大差异。

两个 linter 有助于预分配切片:

  • prealloc: 一种静态分析工具,用于查找可能被预分配的切片声明。
  • makezero: 一种静态分析工具,用于查找未以零长度初始化且稍后与 append 一起使用的切片声明。

结构中的顺序字段

您之前可能没有想到这一点,但结构中字段的顺序对内存消耗很重要。

以下面的结构为例:

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(字节),而所有字段相加为 82 字节。额外的 14 个字节来自哪里?

现代 64 位 CPU 以 64 位(8 字节)块的形式获取数据。如果我们有一个较旧的 32 位 CPU,它将执行 32 位(4 字节)的块。

第一个周期占用 8 个字节,IsDraft 字段占用 1 个字节,并有 7 个未使用字节。它不能占据一个字段的“一半”。

第二和第三个循环取 Title 字符串,第四个循环取 ID,依此类推。再次使用 IsDeleted 字段,它需要 1 个字节并有 7 个未使用的字节。

真正重要的是按字段的大小从上到下对字段进行排序。对上述结构进行排序,大小减少到 88 个字节。最后两个字段 IsDraftIsDeleted 被放在同一个块中,从而将未使用的字节数从 14 (2x7) 减少到 6 (1 x 6),在此过程中节省了 8 个字节。

type Post struct {
    CreatedAt   time.Time // 24 bytes
    Title       string    // 16 bytes
    Description string    // 16 bytes
    Author      string    // 16 bytes
    ID          int64     // 8 bytes
    IsDeleted   bool      // 1 byte
}

func main(){
    p := Post{}
    fmt.Println(unsafe.Sizeof(p))
}

在 64 位架构上占用 <8 字节的 Go 类型:

  • bool:1 个字节
  • int8/uint8:1 个字节
  • int16/uint16:2 个字节
  • int32/uint32/rune:4 字节
  • float32:4 字节
  • byte:1个字节

无需手动检查结构并按大小对其进行排序,而是使用 linter 找到这些结构并(用于)报告“正确”排序。

  • maligned: 不推荐使用的 linter,用于报告未对齐的结构并打印出正确排序的字段。它在一年前被弃用,但您仍然可以安装旧版本并使用它。
  • govet/fieldalignment: 作为 gotools 和 govet linter 的一部分,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 没有内置集合,通常使用 map[string]bool{} 来表示集合。尽管它更具可读性,这一点非常重要,但将其作为一个集合使用是错误的,因为它有两种状态(假/真),并且与空结构相比使用了额外的内存。

空结构体 (struct{}) 是没有额外字段的结构体类型,占用零字节存储空间。

我不建议这样做,除非您的 map/set 包含大量值并且您需要获得额外的内存或者您正在为低内存平台进行开发。

使用 100 000 000 次写入地图的极端示例:

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{}{}
    }
}

得到以下结果,在整个运行过程中非常一致:

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%

使用这些数字,我们可以得出结论,使用空结构映射的写入速度提高了 3.2%,分配的内存减少了 10%。

此外,使用 map[type]struct{} 是实现集合的正确解决方法,因为每个键都有一个值。使用 map[type]bool,每个键都有两个可能的值,这不是一个集合,如果目标是创建一个集合,则可能会被误用。

然而,可读性大多数时候比(可忽略的)内存改进更重要。与空结构体相比,使用布尔值更容易掌握查找:

m := make(map[string]bool{})
if m["key"]{
 // Do something
}

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

参考链接:Easy memory-saving tricks in Go | Emir Ribic (ribice.ba)

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。