背景
Go 语言中有对应的Go 内存回收机制,在Go采用 并发三色标记清除
算法, 但是由于实际的过程中 发现会有一些内存泄漏的常见,内存泄漏 分为: 临时性 和 永久性内存泄漏。
初步排查过程中: 发现Linux使用top 发现内存随着时间会持续的增加没有稳定在一个合理值中。
在使用 pprof ,BBC
等 Go的内存泄漏工具进行排查
临时性内存泄漏
指的释放内存 不及时,对应的内存在更晚时候释放,这类问题主要是 string,slice 和底层的Buffer 错误共享,或者defer 函数资源没有及时的释放。
- 数组不正常使用导致内存泄漏
数组作为形参 遵守的是 值拷贝,如果函数调用次数很多并且数组过大,导致 内存使用激增
func countTragetBigNum(nums [1000000]int, target int) int {
num := 0
for i :=0; i< len(nums) && nums[i] ==target ; i++ {
num += 1
}
return num
}
# 在短时间内 创建100万数组 内存是8M,短时间内调用 100 次,并且作为是形参 在Go进行是 值Copy ,800M, 所以在时间过程中:
大数组在形参的场景下,通常使用的是切片方式。或者使用指针进行传递,避免在短时间内内存激增
- goroutine 没有及时释放
一个 goroutine 创建 2KB
1. 互斥锁没有释放
func mutexTest() {
mutex := sync.Mutex{}
for i := 0; i < 10; i++ {
go func () {
mutex.Lock()
fmt.Printf("%d goroutine get mutex", i)
time.Sleep(100 * time.Microsecond)
}()
}
}
2. 死锁情形
3. 空channel --声明空channel但是没有初始化 导致读写被阻塞
func channelTest(){
// 声明空 channel且不初始化导致阻塞
var c chan int
// 向通道中写数据
go func() {
c <- 1
fmt.Printf("g1 send message")
}()
// 从通道中读数据
go func(){
<- c
fmt.Printf("g2 receive message")
}()
}
4. 能进不能出, 能出不能进 (写和读 通道量不一致)
导致大量的协程被阻塞
func channelTest() {
// 声明空 channel且不初始化导致阻塞
var c chan int
// 10 个向通道中写数据,导致 写大于读量
// 10个通道读数据,1个通道写数据也是一样的
for i := 0; i < 10; i++ {
go func() {
c <- i
fmt.Printf("g1 send message")
}()
}
// 从通道中读数据
go func() {
<-c
fmt.Printf("g2 receive message")
}()
}
5. Time 定时器使用 定时器没有 手动Stop 会一直占有内存
func tickerTest() {
ticker := time.NewTicker(time.Second * 20)
go func() {
for t := range ticker.C {
fmt.Printf("ticker trigger")
}
}()
time.Sleep(time.Second * 20)
ticker.Stop()
}
通道理解
通道 channel 属于Go语言中首次提出的 运用 goroutine 的进行数据交换的 容器;
- 缓冲通道 属于一个元素队列, 有先入先出原则, 属于
线程安全
- 如果通道 满了, 发送goroutine 会阻塞直到 read goroutine 进行接收操作
- 如果通道是 空的, 执行接收goroutine 阻塞直到 write goroutine 在通道上发送数据;
- 通道既不满也不空,所以通道的缓冲区将发送和接收 goroutine 进行解耦操作
如果程序直到 缓冲区的容量, 可以调用 内置的 cap函数 cap(ch) -- 缓冲区容量
len(ch) -- 缓冲区内 元素个数
goroutine 泄漏: 使用一个无缓冲通道,两个慢的 goroutine 卡住,发送的响应的结果没有其他的goroutine 接收 这个情况属于 goroutine 泄漏;
- 如果读速度比较快,缓冲区存是没有意义的