Golang内存泄漏场景以及解决方案详析

目录
  • 1、字符串截取
  • 2、切片截取引起子切片内存泄漏
  • 3、没有重置丢失的子切片元素中的指针
  • 4、函数数组传参
  • 5、goroutine
  • 6、定时器
    • 1)time.After
    • 2)timer、ticker
  • 总结

1、字符串截取

func main() {
	var str0 = "12345678901234567890"
	str1 := str0[:10]
}

以上代码,会有10字节的内存泄漏,我们知道,str0和str1底层共享内存,只要str1一直活跃,str0 就不会被回收,10字节的内存被使用,剩下的10字节内存就造成了临时性的内存泄漏,直到str1不再活跃

如果str0足够大,str1截取足够小,或者在高并发场景中频繁使用,那么可想而知,会造成临时性内存泄漏,对性能产生极大影响。

解决方案1:string to []byte, []byte to string

func main() {
	var str0 = "12345678901234567890"
	str1 := string([]byte(str0[:10]))
}

将需要截取的部分先转换成[]byte,再转换成string,但是这种方式会产生两个10字节的临时变量,string转换[]byte时产生一个10字节临时变量,[]byte转换string时产生一个10字节的临时变量

解决方案2

func main() {
	var str0 = "12345678901234567890"
	str1 := (" " + str0[:10])[1:]
}

这种方式仍旧会产生1字节的浪费

解决方案3:strings.Builder

func main() {
	var str0 = "12345678901234567890"
	var builder strings.Builder
	builder.Grow(10)
	builder.WriteString(str0[:10])
	str1 := builder.String()
}

这种方式的缺点就是代码量过多

解决方案4:strings.Repeat

func main() {
	var str0 = "12345678901234567890"
	str1 := strings.Repeat(str0[:10], 1)
}

这种方式底层还是用到了strings.Builder,优点就是将方案3进行了封装,代码量得到了精简

2、切片截取引起子切片内存泄漏

func main() {
	var s0 = []int{1, 2, 3, 4, 5, 6, 7, 8, 9}
	s1 := s0[:5]
}

这种情况与字符串截取引起的内存泄漏情况类似,s1活跃情况下,造成s0中部分内存泄漏

解决方案:append

func main() {
	var s0 = []int{1, 2, 3, 4, 5, 6, 7, 8, 9}
	s1 := append(s0[:0:0], s0[:5]...)
}

append为内置函数,go源码src/builtin/builtin.go中释义:

// The append built-in function appends elements to the end of a slice. If
// it has sufficient capacity, the destination is resliced to accommodate the
// new elements. If it does not, a new underlying array will be allocated.
// Append returns the updated slice. It is therefore necessary to store the
// result of append, often in the variable holding the slice itself:
//	slice = append(slice, elem1, elem2)
//	slice = append(slice, anotherSlice...)
// As a special case, it is legal to append a string to a byte slice, like this:
//	slice = append([]byte("hello "), "world"...)
func append(slice []Type, elems ...Type) []Type

3、没有重置丢失的子切片元素中的指针

func main() {
	var s0 = []*int{new(int), new(int), new(int), new(int), new(int)}
	s1 := s0[1:3]
}

原切片元素为指针类型,原切片被截取后,丢失的子切片元素中的指针元素未被置空,导致内存泄漏

解决方案:元素置空

func main() {
	var s0 = []*int{new(int), new(int), new(int), new(int), new(int)}
	s0[0], s0[3], s0[4] = nil, nil, nil
	s1 := s0[1:3]
}

4、函数数组传参

Go数组是值类型,赋值和函数传参都会复制整个数组

func main() {
	var arrayA = [3]int{1, 2, 3}
	var arrayB = [3]int{}
	arrayB = arrayA
	fmt.Printf("arrayA address: %p, arrayA value: %+v\n", &arrayA, arrayA)
	fmt.Printf("arrayB address: %p, arrayB value: %+v\n", &arrayB, arrayB)
	array(arrayA)
}

func array(array [3]int) {
	fmt.Printf("array address: %p, array value: %+v\n", &array, array)
}

打印结果:

arrayA address: 0xc0000ae588, arrayA value: [1 2 3]
arrayB address: 0xc0000ae5a0, arrayB value: [1 2 3]
array address: 0xc0000ae5e8, array value: [1 2 3]

可以看到,三条打印的地址都不相同,说明数组是值传递的,这会导致什么问题呢?

如果我们在函数传参的时候用到了数组传参,且这个数组够大(我们假设数组大小为100万,64位机上消耗的内存约为800w字节,即8MB内存),或者该函数短时间内被调用N次,那么可想而知,会消耗大量内存,对性能产生极大的影响,如果短时间内分配大量内存,而又来不及GC,那么就会产生临时性的内存泄漏,对于高并发场景相当可怕。

解决方案1:采用指针传递

func main() {
	var arrayA = [3]int{1, 2, 3}
	var arrayB = &arrayA
	fmt.Printf("arrayA address: %p, arrayA value: %+v\n", &arrayA, arrayA)
	fmt.Printf("arrayB address: %p, arrayB value: %+v\n", arrayB, *arrayB)
	arrayP(&arrayA)
}

func arrayP(array *[3]int) {
	fmt.Printf("array address: %p, array value: %+v\n", array, *array)
}

打印结果:

arrayA address: 0xc00000e6a8, arrayA value: [1 2 3]
arrayB address: 0xc00000e6a8, arrayB value: [1 2 3]
array address: 0xc00000e6a8, array value: [1 2 3]

可以看到,三条打印的地址相同,说明指针是引用传递的 ,三个数组指向的都是同一块内存,就算数组很大,或者函数短时间被调用N次,也不会产生额外的内存开销,这样会不会有隐患呢?

有,如果arrayA的指针地址发生变化,那么,arrayB和函数内array的指针地址也随之改变,稍不注意,容易发生bug

解决方案2:利用切片可以很好的解决以上两个问题

func main() {
	var arrayA = [3]int{1, 2, 3}
	var arrayB = arrayA[:]
	fmt.Printf("arrayA address: %p, arrayA value: %+v\n", &arrayA, arrayA)
	fmt.Printf("arrayB address: %p, arrayB value: %+v\n", &arrayB, arrayB)
	arrayS(arrayB)
}

func arrayS(array []int) {
	fmt.Printf("array address: %p, array value: %+v\n", &array, array)
}

打印结果:

arrayA address: 0xc00000e6a8, arrayA value: [1 2 3]
arrayB address: 0xc0000040d8, arrayB value: [1 2 3]
array address: 0xc000004108, array value: [1 2 3]

可以看到,三条打印的地址都不相同,而切片本身是一个引用类型,arrayA和arrayB底层共享内存,不会产生额外内存开销,而且arrayA的指针地址发生改变,arrayB的指针地址也不会改变,切片的数据结构如下:

type slice struct {
	array unsafe.Pointer
	len   int
	cap   int
}

5、goroutine

“Go里面10次内存泄漏有9次都是goroutine泄漏引起的”

有些编码不当的情况下,goroutine被长期挂住,导致该协程中的内存也无法被释放,就会造成永久性的内存泄漏。例如协程结束时协程中的channel没有关闭,导致一直阻塞;例如协程中有死循环;等等

我们来看下

func main() {
	ticker := time.NewTicker(time.Second * 1)
	for {
		<-ticker.C
		ch := make(chan int)
		go func() {
			for i := 0; i < 100; i++ {
				ch <- i
			}
		}()

		for v := range ch {
			if v == 50 {
				break
			}
		}
	}
}

将代码运行起来,并利用pprof工具,在web输入http://localhost/debug/pprof/,我们可以看到,goroutine的数量随着时间在不断的增加,而且丝毫没有减少的迹象

这是因为break的时候,协程中的channel并没有关闭,导致协程一直存活,无法被回收

解决方案:

func main() {
	ticker := time.NewTicker(time.Second * 1)
	for {
		<-ticker.C
		cxt, cancel := context.WithCancel(context.Background())
		ch := make(chan int)
		go func(cxt context.Context) {
			for i := 0; i < 100; i++ {
				select {
				case <-cxt.Done():
					return
				case ch <- i:
				}
			}
		}(cxt)

		for v := range ch {
			if v == 50 {
				cancel()
				break
			}
		}
	}
}

利用context,在break之前cancel,目的就是通知协程退出,这样就避免了goroutine泄漏

6、定时器

1)time.After

func main() {
	ch := make(chan int)
	go func() {
		for {
			timerC := time.After(100 * time.Second)
			//timerC 每次都是重新创建的,什么意思呢?简单说来,当 select 成功监听 ch 并进入它的处理分支,下次循环 timerC 重新创建了,时间肯定就重置了。
			select {
			//如果有多个 case 都可以运行,select 会随机公平选择出一个执行。其余的则不会执行
			case num := <-ch:
				fmt.Println("get num is", num)
			case <-timerC:
				//等价于 case <-time.After(100 * time.Second)
				fmt.Println("time's up!!!")
				//done<-true
			}
		}
	}()

	for i := 1; i < 100000; i++ {
		ch <- i
		time.Sleep(time.Millisecond)
	}
}

以上代码会造成内存泄漏,time.After底层实现是一个timer,而定时器未到触发时间,该定时器不会被gc回收,从而导致临时性的内存泄漏,而如果定时器一直在创建,那么就造成了永久性的内存泄漏了。

解决方案:采用timer定时器

func main() {
	ch := make(chan int)
	go func() {
		timer := time.NewTimer(100 * time.Second)
		defer timer.Stop()
		for {
			timer.Reset(100 * time.Second)
			select {
			case num := <-ch:
				fmt.Println("get num is", num)
			case <-timer.C:
				fmt.Println("time's up!!!")
			}
		}
	}()

	for i := 1; i < 100000; i++ {
		ch <- i
		time.Sleep(time.Millisecond)
	}
}

创建timer定时器,每次需要启动定时器的时候,使用Reset方法重置定时器,这样就不用每次都要创建新的定时器了

2)timer、ticker

在高并发、高性能场景中,使用time.NewTimer或者time.NewTicker定时器,都需要注意及时调用Stop方法来及时释放资源,否则可能造成临时性或者永久性的内存泄漏。

总结

到此这篇关于Golang内存泄漏场景以及解决方案的文章就介绍到这了,更多相关Golang内存泄漏场景及解决内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • GoLang内存泄漏原因排查详解

    目录 背景 临时性内存泄漏 通道理解 背景 Go 语言中有对应的Go 内存回收机制,在Go采用 并发三色标记清除  算法, 但是由于实际的过程中 发现会有一些内存泄漏的常见,内存泄漏 分为: 临时性 和 永久性内存泄漏. 初步排查过程中: 发现Linux使用top 发现内存随着时间会持续的增加没有稳定在一个合理值中. 在使用 pprof ,BBC 等 Go的内存泄漏工具进行排查 临时性内存泄漏 指的释放内存 不及时,对应的内存在更晚时候释放,这类问题主要是 string,slice 和底层的Bu

  • Go map发生内存泄漏解决方法

    目录 正文 hamp 结构体代码 查看占用的内存数量 对于 map 内存泄漏的解法 正文 Go 程序运行时,有些场景下会导致进程进入某个“高点”,然后就再也下不来了. 比如,多年前曹大写过的一篇文章讲过,在做活动时线上涌入的大流量把 goroutine 数抬升了不少,流量恢复之后 goroutine 数也没降下来,导致 GC 的压力升高,总体的 CPU 消耗也较平时上升了 2 个点左右. 有一个 issue 讨论为什么 allgs(runtime 中存储所有 goroutine 的一个全局 sl

  • golang容易导致内存泄漏的6种情况汇总

    目录 1. 定时器使用不当 1.1 time.After()的使用 1.2 time.NewTicker资源未及时释放 2. select阻塞 2.1 导致goroutine阻塞的情况 2.2 循环空转导致CPU暴涨 3. channel阻塞 4. goroutine导致的内存泄漏 4.1 申请过多的goroutine 4.2 goroutine阻塞 4.2.1 I/O问题 4.2.2 互斥锁未释放 4.2.3 死锁 4.2.4 waitgroup使用不当 5. slice 引起的内存泄漏 6.

  • Golang内存泄漏场景以及解决方案详析

    目录 1.字符串截取 2.切片截取引起子切片内存泄漏 3.没有重置丢失的子切片元素中的指针 4.函数数组传参 5.goroutine 6.定时器 1)time.After 2)timer.ticker 总结 1.字符串截取 func main() { var str0 = "12345678901234567890" str1 := str0[:10] } 以上代码,会有10字节的内存泄漏,我们知道,str0和str1底层共享内存,只要str1一直活跃,str0 就不会被回收,10字节

  • js内存泄漏场景、如何监控及分析详解

    目录 前言 哪些情况会引起内存泄漏 1. 意外的全局变量 2. 遗忘的定时器 3. 使用不当的闭包 4. 遗漏的 DOM 元素 5. 网络回调 如何监控内存泄漏 如何分析内存泄漏,找出有问题的代码 实例分析 总结 前言 Q:什么是内存泄漏? 字面上的意思,申请的内存没有及时回收掉,被泄漏了 Q:为什么会发生内存泄漏? 虽然前端有垃圾回收机制,但当某块无用的内存,却无法被垃圾回收机制认为是垃圾时,也就发生内存泄漏了 而垃圾回收机制通常是使用标志清除策略,简单说,也就是引用从根节点开始是否可达来判定

  • Vue优化:常见会导致内存泄漏问题及优化详解

    如果你在用 Vue 开发应用,那么就要当心内存泄漏的问题.这个问题在单页应用 (SPA) 中尤为重要,因为在 SPA 的设计中,用户使用它时是不需要刷新浏览器的,所以 JavaScript 应用需要自行清理组件来确保垃圾回收以预期的方式生效.因此在vue开发过程中,你需要时刻警惕内存泄漏的问题,这些内存泄漏往往会发生在使用 Vue 之外的其它进行 DOM 操作的三方库时,请确保测试应用的内存泄漏问题并在适当的时机做必要的组件清理. 下面是我开发过程中遇到,并查资料总结的内存泄漏问题,会持续更新中

  • 总结python 三种常见的内存泄漏场景

    概要 不要以为 Python 有自动垃圾回收就不会内存泄漏,本着它有"垃圾回收"我有"垃圾代码"的精神,现在总结一下三种常见的内存泄漏场景. 无穷大导致内存泄漏 如果把内存泄漏定义成只申请不释放,那么借着 Python 中整数可以无穷大的这个特点,我们一行代码就可以完成内存泄漏了. i = 1024 ** 1024 ** 1024 循环引用导致内存泄漏 引用记数器 是 Python 垃圾回收机制的基础,如果一个对象的引用数量不为 0 那么是不会被垃圾回收的,我们可以

  • Android Handler内存泄漏原因及解决方案

    目录: 1.须知: 主线程Looper生命周期和Activity的生命周期一致. 非静态内部类,或者匿名内部类.默认持有外部类引用. 2.原因: Handler造成内存泄露的原因.非静态内部类,或者匿名内部类.使得Handler默认持有外部类的引用.在Activity销毁时,由于Handler可能有未执行完/正在执行的Message.导致Handler持有Activity的引用.进而导致GC无法回收Activity. 3.可能造成内存泄漏 匿名内部类: //匿名内部类 Handler handl

  • Android 有效的解决内存泄漏的问题实例详解

    Android 有效的解决内存泄漏的问题 Android内存泄漏,我想做Android 应用的时候遇到的话很是头疼,这里是我在网上找的不错的资料,实例详解这个问题的解决方案 前言:最近在研究Handler的知识,其中涉及到一个问题,如何避免Handler带来的内存溢出问题.在网上找了很多资料,有很多都是互相抄的,没有实际的作用. 本文的内存泄漏检测工具是:LeakCanary  github地址:https://github.com/square/leakcanary 什么是内存泄漏? 内存泄漏

  • redis 使用lettuce 启动内存泄漏错误的解决方案

    redis 使用 lettuce 出现 LEAK: hashedwheelTimer.release() was not called before it's garbage-collected. Enable advanced leak 内存泄漏.其实是内存不够大导致. 找到eclispe 中window->preferences->Java->Installed JRE ,点击右侧的Edit 按钮,在编辑界面中的 "Default VM Arguments "选项

  • macOS上使用gperftools定位Java内存泄漏问题及解决方案

    这几天在排查一个堆外内存泄漏的问题时看到很多人都提到了gperftools这个神器,想要尝试一下结果发现它对macOS的支持不太友好.而且大多数教程是针对C++的,里面的一通编译链接的操作看得我个Java仔眼花缭乱的.所以我在这里整理一份mac和Java版的使用教程,免得大家再来踩坑了. 一.简介 gperftools是google提供的一套分析工具,包括堆内存检测heap-profiler,内存泄漏分析工具heap-checker和CPU性能监测工具cpu-profiler.众所周知堆外内存的

  • C++内存泄漏及检测工具详解

    首先我们需要知道程序有没有内存泄露,然后定位到底是哪行代码出现内存泄露了,这样才能将其修复. 最简单的方法当然是借助于专业的检测工具,比较有名如BoundsCheck,功能非常强大,相信做C++开发的人都离不开它.此外就是不使用任何工具,而是自己来实现对内存泄露的监控,分如下两种情况: 一. 在 MFC 中检测内存泄漏 假如是用MFC的程序的话,很简单.默认的就有内存泄露检测的功能. 我们用VS2005生成了一个MFC的对话框的程序,发现他可以自动的检测内存泄露.不用我们做任何特殊的操作. 仔细

随机推荐