内存块

• 一个结构体值很可能由若干字段，所以当为此结构体值开辟了一个内存块时，此内存块同时也将承载此结构体值的各个字段值（的直接部分）。
• 一个数组值常常包含很多元素，所以当为此数组值开辟了一个内存块时，此内存块同时也将承载此数组值的各个元素值（的直接部分）。
• 两个切片的底层间接部分的元素序列可能承载在同一个内存块上，这两个间接值部甚至可能有部分重叠。

• 显式地调用new和make内置函数。 一个new函数调用总是只开辟一个内存块。 一个make函数调用有可能会开辟多个内存块来承载创建的切片/映射/通道值的直接和底层间接值部。
• 使用字面量创建映射、切片或函数值。在此创建过程中，一个或多个内存块将被开辟出来。
• 声明变量。
• 将一个非接口值赋给一个接口值。（对于标准编译器来说，不包括将一个指针值赋给一个接口值的情况。）
• 衔接非常量字符串。
• 将字符串转换为字节切片或者码点切片，或者反之，除了一些编译器优化情形。
• 将一个整数转换为字符串。
• 调用内置append函数并且基础切片的容量不足够大。
• 向一个映射添加一个键值条目并且此映射底层内部的哈希表需要改变容量。

• 从栈上开辟内存块比在堆上快得多；
• 开辟在栈上的内存块不需要被垃圾回收；
• 开辟在栈上的内存块对CPU缓存更加友好。

• 如果一个结构体值的一个字段逃逸到了堆上，则此整个结构体值也逃逸到了堆上。
• 如果一个数组的某个元素逃逸到了堆上，则此整个数组也逃逸到了堆上。
• 如果一个切片的某个元素逃逸到了堆上，则此切片中的所有元素都将逃逸到堆上，但此切片值的直接部分可能开辟在栈上。
• 如果一个值部v被一个逃逸到了堆上的值部所引用，则此值部v也将逃逸到堆上。

package main

var p *int

func main() {
    done := make(chan bool)
    // done通道将被使用在主协程和下面将要
    // 创建的新协程中，所以它将被开辟在堆上。

    go func() {
        x, y, z := 123, 456, 789
        _ = z  // z可以被安全地开辟在栈上。
        p = &x // 因为x和y都会将曾经被包级指针p所引用过，
        p = &y // 因此，它们都将开辟在堆上。

        // 到这里，x已经不再被任何其它值所引用。或者说承载
        // 它的内存块已经不再被使用。此内存块可以被回收了。

        p = nil
        // 到这里，y已经不再被任何其它值所引用。
        // 承载它的内存块可以被回收了。

        done <- true
    }()

    <-done
    // 到这里，done已经不再被任何其它值所引用。一个
    // 聪明的编译器将认为承载它的内存块可以被回收了。

    // ...
}

有时，聪明的编译器可能会做出一些出人意料的（但正确的）的优化。
比如在下面这个例子中，切片bs的底层间接值部在bs仍在使用之前就已经被标准编译器发觉已经不再被使用了。

package main

import "fmt"

func main() {
    // 假设此切片的长度很大，以至于它的元素
    // 将被开辟在堆上。
    bs := make([]byte, 1 << 31)

    // 一个聪明的编译器将觉察到bs的底层元素
    // 部分已经不会再被使用，而正确地认为bs的
    // 底层元素部分在此刻可以被安全地回收了。

    fmt.Println(len(bs))
}

关于切片值的内部实现结构，请参考值部一文。

顺便说一下，有时候出于种种原因，我们希望确保上例中的bs切片的底层间接值部不要在fmt.Println调用之前被垃圾回收。 这时，我们可以使用一个runtime.KeepAlive函数调用以便让垃圾回收器知晓在此调用之前切片bs和它所引用着的值部仍在被使用中。

一个例子：

package main

import "fmt"
import "runtime"

func main() {
    bs := make([]int, 1000000)

    fmt.Println(len(bs))
    runtime.KeepAlive(&bs)
    // 对于这个特定的例子，也可以调用
    // runtime.KeepAlive(bs)。
}

目前的官方Go标准运行时（1.15版本）使用一个并发三色（tri-color）标记清扫（mark-sweep）算法来实现垃圾回收。 这里仅会对此算法的原理做一个大致的描述。一个具体实现可能和此大致描述会有很多细节上的差别。

一个垃圾回收过程分为两个阶段：标记阶段和清扫阶段。

在标记阶段，垃圾回收器（实际上是一组协程）使用三色算法来分析哪些（开辟在堆上的）内存块已经不再使用了。

• 在每一轮（见下一节的解释）垃圾回收过程的开始，所有的内存块将被标记为白色。
• 然后垃圾回收器将所有开辟在栈和全局内存区上的内存块标记为灰色，并把它们加入一个灰色内存块列表。
• 循环下面两步直到灰色内存块列表为空：
  1. 从个灰色内存块列表中取出一个内存块，并把它标记为黑色。
  2. 然后扫描承载在此内存块上的指针值，并通过这些指针找到它们引用着的内存块。 如果一个引用着的内存块为白色的，则将其标记为灰色并加入灰色内存块列表；否则，忽略之。

（注意这里在算法中使用三色而不是两色的原因是此标记过程是并发的。在标记的过程中，很多其它普通用户协程也正在运行中。 在此标记过程中对指针的写入需要一些额外的开销，欲更深入了解此点，请以“write barrier golang”为关键字自行搜索以深入了解。 简而言之，当在某个用户协程中，一个已经标记为黑色的内存块在标记过程中被修改而使其新引用着的一个仍标记为白色的内存块时，此白色内存块需要被标记为灰色，否则此白色内存块有可能将被认为是垃圾而回收掉；除此之外的情况不做特殊处理。）

在清扫阶段，仍被标记为白色的内存块将被认为是不再使用的而被回收掉。

此垃圾回收算法不会移动内存块来整理内存碎片。

开辟在堆上的不再使用的内存块将被Go运行时认为是垃圾而将被回收，以供以后重用或者释放（给操作系统）。 垃圾回收器并不是时刻都在运行着。它只是每隔一段时间因为某些条件达成之后才开始新的一轮垃圾回收过程。 所以，一个不再被使用的内存块不会在它不再使用后立即得到回收，而是将在一段时间后被逐步回收。

目前（Go官方工具链1.15），对于使用标准编译器编译的Go程序，一轮新的垃圾回收过程开启的默认条件是通过GOGC环境变量来控制的。 当从上一轮垃圾回收结束后新申请的内存块的内存总和占上一轮垃圾回收结束时仍在被使用的所有内存块的内存总和的百分比超过此值时，新的一轮垃圾回收过程将开始。 所以此值决定了垃圾回收过程的频率。 此环境变量的默认值为100。 此值也可以通过调用runtime/debug.SetGCPercent函数在运行时刻被动态地修改。 调用debug.SetGCPercent(-1)将关闭自动垃圾回收。

一轮新的垃圾回收过程也可以通过调用runtime.GC函数来手动开启。

另一点需要注意的是，当前的官方Go运行时（v1.15）同时采取了另一个策略：一个Go程序的最大垃圾回收时间间隔为两分钟。

以后的Go运行时版本可能会采取不同的垃圾回收策略。

一个不再被使用的内存块被回收后可能并不会立即释放给操作系统，这样Go运行时可以将其重新分配给其它值部使用。 不用担心，官方Go运行时的实现比大多数主流的Java运行时要消耗少得多的内存。