golang 内存那些事--如何快速分配内存，减少系统 GC （三）

在写这一章节的时候我在考虑关于 golang 内存管理到底要讲到什么程度，毕竟 golang 的内存管理尤其是 golang 的 gc 机制是一门复杂的哲学，非万字长文是说不明白的，我又在网上搜索了一圈发现网上已经有了很好的讲解 golang gc 的文档。这篇文档还是本着实用的原则通过各种例子来讲解 golang 的内存，不会过多涉及 golang 底层实现机制。

make 和 new 的区别

golang 中内存分配有三种方式：1、在声明变量时直接初始化，这是 golang 会为初始化数据分配一段空间；2、使用内置函数 make；3、使用内置函数 new。这里 make 函数只能用于slice，map，chan 三种类型，返回值是一个引用，new 可以用于任意类型，返回值是是一个指针。另外 make 还支持 size 参数，能知道引用底层存储空间的大小。

append 函数是如何处理 slice 的？

前面在第二章节的时候 append 会在底层存储空间不够时 copy 一份数据加大新的存储空间，但是当底层存储空间足够时会发送什么呢？我们看一下下面的例子：

package main

import (
    "fmt"
    "unsafe"
)

func main() {
    a := make([]int, 2, 3)
    fmt.Printf("Address of a=%d\n", unsafe.Pointer(&a[0]))
    a = append(a, 1)
    fmt.Printf("Address of a=%d\n", unsafe.Pointer(&a[0]))
    a = append(a, 1)
    fmt.Printf("Address of a=%d\n", unsafe.Pointer(&a[0]))
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

输出结果：

Address of a=824633811328
Address of a=824633811328
Address of a=824633860288
1
2
3

我们可以看到第一次 append 时存储空间的地址并没有变化，第二次 append 时存储空间地址发送了变化（因为第二次时存储空间已经不足了）。从这儿我们也可以看出在使用 slice 时我们尽量一次性分配足够的空间，这样就是减少因为空间不足带来的内存平凡分配，gc，copy 时带来的cpu 消耗。

另外还需要注意的时，多个 slice 可以共用一个存储空间，通过其中一个 slice 改变了值会影响到其他 slice，看下面例子：

package main

import "fmt"

func main() {
    a := []int{1, 2, 3}
    b := a[1:]
    b[1] = 100
    fmt.Printf("a=%v\n", a)
    b = append(b, 200)
    fmt.Printf("a=%v\n", a)
    fmt.Printf("b=%v\n", b)
}
1
2
3
4
5
6
7
8
9
10
11
12
13

输出结果：

a=[1 2 100]
a=[1 2 100]
b=[2 100 200]
1
2
3

上面输出结果可以看出第一次 b 的值改变影响到了 a，但是 append 之后 b 指向了新的地址空间，这时候 b 和 a 就没有关系了，b 的改变不会影响 a。

sync.Pool

golang 的 gc 机制会自动回收没有任何引用和任何指针的内存空间，这种机制虽然可以减少程序员因为任务失误找出内存泄露的风险，但是 gc 本身也是消耗 cpu 的，如果频繁的创建，消耗内存空间比如会拖慢整个系统的速度，比如高并发的网络系统，在短时内会有大量数据到达并处理，这就意味着短时内要大量重复的创建内存空间用完后在等到 gc 回收。

golang 为解决这个问题提供了 sync.Pool，sync.Pool 可以临时存放不需要的内存空间，等到下次有新的内存空间需要时可以从 sync.Pool 中直接申领而不必在重新创建。我们来直接看例子：

package main

import (
    "fmt"
    "sync"
    "unsafe"
)

var bufPool = sync.Pool{
    // 当 pool 中没有元素其 Get 方法被调用时会使用这个方法创建元素并返回
    New: func() any {
        return make([]int, 3, 3)
    },
}

func main() {
    testfunc()
    testfunc()
}

func testfunc() {
    a := bufPool.Get().([]int)
    // 在函数栈销毁之前把 a 放入 bufPool，方便下次直接获取
    defer bufPool.Put(a)
    fmt.Printf("Address of a=%v\n", unsafe.Pointer(&a[0]))
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

输出结果：

Address of a=0xc0000ba000
Address of a=0xc0000ba000
1
2

可以看到两次调用函数，a 都指向了同一内存。另外需要注意的是 sync.Pool 如果长时间没有被再次利用也会自动销毁的，看一下下面这个例子：

package main

import (
    "fmt"
    "sync"
    "time"
    "unsafe"
)

var bufPool = sync.Pool{
    // 当 pool 中没有元素其 Get 方法被调用时会使用这个方法创建元素并返回
    New: func() any {
        return make([]int, 3, 3)
    },
}

func main() {
    testfunc()
    // 多了 sleep，在 sleep 期间 bufPool 里的空间会被释放
    time.Sleep(10 * time.Second)
    testfunc()
}

func testfunc() {
    a := bufPool.Get().([]int)
    // 在函数栈销毁之前把 a 放入 bufPool，方便下次直接获取
    defer bufPool.Put(a)
    fmt.Printf("Address of a=%v\n", unsafe.Pointer(&a[0]))
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

输出结果：

Address of a=0xc000016180
Address of a=0xc000094000
1
2

可以看到就是加了个 sleep，两次函数调用 a 指向的空间地址就不同了。