golang内存泄漏

golang也用了好几年了，趁着有空整理归纳下，以后忘了好看下
一般认为 Go 10次内存泄漏，8次goroutine泄漏，1次是真正内存泄漏，还有1次是cgo导致的内存泄漏
1:环境
go1.20
win10
2:goroutine泄漏
单个Goroutine占用内存，可参考Golang计算单个Goroutine占用内存, 在不发生栈扩张情况下, 新版本Go大概单个goroutine 占用2.6k左右的内存
Goroutine 泄露的常见原因
1>. 从 channel 里读，但是同时没有写入操作
2> 向无缓冲 channel 里写，但是同时没有读操作
3> 向已满的有缓冲 channel 里写，但是同时没有读操作
4> select操作在所有的case上都阻塞
5> goroutine进入死循环或死锁，一直结束不了

处理
<1><2><3> 少撒加撒,没什么解释的
<4> 查看 case 阻塞原因有没有缓冲什么的，为什么都阻塞，有没有超时机制
<5> 为什么死循环或死锁
来个demo

package mainimport ("fmt""net/http"_ "net/http/pprof""sync/atomic""time"
)func pprofServer() {ip := "0.0.0.0:6060"if err := http.ListenAndServe(ip, nil); err != nil {fmt.Printf("start pprof failed on %s\n", ip)}
}
// 所有chan 阻塞
func goroutineblock() {ch1 := make(chan string) // 无缓冲channelch2 := make(chan string) // 无缓冲channelgo func() {select {case <-ch1:fmt.Println("output1")case <-ch2:fmt.Println("output2")}}()
}

在这里插入图片描述

补充下 pprof
通过 http://localhost:6060/debug/pprof/CMD 获取对应的采样数据。支持的 CMD 有:
goroutine: 获取程序当前所有 goroutine 的堆栈信息。
heap: 包含每个 goroutine 分配大小，分配堆栈等。每分配 runtime.MemProfileRate(默认为512K) 个字节进行一次数据采样。
threadcreate: 获取导致创建 OS 线程的 goroutine 堆栈
block: 获取导致阻塞的 goroutine 堆栈(如 channel, mutex 等)，使用前需要先调用 runtime.SetBlockProfileRate
mutex: 获取导致 mutex 争用的 goroutine 堆栈，使用前需要先调用 runtime.SetMutexProfileFraction

GC的触发场景
在这里插入图片描述

0：gcTriggerHeap 程序检测到距上次 GC 内存分配增长超过一定比例时（默认 100%）触发,就是内存翻倍就GC
heapLive 表示当前堆中存活（正在使用）的对象的总大小。
它反映了程序当前实际使用的堆内存量。
随着程序分配新对象和释放旧对象，这个值会动态变化
gcPercent 是一个控制GC触发频率的参数。
默认值是100，表示当堆内存增长到上次GC后的2倍时触发新的GC。
可以通过环境变量 GOGC 或运行时函数 debug.SetGCPercent() 来调整。

1：gcTriggerTime 从上次GC后间隔时间达到了runtime.forcegcperiod 时间
// This is a variable for testing purposes. It normally doesn’t change.
var forcegcperiod int64 = 2 * 60 * 1e9
2：gcTriggerCycle 用户主动调用runtime.GC().

GoV1.8 三色标记法+混合写屏障法
参考 https://zhuanlan.zhihu.com/p/14541819173
垃圾回收(Garbage Collection，简称GC)是编程语言中提供的自动的内存管理机制，自动释放不需要的对象，让出存储器资源，无需程序员手动执行。
Golang中的垃圾回收主要应用三色标记法，GC过程和其他用户goroutine可并发运行，但需要一定时间的STW(stop the world)，STW的过程中，CPU不执行用户代码，全部用于垃圾回收，这个过程的影响很大，Golang进行了多次的迭代优化来解决这个问题。

三色并发标记法
三色标记法实际上就是通过三个阶段的标记来确定清楚的对象都有哪些.
1> 就是只要是新创建的对象,默认的颜色都是标记为“白色”.
2> 每次GC回收开始, 然后从根节点开始遍历所有对象，把遍历到的对象从白色集合放入“灰色”集合。
3> 遍历灰色集合，将灰色对象引用的对象从白色集合放入灰色集合，之后将此灰色对象放入黑色集合
4> 重复第三步, 直到灰色中无任何对象.
5> 回收所有的白色标记表的对象. 也就是回收垃圾.
可以看出，在三色标记法中，导致对象丢失的有两个条件：
1> 一个白色对象被黑色对象引用**(白色被挂在黑色下)**
2> 灰色对象与它之间的可达关系的白色对象遭到破坏**(灰色同时丢了该白色)**

关于 stw
Go的STW持续时间
Go的垃圾回收器通过使用并发标记和后台并发清除来尽量减少STW的时间。这意味着在大多数情况下，Go程序不会因为垃圾回收而完全停止。然而，在某些情况下，比如在高负载或大量内存分配时，Go的垃圾回收器可能会触发一个较长的STW暂停。
较短的STW：在正常情况下，特别是在使用了Go 1.3及以后版本的程序中，STW暂停通常很短，可能只有几毫秒。
较长的STW：在一些极端情况下，如果内存分配非常快或者堆的大小增长非常快，可能会触发一个较长的STW暂停。这通常发生在堆的增长超过了预设的阈值，并且系统需要一次性清理大量对象时。
如何管理和减少STW时间
优化内存使用：通过减少内存分配和优化数据结构的使用，可以降低垃圾回收的频率和STW的必要性。
调整GC参数：Go提供了多个GC调优参数（例如GOGC），可以用来调整垃圾回收的行为。例如，增加GOGC的值可以减少垃圾回收的频率，但可能会增加STW的持续时间。
使用runtime.ReadMemStats监控内存使用：通过监控内存使用情况，可以更好地理解何时会发生垃圾回收，并据此优化代码。

在补充下 Golang中协程调度器
参考 https://blog.csdn.net/tiancityycf/article/details/103857524
三个必知的核心元素。(G、M、P)
G：Goroutine的缩写，一个G代表了对一段需要被执行的Go语言代码的封装
M：Machine的缩写，一个M代表了一个内核线程，等同于系统线程
P：Processor的缩写，一个P代表了M所需的上下文环境

G需要绑定在M上才能运行；
M需要绑定P才能运行；
上所述，一个G的执行需要M和P的支持。一个M在于一个P关联之后就形成一个有效的G运行环境【内核线程 + 上下文环境】。每个P都含有一个可运行G的队列【runq】。队列中的G会被一次传递给本地P关联的M并且获得运行时机。
M 与 P 总是一对一，P 与 G 总是一对多，而一个 G 最终由一个 M 来负责运行。

简单的来说，一个G的执行需要M和P的支持。一个M在与一个P关联之后形成了一个有效的G运行环境【内核线程 + 上下文环境】。每个P都会包含一个可运行的G的队列 (runq )。队列中的G会被一次传递给本地P关联的M并且获得运行时机。
M 与 P 总是一对一，P 与 G 总是一对多，而一个 G 最终由一个 M 来负责运行。
调度器的有两大思想：

复用线程：协程本身就是运行在一组线程之上，不需要频繁的创建、销毁线程，而是对线程的复用。在调度器中复用线程还有2个体现：1）work stealing，当本线程无可运行的G时，尝试从其他线程绑定的P偷取G，而不是销毁线程。2）hand off，当本线程因为G进行系统调用阻塞时，线程释放绑定的P，把P转移给其他空闲的线程执行。

利用并行：GOMAXPROCS设置P的数量，当GOMAXPROCS大于1时，就最多有GOMAXPROCS个线程处于运行状态，这些线程可能分布在多个CPU核上同时运行，使得并发利用并行。另外，GOMAXPROCS也限制了并发的程度，比如GOMAXPROCS = 核数/2，则最多利用了一半的CPU核进行并行。

调度器的两小策略：
抢占：在coroutine中要等待一个协程主动让出CPU才执行下一个协程，在Go中，一个goroutine最多占用CPU 10ms，防止其他goroutine被饿死，这就是goroutine不同于coroutine的一个地方。
全局G队列：在新的调度器中依然有全局G队列，但功能已经被弱化了，当M执行work stealing从其他P偷不到G时，它可以从全局G队列获取G。

3：其他情况
1>slice、string 切片误用造成内存泄漏个人认为不应该叫泄漏应该叫浪费，就是你只需要吃一口饭就饱了，但你盛了一大碗饭

func main() {go pprofServer()time.Sleep(5 * time.Second)//for i := 0; i < 30; i++ {//	goroutineblock()////}//test2s0 := sliceleak(getStringWithLengthOnHeap(1 << 20)) // 1M bytesprintln("finish")  //第一次 调用  go tool pprof -http=:8081 http://localhost:6060/debug/pprof/heap time.Sleep(10 * time.Second)s0 = ""runtime.GC()  //gcTriggerTime  等2分钟太久了，手动GC一次//第2次 调用  go tool pprof -http=:8081 http://localhost:6060/debug/pprof/heap select {}println("finish2", s0)
}
// 2切片   len(s1) >3
func sliceleak(s1 string) string {s0 := s1[:3]return s0
}func getStringWithLengthOnHeap(length int) string {if length < 0 {length = 0 // 处理负长度的情况，避免创建负长度的切片}bytes := make([]byte, length) // 创建一个指定长度的字节切片for i := range bytes {        // 使用空格填充（或根据需要修改填充内容）bytes[i] = ' '}return string(bytes) // 将字节切片转换为字符串
}

一次在 println(“finish”) 后 time.Sleep(10 * time.Second) 前
第2次在等20秒后再调用的控制再手动gc 后调用
切片浪费的内存也会释放，无非是没释放前，浪费了，所以切片的如果浪费很多，用重新分配后小的再copy过去，浪费不多，可以无视
在这里插入图片描述
2>time.After()的使用

func timeleak() {chs := make(chan int, 60)go func() {var  num = 0for {num ++chs <- num }}()for true {select {case <-time.After(time.Second * 60): //定时任务未到期之前，是不会被gc清理的fmt.Printf("time.After:%v", time.Now().Unix())case num := <-chs:fmt.Printf("print:num %v\n", num )}}
//可以这么修改//delay := time.NewTimer(time.Second * 60)//defer delay.Stop()//for true {//	delay.Reset(time.Second * 60)//	select {//	case <-delay.C://		fmt.Printf("time.After:%v", time.Now().Unix())//	case v := <-chs://		fmt.Printf("print:%v\n", v)//	}//}}

print:693435
print:693436
print:693437
print:693438

间隔执行了2次

在这里插入图片描述

如改成

func timeleak() {chs := make(chan int, 100)go func() {var i = 0for {i++chs <- iif i%10 == 0 {time.Sleep(time.Millisecond)}}}()for true {select {case <-time.After(time.Second * 1000): //定时任务未到期之前，是不会被gc清理的fmt.Printf("time.After:%v", time.Now().Unix())case v := <-chs:if v%1000 == 0 {fmt.Printf("print:%v\n", v)}}}
}

在这里插入图片描述
从 10000内执行一次第2次大概是 40000-50000间
内存泄漏速度下降了好多，泄漏的速度跟 case 执行速度又关

如果用default 如下，内存泄漏更快，不用default time.After 会阻塞，用了，不阻塞了，死的更快
for loop 下的 select 中 default 需要慎用

func timeleak2() {var i int32 = 0for {select {case <-time.After(time.Second * 1000): //定时任务未到期之前，是不会被gc清理的fmt.Printf("time.After:%v", time.Now().Unix())default:i++if i < 50000 {fmt.Println("i=", i)}}}
}

在这里插入图片描述

3> 可以参考 https://blog.csdn.net/qq_38609643/article/details/144963265
这里就不一一试了
（1）未及时释放的对象引用
（2）循环引用
（3）未关闭的资源（文件、网络连接等）
（4）闭包引用外部变量
（5）使用了 sync.Pool 但没有清理
（6）不合理的 defer 使用

4>GC 频繁排查参考 https://zhuanlan.zhihu.com/p/18966775221

4：生成svg
1:http://localhost:6060/debug/pprof/heap 生成heap文件
2:把heap 文件放到执行文件同一目录
3:https://graphviz.org/download/ 下载 graphviz-12.2.1 (64-bit) ZIP archive [sha256] 配置 path ##路径不要有中文或其他标点符号有时识别不了
3: go tool pprof heap
4：执行 svg 命令生成 profile001.svg
5:浏览器打开

other 差异对比
差异对比 eg:
go tool pprof -base C:\Users\Administrator\pprof\pprof.testmemory.exe.alloc_objects.alloc_space.inuse_objects.inuse_space.008.pb.gz C:\Users\Administrator\pprof\pprof.testmemory.exe.alloc_objects.alloc_space.inuse_objects.inuse_space.009.pb.gz

5：如果觉得有用，麻烦点个赞，加个收藏