Go坑:time.After可能导致的内存泄露问题分析

这篇具有很好参考价值的文章主要介绍了Go坑:time.After可能导致的内存泄露问题分析。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

Go 中 time.After 可能导致的内存泄露

一、Time 包中定时器函数

go v1.20.4

定时函数:NewTicker,NewTimer 和 time.After 介绍

time 包中有 3 个比较常用的定时函数:NewTicker,NewTimer 和 time.After:

  • NewTimer: 表示在一段时间后才执行,默认情况下执行一次。如果想再次执行,需要调用 time.Reset() 方法,这时类似于 NewTicker 定时器了。可以调用 stop 方法停止执行。
  func NewTimer(d Duration) *Timer
  // NewTimer 创建一个新的 Timer,它将至少持续时间 d 之后,在向通道中发送当前时间
  // d 表示间隔时间
  
 type Timer struct {
  	C <-chan Time
	r runtimeTimer
  }

重置 NewTimer 定时器的 Reset() 方法,它是定时器在持续时间 d 到期后,用这个方法重置定时器让它再一次运行,如果定时器被激活返回 true,如果定时器已过期或停止,在返回 false。

func (t *Timer) Reset(d Duration) bool
  • 用 Reset 方法需要注意的地方:

如果程序已经从 t.C 接收到了一个值,则已知定时器已过期且通道值已取空,可以直接调用 time.Reset 方法;

如果程序尚未从 t.C 接收到值,则要先停止定时器 t.Stop(),再从 t.C 中取出值,最后调用 time.Reset 方法。

综合上面 2 种情况,正确使用 time.Reset 方法就是:

if !t.Stop() {
	<-t.C
}
t.Reset(d)
  • Stop 方法
func (t *Timer) Stop() bool
// 如果定时器已经过期或停止,返回 false,否则返回 true

Stop 方法能够阻止定时器触发,但是它不会关闭通道,这是为了防止从通道中错误的读取值。

为了确保调用 Stop 方法后通道为空,需要检查 Stop 方法的返回值并把通道中的值清空,如下:

if !t.Stop() {
 <-t.C
}
  • NewTicker: 表示每隔一段时间运行一次,可以执行多次。可以调用 stop 方法停止执行。

    func NewTicker(d Duration) *Ticker
    

    NewTicker 返回一个 Ticker,这个 Ticker 包含一个时间的通道,每次重置后会发送一个当前时间到这个通道上。

    d 表示每一次运行间隔的时间。

  • time.After: 表示在一段时间后执行。其实它内部调用的就是 time.Timer 。

    func After(d Duration) <-chan Time
    

​ 跟它还有一个相似的函数 time.AfterFunc,后面运行的是一个函数。

NewTicker 代码例子:

package main

import (
	"fmt"
	"time"
)

func main() {
	ticker := time.NewTicker(time.Second)
	defer ticker.Stop()
	done := make(chan bool)
	go func() {
		time.Sleep(10 * time.Second)
		done <- true
	}()
	for {
		select {
		case <-done:
			fmt.Println("Done!")
			return
		case t := <-ticker.C:
			fmt.Println("Current time: ", t)
		}
	}
}

二、time.After 导致的内存泄露

基本用法

time.After 方法是在一段时间后返回 time.Time 类型的 channel 消息,看下面源码就清楚返回值类型:

// https://github.com/golang/go/blob/go1.20.4/src/time/sleep.go#LL156C1-L158C2
func After(d Duration) <-chan Time {
	return NewTimer(d).C
}

// https://github.com/golang/go/blob/go1.20.4/src/time/sleep.go#LL50C1-L53C2
type Timer struct {
	C <-chan Time
	r runtimeTimer
}

从代码可以看出它底层就是 NewTimer 实现。

一般可以用来实现超时检测:

package main

import (
	"fmt"
	"time"
)

func main() {
	ch1 := make(chan string, 1)

	go func() {
		time.Sleep(time.Second * 2)
		ch1 <- "hello"
	}()

	select {
	case res := <-ch1:
		fmt.Println(res)
	case <-time.After(time.Second * 1):
		fmt.Println("timeout")
	}
}

有问题代码

上面的代码运行是没有什么问题的,不会导致内存泄露。

那问题会出在什么地方?

在有些情况下,select 需要配合 for 不断检测通道情况,问题就有可能出在 for 循环这里。

修改上面的代码,加上 for + select,为了能显示的看出问题,加上 pprof + http 代码,

timeafter.go:

package main

import (
	"fmt"
	"net/http"
	_ "net/http/pprof"
	"time"
)

func main() {
	fmt.Println("start...")
	ch1 := make(chan string, 120)

	go func() {
		// time.Sleep(time.Second * 1)
		i := 0
		for {
			i++
			ch1 <- fmt.Sprintf("%s %d", "hello", i)
		}

	}()

	go func() {
		// http 监听8080, 开启 pprof
		if err := http.ListenAndServe(":8080", nil); err != nil {
			fmt.Println("listen failed")
		}
	}()

	for {
		select {
		case _ = <-ch1:
			// fmt.Println(res)
		case <-time.After(time.Minute * 3):
			fmt.Println("timeout")
		}
	}
}

在终端上运行代码:go run timeafter.go

然后在开启另一个终端运行:go tool pprof -http=:8081 http://localhost:8080/debug/pprof/heap

运行之后它会自动在浏览器上弹出 pprof 的浏览界面,http://localhost:8081/ui/ 。

本机运行一段时间后比较卡,也说明程序有问题。可以在运行一段时间后关掉运行的 Go 程序,避免电脑卡死。

用pprof分析问题代码

在浏览器上查看 pprof 图,http://localhost:8081/ui/ ,

Go坑:time.After可能导致的内存泄露问题分析

从上图可以看出,内存使用暴涨(不关掉程序还会继续涨)。而且暴涨的内存集中在 time.After 上,上面分析了 time.After 实质调用的就是 time.NewTimer,从图中也可以看出。它调用 time.NewTimer 不断创建和申请内存,何以看出这个?继续看下面分析,

再来看看哪段代码内存使用最高,还是用 pprof 来查看,浏览 http://localhost:8081/ui/source

timeafter.go

Go坑:time.After可能导致的内存泄露问题分析

上面调用的 Go 源码 NewTimer,

Go坑:time.After可能导致的内存泄露问题分析

Go坑:time.After可能导致的内存泄露问题分析

从上图数据分析可以看出最占用内存的那部分代码,src/time/sleep.go/NewTimer 里的 c 和 t 分配和申请内存,最占用内存。

如果不强行关闭运行程序,这里内存还会往上涨。

为什么会出现内存一直涨呢?

在程序中加了 for 循环,for 循环都会不断调用 select,而每次调用 select,都会重新初始化一个新的定时器 Timer(调用time.After,一直调用它就会一直申请和创建内存),这个新的定时器会增加到时间堆中等待触发,而定时器启动前,垃圾回收器不会回收 Timer(Go源码注释中有解释),也就是说 time.After 创建的内存资源需要等到定时器执行完后才被 GC 回收,一直增加内存 GC 却不回收,内存肯定会一直涨。

当然,内存一直涨最重要原因还是 for 循环里一直在申请和创建内存,其它是次要 。

// https://github.com/golang/go/blob/go1.20.4/src/time/sleep.go#LL150C1-L158C2

// After waits for the duration to elapse and then sends the current time
// on the returned channel. 
// It is equivalent to NewTimer(d).C.
// The underlying Timer is not recovered by the garbage collector
// until the timer fires. If efficiency is a concern, use NewTimer
// instead and call Timer.Stop if the timer is no longer needed.
func After(d Duration) <-chan Time {
	return NewTimer(d).C
}
// 在经过 d 时段后,会发送值到通道上,并返回通道。
// 底层就是 NewTimer(d).C。
// 定时器Timer启动前不会被垃圾回收器回收,定时器执行后才会被回收。
// 如果担心效率问题,可以使用 NewTimer 代替,如果不需要定时器可以调用 Timer.Stop 停止定时器。

在上面的程序中,time.After(time.Minute * 3) 设置了 3 分钟,也就是说 3 分钟后才会执行定时器任务。而这期间会不断被 for 循环调用 time.After,导致它不断创建和申请内存,内存就会一直往上涨。

那怎么解决循环调用的问题?解决了,就可能解决内存一直往上涨的问题。

解决问题

既然是 for 循环一直调用 time.After 导致内存暴涨问题,那不循环调用 time.After 行不行?

修改后的代码如下:

package main

import (
	"fmt"
	"net/http"
	_ "net/http/pprof"
	"time"
)

func main() {
	fmt.Println("start...")
	ch1 := make(chan string, 120)

	go func() {
		// time.Sleep(time.Second * 1)
		i := 0
		for {
			i++
			ch1 <- fmt.Sprintf("%s %d", "hello", i)
		}

	}()

	go func() {
		// http 监听8080, 开启 pprof
		if err := http.ListenAndServe(":8080", nil); err != nil {
			fmt.Println("listen failed")
		}
	}()
	// time.After 放到 for 外面
	timeout := time.After(time.Minute * 3)
	for {
		select {
		case _ = <-ch1:
			// fmt.Println(res)
		case <-timeout:
			fmt.Println("timeout")
			return
		}
	}
}

在终端上运行代码,go run timeafter1.go

等待半分钟左右,在另外一个终端上运行 go tool pprof -http=:8081 http://localhost:8080/debug/pprof/heap

自动在浏览器上弹出界面 http://localhost:8081/ui/ ,我这里测试,界面没有任何数据显示,说明修改后的程序运行良好。

在 Go 的源码中 After 函数注释说了为了更有效率,可以使用 NewTimer ,那我们使用这个函数来改造上面的代码,

package main

import (
	"fmt"
	"net/http"
	_ "net/http/pprof"
	"time"
)

func main() {
	fmt.Println("start...")
	ch1 := make(chan string, 120)

	go func() {
		// time.Sleep(time.Second * 1)
		i := 0
		for {
			i++
			ch1 <- fmt.Sprintf("%s %d", "hello", i)
		}

	}()

	go func() {
		// http 监听8080, 开启 pprof
		if err := http.ListenAndServe(":8080", nil); err != nil {
			fmt.Println("listen failed")
		}
	}()

	duration := time.Minute * 2
	timer := time.NewTimer(duration)
	defer timer.Stop()
	for {
		timer.Reset(duration) // 这里加上 Reset()
		select {
		case _ = <-ch1:
			// fmt.Println(res)
		case <-timer.C:
			fmt.Println("timeout")
			return
		}
	}
}

在上面的实现中,也把 NewTimer 放在循环外面,并且每次循环中都调用了 Reset 方法重置定时时间。

测试,运行 go run timeafter1.go,然后多次运行 go tool pprof -http=:8081 http://localhost:8080/debug/pprof/heap ,查看 pprof,我这里测试每次数据都是空白,说明程序正常运行。

三、网上一些错误分析

for循环每次select的时候,都会实例化一个一个新的定时器。该定时器在多少分钟后,才会被激活,但是激活后已经跟select无引用关系,被gc给清理掉。换句话说,被遗弃的time.After定时任务还是在时间堆里面,定时任务未到期之前,是不会被gc清理的

上面这种分析说明,最主要的还是没有说清楚内存暴涨的真正内因。如果用 pprof 的 source 分析查看,就一目了然,那就是 NewTimer 里的 2 个变量创建和申请内存导致的。


也欢迎到我的公众号 【九卷技术录】 Go坑:time.After可能导致的内存泄露问题分析 讨论文章来源地址https://www.toymoban.com/news/detail-432841.html

四、参考

  • https://pkg.go.dev/time#pkg-overview
  • https://github.com/golang/go/blob/go1.20.4/src/time/sleep.go
  • https://www.cnblogs.com/jiujuan/p/14588185.html pprof 基本使用
  • 《100 Go Mistakes and How to Avoid Them》 作者:Teiva Harsanyi

到了这里,关于Go坑:time.After可能导致的内存泄露问题分析的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • go 内存泄露

    事件回顾 9.15号晚18点服务端发版 9.16号晚21点监控显示自发版后服务器 TCP_alloc 指标一路飙升至40K(如图) 问题分析 看到 tcp_alloc 指标异常,初步怀疑有tcp连接创建后未关闭,应该是上次发版写了什么代码导致的。回顾此次发版清单,问题应该出现在了daemon服务心跳上报上。 d

    2024年02月07日
    浏览(46)
  • 注意避坑!Java 内部类持有外部类会导致内存泄露。。。

    本文介绍 Java 内部类持有外部类导致内存泄露的原因以及其解决方案。 为什么内部类持有外部类会导致内存泄露 非静态内部类会持有外部类,如果有地方引用了这个非静态内部类,会导致外部类也被引用,垃圾回收时无法回收这个外部类(即使外部类已经没有其他地方在使

    2024年02月09日
    浏览(51)
  • .NET 6 在 Win7 系统证书链错误导致 HttpWebRequest 内存泄露

    本文记录我将应用迁移到 dotnet 6 之后,在 Win7 系统上,因为使用 HttpWebRequest 访问一个本地服务,此本地服务开启 https 且证书链在此 Win7 系统上错误,导致应用内存泄露问题。本文记录此问题的原因以及调查过程 核心原因是在 CRYPT32.dll 上的 CertGetCertificateChain 方法存在内存泄

    2024年02月06日
    浏览(49)
  • lettuce.core.RedisCommandTimeoutException: Command timed out after 1 minute(s) timeout 60000超时问题

    有一台服务器 java程序不定期会出现Redis command timed out; nested exception is io.lettuce.core.RedisCommandTimeoutException: Command timed out after 1 minute(s) 错误,导致应用出现 timeout 60000 错误,重启应用后,问题修复,但还是会不定期出现该问题。查看应用日志,发现有如下错误: 出现timeout 600

    2024年02月16日
    浏览(50)
  • Java 内存泄露问题详解

    目录 1、什么是内存泄露? 2、Java 中可能导致内存泄露的场景 3、长生命周期对象持有短生命周期对象引用造成的内存泄露问题示例 4、静态集合类持有对象引用造成内存泄露问题的示例 1、什么是内存泄露?         内存泄露指的是程序运行时未能正确释放不再使用的内

    2024年02月09日
    浏览(41)
  • 记录线上排查内存泄露问题

    记录一次云上排查内存泄露的问题,最近监控告警云上有空指针异常报出,于是找到运维查日志定位到具体是哪一行代码抛出的空指针异常, 发现是在解析cookie的一个方法内,调用HttpServletRequest.getServerName()获取不到抛出的NPE,这个获取服务名获取不到,平时都没有出现过的

    2024年02月03日
    浏览(37)
  • 用jprofiler来分析 jvm 堆 内存泄露,fullgc

    jvm 命令和工具_个人渣记录仅为自己搜索用的博客-CSDN博客   方法1: 重新设置堆后,重启,复现.   方法2:  切割  官网文档 JProfiler Help - HPROF snapshots heap walker教学: 用jprofile查看hprof文件_hprof jprofile_java老张的博客-CSDN博客 通识教学: JVM监控及诊断工具GUI篇之JProfiler_每天都要进步一

    2024年02月08日
    浏览(92)
  • Java应用堆外内存泄露问题排查

    最近有个java应用在做压力测试 压测环境配置: CentOS系统 4核CPU 8g内存 jdk1.6.0_25,jvm配置-server -Xms2048m -Xmx2048m 出现问题如下 执行300并发,压测持续1个小时后内存使用率从20%上升到100%,tps从1100多降低到600多。 首先使用top命令查看内存占用如下 然后查看java堆内存分布情况,查

    2024年02月12日
    浏览(37)
  • JavaScript 使用 splice 方法删除数组元素可能导致的问题

    splice() 方法通过删除或替换现有元素或者原地添加新的元素来修改数组,并以数组形式返回被修改的内容。此方法会改变原数组。 JavaScript 遍历数组并通过 splice 方法删除该数组符合某些条件的元素将会导致哪些问题? 当使用 splice 方法从 JavaScript 数组中删除元素时,可能会

    2023年04月23日
    浏览(42)
  • 可能导致balenaEtcher写入出错的原因以及如何解决这些问题

    balenaEtcher是一款流行的免费开源烧录软件,它能够帮助用户将ISO映像文件或者img文件烧录到USB闪存驱动器或SD卡上。尽管balenaEtcher使用简单,但有时候在烧录过程中可能会出现错误。下面是一些可能导致balenaEtcher写入出错的原因以及如何解决这些问题: 1.不正确的映像文件:

    2024年02月05日
    浏览(116)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包