作者：William Kennedy 译者：jettyhan 校对：polaris1119

前序（Prelude）

本系列文章总共四篇，主要帮助大家理解 Go 语言中一些语法结构和其背后的设计原则，包括指针、栈、堆、逃逸分析和值/指针传递。这是第二篇，主要介绍堆和逃逸分析。

以下是本系列文章的索引：

  1. Go 语言机制之栈与指针
  2. Go 语言机制之逃逸分析
  3. Go 语言机制之内存剖析
  4. Go 语言机制之数据和语法的设计哲学

介绍（Introduction）

在四部分系列的第一部分，我用一个将值共享给 goroutine 栈的例子介绍了指针结构的基础。而我没有说的是值存在栈之上的情况。为了理解这个，你需要学习值存储的另外一个位置：堆。有这个基础，就可以开始学习逃逸分析。

逃逸分析是编译器用来决定你的程序中值的位置的过程。特别地，编译器执行静态代码分析，以确定一个构造体的实例化值是否会逃逸到堆。在 Go 语言中，你没有可用的关键字或者函数，能够直接让编译器做这个决定。只能够通过你写代码的方式来作出这个决定。

堆（Heaps）

堆是内存的第二区域，除了栈之外，用来存储值的地方。堆无法像栈一样能自清理，所以使用这部分内存会造成很大的开销（相比于使用栈）。重要的是，开销跟 GC（垃圾收集），即被牵扯进来保证这部分区域干净的程序，有很大的关系。当垃圾收集程序运行时，它会占用你的可用 CPU 容量的 25%。更有甚者，它会造成微秒级的 stop the world 的延时。拥有 GC 的好处是你可以不再关注堆内存的管理，这部分很复杂，是历史上容易出错的地方。

在 Go 中，会将一部分值分配到堆上。这些分配给 GC 带来了压力，因为堆上没有被指针索引的值都需要被删除。越多需要被检查和删除的值，会给每次运行 GC 时带来越多的工作。所以，分配算法不断地工作，以平衡堆的大小和它运行的速度。

共享栈（Sharing Stacks）

在 Go 语言中，不允许 goroutine 中的指针指向另外一个 goroutine 的栈。这是因为当栈增长或者收缩时， goroutine 中的栈内存会被一块新的内存替换。如果运行时需要追踪指针指向其他的 goroutine 的栈，就会造成非常多需要管理的内存，以至于更新指向那些栈的指针将使 stop the world 问题更严重。

这里有一个栈被替换好几次的例子如下。看输出的第 2 和第 6 行。你会看到 main 函数中的栈的字符串地址值改变了两次。

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

// All material is licensed under the Apache License Version 2.0, January 2004
// http://www.apache.org/licenses/LICENSE-2.0

// Sample program to show how stacks grow/change.
package main

// Number of elements to grow each stack frame.
// Run with 10 and then with 1024
const size = 1024

// main is the entry point for the application.
func main() {
	s := "HELLO"
	stackCopy(&s, 0, [size]int{})
}

// stackCopy recursively runs increasing the size
// of the stack.
func stackCopy(s *string, c int, a [size]int) {
	println(c, s, *s)

	c++
	if c == 10 {
		return
	}

	stackCopy(s, c, a)
}

逃逸机制（Escape Mechanics）

任何时候，一个值被分享到函数栈帧范围之外，它都会在堆上被重新分配。这是逃逸分析算法发现这些情况和管控这一层的工作。（内存的）完整性在于确保对任何值的访问始终是准确、一致和高效的。

通过查看这个语言机制了解逃逸分析。Playground

清单 1

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
30
31
32
33
34
35

package main

type user struct {
    name  string
    email string
}

func main() {
    u1 := createUserV1()
    u2 := createUserV2()

    println("u1", &u1, "u2", &u2)
}

//go:noinline
func createUserV1() user {
    u := user{
        name:  "Bill",
        email: "bill@ardanlabs.com",
    }

    println("V1", &u)
    return u
}

//go:noinline
func createUserV2() *user {
    u := user{
        name:  "Bill",
        email: "bill@ardanlabs.com",
    }

    println("V2", &u)
    return &u
}

我使用 go:noinline 指令，阻止在 main 函数中，编译器使用内联代码替代函数调用。内联（优化）会使函数调用消失，并使例子复杂化。我将在下一篇博文介绍内联造成的副作用。

在表 1 中，你可以看到创建 user 值，并返回给调用者的两个不同的函数。在函数createUserV1 中，返回值。

清单 2

1
2
3
4
5
6
7
8
9

16 func createUserV1() user {
17     u := user{
18         name:  "Bill",
19         email: "bill@ardanlabs.com",
20     }
21
22     println("V1", &u)
23     return u
24 }

我说这个函数返回的是值是因为这个被函数创建的 user 值被拷贝并传递到调用栈上。这意味着调用函数接收到的是这个值的拷贝。

你可以看下第 17 行到 20 行 user 值被构造的过程。然后在第 23 行， user 值的副本被传递到调用栈并返回给调用者。函数返回后，栈看起来如下所示。

图 1

图1

你可以看到图 1 中，当调用完 createUserV1 ，一个 user 值同时存在（两个函数的）栈帧中。在函数版本 2 中，返回指针。

清单 3

1
2
3
4
5
6
7
8
9

27 func createUserV2() *user {
28     u := user{
29         name:  "Bill",
30         email: "bill@ardanlabs.com",
31     }
32
33     println("V2", &u)
34     return &u
35 }

我说这个函数返回的是指针是因为这个被函数创建的 user 值通过调用栈被共享了。这意味着调用函数接收到一个值的地址拷贝。

你可以看到在第 28 行到 31 行使用相同的字段值来构造 user 值，但在第 34 行返回时却是不同的。不是将 user 值的副本传递到调用栈，而是将 user 值的地址传递到调用栈。基于此，你也许会认为栈在调用之后是这个样子。

图 2

图2

如果看到的图 2 真的发生的话，你将遇到一个问题。指针指向了栈下的无效地址空间。当 main 函数调用下一个函数，指向的内存将重新映射并将被重新初始化。

这就是逃逸分析将开始保持完整性的地方。在这种情况下，编译器将检查到，在 createUserV2 的（函数）栈中构造 user 值是不安全的，因此，替代地，会在堆中构造（相应的）值。这（个分析并处理的过程）将在第 28 行构造时立即发生。

可读性（Readability）

在上一篇博文中，我们知道一个函数只能直接访问它的（函数栈）空间，或者通过（函数栈空间内的）指针，通过跳转访问（函数栈空间外的）外部内存。这意味着访问逃逸到堆上的值也需要通过指针跳转。

记住 createUserV2 的代码的样子：

清单 4

1
2
3
4
5
6
7
8
9

27 func createUserV2() *user {
28     u := user{
29         name:  "Bill",
30         email: "bill@ardanlabs.com",
31     }
32
33     println("V2", &u)
34     return &u
35 }

语法隐藏了代码中真正发生的事情。第 28 行声明的变量 u 代表一个 user 类型的值。Go 代码中的类型构造不会告诉你值在内存中的位置。所以直到第 34 行返回类型时，你才知道值需要逃逸（处理）。这意味着，虽然 u 代表类型 user 的一个值，但对该值的访问必须通过指针进行。

你可以在函数调用之后，看到堆栈就像（图 3）这样。

图 3

图3

在 createUserV2 函数栈中，变量 u 代表的值存在于堆中，而不是栈。这意味着用 u 访问值时，使用指针访问而不是直接访问。你可能想，为什么不让 u 成为指针，毕竟访问它代表的值需要使用指针？

清单 5

1
2
3
4
5
6
7
8
9

27 func createUserV2() *user {
28     u := &user{
29         name:  "Bill",
30         email: "bill@ardanlabs.com",
31     }
32
33     println("V2", u)
34     return u
35 }

如果你这样做，将使你的代码缺乏重要的可读性。（让我们）离开整个函数一秒，只关注 return 。

清单 6

1
2

34     return u
35 }

这个 return 告诉你什么了呢？它说明了返回 u 值的副本给调用栈。然而，当你使用 & 操作符， return 又告诉你什么了呢？

清单 7

1
2

34     return &u
35 }

多亏了 & 操作符，return 告诉你 u 被分享给调用者，因此，已经逃逸到堆中。记住，当你读代码的时候，指针是为了共享，& 操作符对应单词 sharing。这在提高可读性的时候非常有用，这（也）是你不想失去的部分。

清单 8

1
2
3

01 var u *user
02 err := json.Unmarshal([]byte(r), &u)
03 return u, err

为了让其可以工作，你一定要通过共享指针变量（的方式）给（函数） json.Unmarshal。json.Unmarshal 调用时会创建 user 值并将其地址赋值给指针变量。Go Playground

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
30
31
32
33
34
35
36
37

package main

import (
	"encoding/json"
	"fmt"
)

type user struct {
	ID   int
	Name string
}

func main() {
	u, err := retrieveUser(1234)
	if err != nil {
		fmt.Println(err)
		return
	}

	fmt.Printf("%+v\n", *u)
}

func retrieveUser(id int) (*user, error) {
	r, err := getUser(id)
	if err != nil {
		return nil, err
	}

	var u *user
	err = json.Unmarshal([]byte(r), &u)
	return u, err
}

func getUser(id int) (string, error) {
	response := fmt.Sprintf(`{"id": %d, "name": "sally"}`, id)
	return response, nil
}

代码解释：

1
2
3

01：创建一个类型为 user，值为空的指针。
02：跟函数 json.Unmarshal 函数共享指针。
03：返回 u 的副本给调用者。

这里并不是很好理解， user 值被 json.Unmarshal 函数创建，并被共享给调用者。

如何在构造过程中使用语法语义来改变可读性？

清单 9

1
2
3

01 var u user
02 err := json.Unmarshal([]byte(r), &u)
03 return &u, err

代码解释：

1
2
3

01：创建一个类型为 user，值为空的变量。
02：跟函数 json.Unmarshal 函数共享 u。
03：跟调用者共享 u。

这里非常好理解。第 02 行共享 user 值到调用栈中的 json.Unmarshal，在第 03 行 user 值共享给调用者。这个共享过程将会导致 user 值逃逸。

在构建一个值时，使用值语义，并利用 & 操作符的可读性来明确值是如何被共享的。

编译器报告（Compiler Reporting）

想查看编译器（关于逃逸分析）的决定，你可以让编译器提供一份报告。你只需要在调用 go build 的时候，打开 -gcflags 开关，并带上 -m 选项。

实际上总共可以使用 4 个 -m，（但）超过 2 个级别的信息就已经太多了。我将使用 2 个 -m 的级别。

清单 10

1
2
3
4
5
6
7
8
9
10
11

$ go build -gcflags "-m -m"
./main.go:16: cannot inline createUserV1: marked go:noinline
./main.go:27: cannot inline createUserV2: marked go:noinline
./main.go:8: cannot inline main: non-leaf function
./main.go:22: createUserV1 &u does not escape
./main.go:34: &u escapes to heap
./main.go:34: from ~r0 (return) at ./main.go:34
./main.go:31: moved to heap: u
./main.go:33: createUserV2 &u does not escape
./main.go:12: main &u1 does not escape
./main.go:12: main &u2 does not escape

你可以看到编译器报告是否需要逃逸处理的决定。编译器都说了什么呢？请再看一下引用的 createUserV1 和 createUserV2 函数。

清单 13

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

16 func createUserV1() user {
17     u := user{
18         name:  "Bill",
19         email: "bill@ardanlabs.com",
20     }
21
22     println("V1", &u)
23     return u
24 }

27 func createUserV2() *user {
28     u := user{
29         name:  "Bill",
30         email: "bill@ardanlabs.com",
31     }
32
33     println("V2", &u)
34     return &u
35 }

从报告中的这一行开始。

清单 14

1

./main.go:22: createUserV1 &u does not escape

这是说在函数 createUserV1 调用 println 不会造成 user 值逃逸到堆。这是必须检查的，因为它将会跟函数 println 共享（u）。

接下来看报告中的这几行。

清单 15

1
2
3
4

./main.go:34: &u escapes to heap
./main.go:34: from ~r0 (return) at ./main.go:34
./main.go:31: moved to heap: u
./main.go:33: createUserV2 &u does not escape

这几行是说，类型为 user ，并在第 31 行被赋值的 u 的值，因为第 34 行的 return 逃逸。最后一行是说，跟之前一样，在 33 行调用 println 不会造成 user 值逃逸。

阅读这些报告可能让人感到困惑，（编译器）会根据所讨论的变量的类型是基于值类型还是指针类型而略有变化。

将 u 改为指针类型的 *user，而不是之前的命名类型 user 。

清单 16

1
2
3
4
5
6
7
8
9

27 func createUserV2() *user {
28     u := &user{
29         name:  "Bill",
30         email: "bill@ardanlabs.com",
31     }
32
33     println("V2", u)
34     return u
35 }

再次生成报告。

清单 17

1
2
3

./main.go:30: &user literal escapes to heap
./main.go:30: from u (assigned) at ./main.go:28
./main.go:30: from ~r0 (return) at ./main.go:34

现在报告说在 28 行赋值的指针类型 *user，u 引用的 user 值，因为 34 行的 return 逃逸。

结论

值在构建时并不能决定它将存在于哪里。只有当一个值被共享，编译器才能决定如何处理这个值。当你在调用时，共享了栈上的一个值时，它就会逃逸。在下一篇中你将探索一个值逃逸的其他原因。

这些文章试图引导你选择给定类型的值或指针的指导原则。每种方式都有（对应的）好处和（额外的）开销。保持在栈上的值，减少了 GC 的压力。但是需要存储，跟踪和维护不同的副本。将值放在堆上的指针，会增加 GC 的压力。然而，也有它的好处，只有一个值需要存储，跟踪和维护。（其实，）最关键的是如何保持正确地、一致地以及均衡（开销）地使用。

参考文献