Go 语言内存管理（三）：逃逸分析Go 语言较之 C 语言一个很大的优势就是自带 GC 功能，可 GC 并不是没有代价的 。写 C 语言的时候 ， 在一个函数内声明的变量 ， 在函数退出后会自动释放掉，因为这些变量分配在栈上 。如果你期望变量的数据可以在函数退出后仍然能被访问，就需要调用malloc方法在堆上申请内存，如果程序不再需要这块内存了 ， 再调用free方法释放掉 。Go 语言不需要你主动调用malloc来分配堆空间，编译器会自动分析，找出需要malloc的变量，使用堆内存 。编译器的这个分析过程就叫做逃逸分析 。
所以你在一个函数中通过dict := make(map[string]int)创建一个 map 变量，其背后的数据是放在栈空间上还是堆空间上，是不一定的 。这要看编译器分析的结果 。
可逃逸分析并不是百分百准确的 ， 它有缺陷 。有的时候你会发现有些变量其实在栈空间上分配完全没问题的 ， 但编译后程序还是把这些数据放在了堆上 。如果你了解 Go 语言编译器逃逸分析的机制 ， 在写代码的时候就可以有意识地绕开这些缺陷，使你的程序更高效 。
Go 语言虽然在内存管理方面降低了编程门槛，即使你不了解堆栈也能正常开发，但如果你要在性能上较真的话 ， 还是要掌握这些基础知识 。
这里不对堆内存和栈内存的区别做太多阐述 。简单来说就是 ， 栈分配廉价，堆分配昂贵 。栈空间会随着一个函数的结束自动释放，堆空间需要时间 GC 模块不断地跟踪扫描回收 。如果对这两个概念有些迷糊，建议阅读下面 2 个文章：
这里举一个小例子，来对比下堆栈的差别：
stack函数中的变量i在函数退出会自动释放；而heap函数返回的是对变量i的引用，也就是说heap()退出后，表示变量i还要能被访问，它会自动被分配到堆空间上 。
他们编译出来的代码如下：
逻辑的复杂度不言而喻，从上面的汇编中可看到，heap()函数调用了runtime.newobject()方法，它会调用mallocgc方法从mcache上申请内存，申请的内部逻辑前面文章已经讲述过 。堆内存分配不仅分配上逻辑比栈空间分配复杂，它最致命的是会带来很大的管理成本，Go 语言要消耗很多的计算资源对其进行标记回收（也就是 GC 成本） 。
Go 编辑器会自动帮我们找出需要进行动态分配的变量，它是在编译时追踪一个变量的生命周期，如果能确认一个数据只在函数空间内访问，不会被外部使用 ， 则使用栈空间 ， 否则就要使用堆空间 。
我们在go build编译代码时 ， 可使用-gcflags '-m'参数来查看逃逸分析日志 。
以上面的两个函数为例 ， 编译的日志输出是：
日志中的i escapes to heap表示该变量数据逃逸到了堆上 。
需要使用堆空间 ， 所以逃逸，这没什么可争议的 。但编译器有时会将不需要使用堆空间的变量 ， 也逃逸掉 。这里是容易出现性能问题的大坑 。网上有很多相关文章，列举了一些导致逃逸情况，其实总结起来就一句话：
多级间接赋值容易导致逃逸。
这里的多级间接指的是，对某个引用类对象中的引用类成员进行赋值 。Go 语言中的引用类数据类型有func,interface,slice,map,chan,*Type(指针)。
记住公式Data.Field = Value，如果Data,Field都是引用类的数据类型，则会导致Value逃逸 。这里的等号=不单单只赋值，也表示参数传递 。
根据公式，我们假设一个变量data是以下几种类型，相应的可以得出结论：
下面给出一些实际的例子：
如果变量值是一个函数，函数的参数又是引用类型，则传递给它的参数都会逃逸 。
上例中te的类型是func(*int) ， 属于引用类型 ， 参数*int也是引用类型，则调用te(j)形成了为te的参数(成员)*int赋值的现象，即te.i = j会导致逃逸 。代码中其他几种调用都没有形成 多级间接赋值 情况 。
同理，如果函数的参数类型是slice,map或interface{}都会导致参数逃逸 。
匿名函数的调用也是一样的，它本质上也是一个函数变量 。有兴趣的可以自己测试一下 。
只要使用了Interface类型(不是interafce{})，那么赋值给它的变量一定会逃逸 。因为interfaceVariable.Method()先是间接的定位到它的实际值 ， 再调用实际值的同名方法，执行时实际值作为参数传递给方法 。相当于interfaceVariable.Method.this = realValue
向 channel 中发送数据，本质上就是为 channel 内部的成员赋值，就像给一个 slice 中的某一项赋值一样 。所以chan *Type,chan map[Type]Type,chan []Type,chan interface{}类型都会导致发送到 channel 中的数据逃逸 。
这本来也是情理之中的，发送给 channel 的数据是要与其他函数分享的，为了保证发送过去的指针依然可用，只能使用堆分配 。
可变参数如func(arg ...string)实际与func(arg []string)是一样的，会增加一层访问路径 。这也是fmt.Sprintf总是会使参数逃逸的原因 。
例子非常多，这里不能一一列举，我们只需要记住分析方法就好，即，2 级或更多级的访问赋值会容易导致数据逃逸 。这里加上容易二字是因为随着语言的发展，相信这些问题会被慢慢解决，但现阶段，这个可以作为我们分析逃逸现象的依据 。
下面代码中包含 2 种很常规的写法，但他们却有着很大的性能差距，建议自己想下为什么 。
Benchmark 和 pprof 给出的结果:
熟悉堆栈概念可以让我们更容易看透 Go 程序的性能问题，并进行优化 。
多级间接赋值会导致 Go 编译器出现不必要的逃逸，在一些情况下可能我们只需要修改一下数据结构就会使性能有大幅提升 。这也是很多人不推荐在 Go 中使用指针的原因，因为它会增加一级访问路径，而map,slice,interface{}等类型是不可避免要用到的，为了减少不必要的逃逸 ， 只能拿指针开刀了 。
大多数情况下，性能优化都会为程序带来一定的复杂度 。建议实际项目中还是怎么方便怎么写，功能完成后通过性能分析找到瓶颈所在，再对局部进行优化 。
【golang】内存逃逸常见情况和避免方式因为如果变量go语言逃逸分析的内存发生逃逸go语言逃逸分析，它的生命周期就是不可知的go语言逃逸分析 ， 其会被分配到堆上go语言逃逸分析，而堆上分配内存不能像栈一样会自动释放，为了解放程序员双手，专注于业务的实现 ， go实现了gc垃圾回收机制，但gc会影响程序运行性能，所以要尽量减少程序的gc操作 。
【go语言逃逸分析 go 逃逸分析】 1、在方法内把局部变量指针返回，被外部引用，其生命周期大于栈 ， 则溢出 。
2、发送指针或带有指针的值到channel，因为编译时候无法知道那个goroutine会在channel接受数据，编译器无法知道什么时候释放 。
3、在一个切片上存储指针或带指针的值 。比如[]*string，导致切片内容逃逸，其引用值一直在堆上 。
4、因为切片的append导致超出容量，切片重新分配地址，切片背后的存储基于运行时的数据进行扩充，就会在堆上分配 。
5、在interface类型上调用方法，在Interface调用方法是动态调度的，只有在运行时才知道 。
1、go语言的接口类型方法调用是动态，因此不能在编译阶段确定 ， 所有类型结构转换成接口的过程会涉及到内存逃逸发生，在频次访问较高的函数尽量调用接口 。
2、不要盲目使用变量指针作为参数，虽然减少了复制，但变量逃逸的开销更大 。
3、预先设定好slice长度 ， 避免频繁超出容量，重新分配 。
Golang的调度模型Go有四大核心模块，基本全部体现在runtime，有调度系统、GC、goroutine、channel ， 那么深入理解其中的精髓可以帮助我们理解Go这一门语言！
参考: 调度系统设计精要
下面是我用Go语言简单写的一个调度器，大家可以看看设计思路，以及存在的问题！
1、测试条件 ， 调度器只启动两个线程，然后一个线程主要是负责循环的添加任务，一个线程循环的去执行任务
2、测试条件 ， 调度器启动三个线程，然后两个线程去执行任务，一个添加任务
3、继续测试，启动十个线程，一个添加任务，九个执行任务
4、我们添加一些阻塞的任务
执行可以看到完全不可用
1、 可以看到随着M的不断的增加，可以发现执行任务的数量也不断的减少，原因是什么呢？有兴趣的同学可以加一个pprof可以看看，其实大量的在等待锁的过程！
2、如果我的M运行了类似于Sleep操作的方法如何解决了，我的调度器还能支撑这个量级的调度吗？
关于pprof如何使用：在代码头部加一个这个代码：
我们查看一下go tool pprof main/prof.pporf
可以看到真正执行代码的时间只有 0.17s0.02s 其他时间都被阻塞掉了！
1、GM模型中的所有G都是放入到一个queue，那么导致所有的M取执行任务时都会去竞争锁，我们插入G也会去竞争锁，所以解决这种问题一般就是减少对单一资源的竞争，那就是桶化 ， 其实就是每个线程都分配一个队列
2、GM模型中没有任务状态，只有runnable，假如任务遇到阻塞，完全可以把任务挂起再唤醒
这里其实会遇到一个问题，假如要分配很多个线程，那么此时随着线程的增加 ， 也会造成队列的增加，其实也会造成调度器的压力，因为它需要遍历全部线程的队列去分配任务以及后续会讲到的窃取任务！
因为我们知道CPU的最大并行度其实取决于CPU的核数 ， 也就是我们没必要为每个线程都去分配一个队列，因为就算是给他们分配了，他们自己去那执行调度 ， 其实也会出现大量阻塞，原因就是CPU调度不过来这些线程！
Go里面是只分配了CPU个数的队列，这里就是P这个概念 ， 你可以理解为P其实是真正的资源分配器，M很轻只是执行程序 ， 所有的资源内存都维护在P上！M只有绑定P才能执行任务（强制的）！
这样做的好处：
1、首先调度程序其实就是调度不同状态的任务，go里面为Go标记了不同的状态，其实大概就是分为：runnable，running，block等 ， 所以如何充分调度不同状态的G成了问题 ， 那么关于阻塞的G如何解决，其实可以很好的解决G调度的问题！
上面这些情况其实就分为：
2、用户态阻塞，一般Go里面依靠gopark函数去实现 ， 大体的代码逻辑基本上和go的调度绑定死了
源码在：
3、其实对于netpool 这种nio模型，其实内核调用是非阻塞的，所以go开辟了一个网络轮训器队列，来存放这些被阻塞的g，等待内核被唤醒！那么什么时候会被唤醒了，其实就是需要等待调度器去调度了！
4、如果是内核态阻塞了（内核态阻塞一般都会将线程挂起 ， 线程需要等待被唤醒），我们此时P只能放弃此线程的权利 ， 然后再找一个新的线程去运行P！
关于着新线程：找有没有idle的线程，没有就会创建一个新的线程！
关于当内核被唤醒后的操作：因为GPM模型所以需要找到个P绑定 ， 所以G会去尝试找一个可用的P，如果没有可用的P ， G会标记为runnable放到全局队列中！
5、其实了解上面大致其实就了解了Go的基本调度模型
答案文章里慢慢品味！
如果某个 G 执行时间过长，其他的 G 如何才能被正常的调度？ 这便涉及到有关调度的两个理念：协作式调度与抢占式调度 。协作式和抢占式这两个理念解释起来很简单： 协作式调度依靠被调度方主动弃权；抢占式调度则依靠调度器强制将被调度方被动中断 。
例如下面的代码，我本地的版本是go1.13.5
执行:GOMAXPROCS=1配置全局只能有一个P
可以看到main函数无法执行!也就是那个go 空转抢占了整个程序
备注：
但是假如我换为用 1.14 版本执行，有兴趣的话可以使用我的docker镜像，直接可以拉?。?fanhaodong/golang:1.15.11和fanhaodong/golang:1.13.5
首先我们知道G/M/P，G可能和M也可能和P解除绑定，那么关于数据变量放在哪哇！其实这个就是逃逸分析！
输出可以看到其实没有发生逃逸，那是因为 demo被拷贝它自己的栈空间内
备注：
-gcflags"-N -l -m"其中-N禁用优化-l禁止内联优化，-m打印逃逸信息
那么继续改成这个
可以看到发现 demo对象其实被逃逸到了堆上！这就是不会出现类似于G如果被别的M执行 ， 其实不会出现内存分配位置的问题！
所以可以看到demo其实是copy到了堆上！这就是g逃逸的问题，和for循环一样的
执行可以发现 ， 其实x已经逃逸到了堆上，所以你所有的g都引用的一个对象，如何解决了
如何解决了，其实很简单
也谈goroutine调度器
图解Go运行时调度器
Go语言回顾：从Go 1.0到Go 1.13
Go语言原本
调度系统设计精要
Scalable Go Scheduler Design Doc
go语言逃逸分析的介绍就聊到这里吧，感谢你花时间阅读本站内容 ， 更多关于go 逃逸分析、go语言逃逸分析的信息别忘了在本站进行查找喔 。
推荐阅读
- java的md5加密代码的简单介绍
- 手机怎么关闭设置界面广告，手机怎么关闭设置界面广告推送
- macosx虚拟机，mac1015虚拟机
- 编程小白go语言 go 编程
- 视频营销什么平台口碑好，豆瓣是短视频营销平台吗
- 笔字体下载，字体笔刷下载
- jquery写登录简单的，jquery实现登录跳转页面
- python大写字母函数 python 大写字母个数
- sqlserver中split，SQLSERVER游标循环