6

面试官:请你详细说说Go的逃逸分析

 1 year ago
source link: https://www.51cto.com/article/722269.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

面试官:请你详细说说Go的逃逸分析

作者:程序员升级打怪之旅 2022-11-08 11:26:13
通过本文的介绍,相信你一定加深了堆栈的理解;搞清楚逃逸分析的作用和原理之后能够指导我们写出更优雅的代码。

我们在之前有提到堆和栈的概念,要搞清楚GO的逃逸分析一定要先搞清楚堆栈的特点:

正如我们上面提到的,内存分配既可以分配到堆中,也可以分配到栈中。

那么什么样的数据会被分配到栈中,什么样的数据又会被分配到堆中呢?GO语言是如何进行内存分配的呢?其设计初衷和实现原理是什么呢?

我们先来了解一下内存管理、堆、栈的知识点:

内存管理主要包括两个动作:分配与释放。逃逸分析就是服务于内存分配,为了更好理解逃逸分析,我们再来回顾一下堆栈的特点:

在Go中,栈的内存是由编译器自动进行分配和释放,栈区往往存储着函数参数、局部变量和调用函数帧,它们随着函数的创建而分配,函数的退出而销毁。

一个goroutine对应一个栈,栈是调用栈(call stack)的简称。一个栈通常又包含了许多栈帧(stack frame),它描述的是函数之间的调用关系,每一帧对应一个尚未返回的函数调用,它本身也是以栈形式存放数据。

与栈不同的是,应用程序在运行时只会存在一个堆。

我们可以简单理解为:我们在GO开发过程中要考虑的内存管理只是针对堆内存而言的。

程序在运行期间可以主动从堆上申请内存,这些内存通过Go的内存分配器分配,并由垃圾收集器回收。

堆和栈的对比

  • 栈不需要加锁:栈是每个goroutine独有的,这就意味着栈上的内存操作是不需要加锁的。
  • 堆有时需要加锁:堆上的内存,有时需要加锁防止多线程冲突

延伸知识点:为什么堆上的内存有时需要加锁?而不是一直需要加锁呢?

因为Go的内存分配策略学习了TCMalloc的线程缓存思想,他为每个处理器P分配了一个mcache,从mcache分配内存也是无锁的

  • 堆内存管理 性能差:对于程序堆上的内存回收,还需要通过标记清除阶段,例如Go采用的三色标记法。
  • 栈内存管理 性能好:栈上的内存,它的分配与释放非常高效的。简单地说,它只需要两个CPU指令:一个是分配入栈,另外一个是栈内释放。只需要借助于栈相关寄存器即可完成。
  • 栈缓存性能更好
  • 堆缓存性能较差

原因是:栈内存能更好地利用CPU的缓存策略,因为栈空间相较于堆来说是更连续的。

上面说了这么多堆和栈的知识点,目的是为了让大家更好的理解逃逸分析。

正如我们讲的,相比于把内存分配到堆中,分配到栈中优势更明显。

Go语言也是这么做的:Go编译器会尽可能将变量分配到到栈上。

但是,当编译器无法证明函数返回的变量有没有被引用时,那么编译器就必须在堆上分配该变量,以此避免悬挂指针(dangling pointer)的问题。另外,如果局部变量占用内存非常大,也会将其分配在堆上。

Go是如何确定内存是分配到栈上还是堆上的呢?

答案就是:逃逸分析。

编译器通过逃逸分析技术去选择堆或者栈,逃逸分析的基本思想如下:检查变量的生命周期是否是完全可知的,如果通过检查,则在栈上分配。否则,就是所谓的逃逸,必须在堆上进行分配。

逃逸分析原则

Go语言虽然没有明确说明逃逸分析原则,但是有以下几点准则,是可以参考的。

  • 不同于JAVA JVM的运行时逃逸分析,Go的逃逸分析是在编译期完成的:编译期无法确定的参数类型必定放到堆中;
  • 如果变量在函数外部存在引用,则必定放在堆中;
  • 如果变量占用内存较大时,则优先放到堆中;
  • 如果变量在函数外部没有引用,则优先放到栈中;

逃逸分析举例

我们使用这个命令来查看逃逸分析的结果:go build -gcflags '-m -m -l'

1.参数是interface类型

package main

import "fmt"

func main() {
   a := 666
   fmt.Println(a)
}

运行结果

7307f27132c9fdbbdf4152276f079c4bc9187d.png

原因分析

因为Println(a ...interface{})的参数是interface{}类型,编译期无法确定其具体的参数类型,所以内存分配到堆中。

528cf7042af88d18e003749494a28d7d3dd910.png

2. 变量在函数外部有引用

package main

func test() *int {
   a := 10
   return &a
}

func main() {
   _ = test()
}

运行结果

5831eae7268fa1e16bc249cd1db9e5262e918a.png

原因分析

变量a在函数外部存在引用。

我们来分析一下执行过程:当函数执行完毕,对应的栈帧就被销毁,但是引用已经被返回到函数之外。如果这时外部通过引用地址取值,虽然地址还在,但是这块内存已经被释放回收了,这就是非法内存。

为了避免上述非法内存的情况,在这种情况下变量的内存分配必须分配到堆上。

3. 变量内存占用较大

package main

func test() {
   a := make([]int, 10000, 10000)
   for i := 0; i < 10000; i++ {
      a[i] = i
   }
}

func main() {
   test()
}

运行结果

26aa04b050371c25e0f20744153836571d7fbc.png

原因分析

我们定义了一个容量为10000的int类型切片,发生了逃逸,内存分配到了堆上(heap)。

我们再简单修改一下代码,将切片的容量和长度修改为1,再次查看逃逸分析的结果,我们发现,没有发生逃逸,内存默认分类到了栈上。

852250588eb47b09f49098021843c0a0dba1d8.png

所以,当变量占用内存较大时,会发生逃逸分析,将内存分配到堆上。

4. 变量大小不确定时

我们再简单修改一下上面的代码:

package main

func test() {
   l := 1
   a := make([]int, l, l)
   for i := 0; i < l; i++ {
      a[i] = i
   }
}

func main() {
   test()
}

运行结果

882ffd0439a3630c7da574fac4c7c298723223.png

原因分析

我们通过控制台的输出结果可以很明显的看出:发生了逃逸,分配到了heap堆中。

原因是这样的:

我们虽然在代码段中给变量 l 赋值了1,但是编译期间只能识别到初始化int类型切片时,传入的长度和容量是变量l,编译期并不能确定变量l的值,所以发生了逃逸,会把内存分配到堆中。

思考题

好了,我们举了4个逃逸分析的经典案例,相信聪明的你已经理解了逃逸分析的作用和发生逃逸的场景。

我们来想一下,在理解逃逸分析的原理之后,在开发的过程中如何更好的编码,进而提高程序的效率,更好的利用内存呢?

如何实践?

理解逃逸分析一定能帮助我们写出更好的程序。知道变量分配在栈堆之上的差别后,我们就要尽量写出分配在栈上的代码。因为堆上的变量变少后,可以减轻内存分配的开销,减小GC的压力,提高程序的运行速度。

但是我们也要有过犹不及的指导思想。

我认为没有一成不变的开发模式,我们一定是在不断的需求变化,业务变化中求得平衡的:

举个日常开发中函数传参栗子:

有些场景下我们不应该传递结构体指针,而应该直接传递结构体。

为什么会这样呢?虽然直接传递结构体需要值拷贝,但是这是在栈上完成的操作,开销远比变量逃逸后动态地在堆上分配内存少的多。

当然这种做法不是绝对的,要根据场景去分析:

  • 如果结构体较大,传递结构体指针更合适,因为指针类型相比值类型能节省大量的内存空间
  • 如果结构体较小,传递结构体更适合,因为在栈上分配内存,可以有效减少GC压力

通过本文的介绍,相信你一定加深了堆栈的理解;搞清楚逃逸分析的作用和原理之后能够指导我们写出更优雅的代码。

我们在日常开发中,要根据实际场景考虑,如何将内存尽量分配到栈中,减少GC的压力,提高性能。

如何找到应用开发效率,程序运行效率,对机器的压力及负载的平衡点,是程序员进阶之旅中的必修课。

本文转载自微信公众号「 程序员升级打怪之旅」,作者「王中阳Go」,可以通过以下二维码关注。

99aeb9810713c11ec8e014bd2707a84e0e6f1b.jpg

转载本文请联系「 程序员升级打怪之旅」公众号。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK