Golang转义分析中的“leak/leaking param”是什么意思

有志者，事竟成！如果你在学习Golang，那么本文《Golang转义分析中的“leak/leaking param”是什么意思》，就很适合你！文章讲解的知识点主要包括，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

func main() {
        i1 := 1
    a1(&i1)
}

func a1(i1 *int) *int {
    return i1
}

逃逸分析结果为

./main.go:18:9: parameter i1 leaks to \~r1 with derefs=0:
./main.go:18:9:   flow: \~r1 = i1:
./main.go:18:9:     from return i1 (return) at ./main.go:19:2
./main.go:18:9: leaking param: i1 to result \~r1 level=0

parameter i1 泄漏到 \~r1 的含义是什么， derefs=0 和 leaking param: i1 to result \~r1 level=0

首先我尝试google golang escapeleaking，最相关的结果在escape-analysis-shows-channel-as-leaking-param的评论中

“你为什么那么想？”可以合理地假设泄漏是严重的并且与其阀杆泄漏有关。我正在努力想出一个示例上下文，其中泄漏是一件好事，例如泄漏的桶、泄漏的油箱、泄漏、泄漏的电容器、泄漏的船、泄漏的抽象。对于高性能 go 专家来说，这可能是显而易见的，但对于我们其他人来说，链接到文档并提供泄漏参数所指内容的简要说明会很有帮助

这也是我想问的问题，但之后就没有回复了。

然后我尝试阅读打印这些结果的源代码。

在compile/internal/escape/leaks.go中，我发现了评论

// 泄漏代表来自参数的一组赋值流 // 到堆或它的任何函数（第一个 numescresults） // 结果参数。

但是我无法理解这一点，有没有任何官方文档可以代表它。

此外，在源代码中我发现还有一个问题。 numescresults(7)之后的结果参数是否会在运行时逃逸到堆？

func main() {
    i1, i2, i3, i4, i5, i6, i7, i8, i9 := 1, 1, 1, 1, 1, 1, 1, 1, 1
    a1(&i1, &i2, &i3, &i4, &i5, &i6, &i7, &i8, &i9)
    return
}

func a1(i1, i2, i3, i4, i5, i6, i7, i8, i9 *int) (*int, *int, *int, *int, *int, *int, *int, *int, *int) {
    return i1, i2, i3, i4, i5, i6, i7, i8, i9
}

...some duplicate output
./main.go:16:13: leaking param: i2 to result ~r10 level=0
./main.go:16:17: leaking param: i3 to result ~r11 level=0
./main.go:16:21: leaking param: i4 to result ~r12 level=0
./main.go:16:25: leaking param: i5 to result ~r13 level=0
./main.go:16:29: leaking param: i6 to result ~r14 level=0
./main.go:16:33: leaking param: i7 to result ~r15 level=0
./main.go:16:37: leaking param: i8
./main.go:16:41: leaking param: i9
./main.go:8:30: i8 escapes to heap:
./main.go:8:30:   flow: {heap} = &i8:
./main.go:8:30:     from &i8 (address-of) at ./main.go:9:40
./main.go:8:30:     from A1(&i1, &i2, &i3, &i4, &i5, &i6, &i7, &i8, &i9) (call parameter) at ./main.go:9:4
./main.go:8:34: i9 escapes to heap:
./main.go:8:34:   flow: {heap} = &i9:
./main.go:8:34:     from &i9 (address-of) at ./main.go:9:45
./main.go:8:34:     from A1(&i1, &i2, &i3, &i4, &i5, &i6, &i7, &i8, &i9) (call parameter) at ./main.go:9:4
./main.go:8:30: moved to heap: i8
./main.go:8:34: moved to heap: i9

正确答案

参数 i1 泄漏到 ~r1 且 derefs=0 和泄漏参数：i1 到结果 ~r1 level=0 的含义是什么

tldl：如果您正在寻找分配，请忽略泄漏参数并寻找“移动到堆”的部分。

“泄漏参数”意味着该函数在返回后以某种方式保持其参数处于活动状态，这并不意味着它被移动到堆，事实上大多数“泄漏参数”都是在堆栈上分配的。

“r1”指的是函数的返回值，它从0开始，所以“r1”指的是第二个返回值。 （与op提供的示例代码不匹配，应该是r0），在第一个片段的情况下，它泄漏“i1”，因为“r0 = i1”，所以第0个函数返回值是“i1”，因此“i1” " 返回后必须保持活动状态，“泄漏”给调用者

编译器输出中“泄漏参数”之前的部分是因为 op 使用“-m -m”，它会打印数据流图。

对于 deref，来自 cmd/compile/internal/escape/escape.go 中的注释：

[...] 取消引用操作的数量减去 寻址操作被记录为边的权重（称为 “取消引用”）。

“level”在当前的注释中没有描述，自从我熟悉gc源代码以来已经有一段时间了，据我所知它是内存间接的级别，间接（*）操作增量，地址(&) 递减，因此该函数

func A1(a **int) *int {
    p := &a
    return **p
}

应该给出一个 level=1 的泄漏参数 a。

此外，在源代码中我发现还有一个问题。 numescresults(7)之后的结果参数是否会在运行时逃逸到堆？

是的，第 7 个之后依赖于泄漏参数的所有结果（读取、返回）都将被移动到堆中，我不知道确切的原因对于 7，但我可以根据 gc 源代码的经验猜测，这个值不会减慢编译速度太多，但仍保留对大多数函数的优化

今天带大家了解了的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~