Go Ticker资源泄露案例
前言
前面我们研究了Ticker的实现原理,已经知道Ticker如果不主动停止会有资源泄露的问题。
本节介绍一个真实的案例,重点分析产生资源泄露的现象以及排查思路。
应用背景
曾经做过一个产品,不经意间出现了CPU使用率缓慢升高,最后CPU使用率竟然达到了100%,严重影响了业务。经过排查,问题出在Ticker的使用方式上,创建了Ticker,在使用结束后没有释放导致的。
该产品需要监控其他服务器的健康状态,其中很常见的一种做法是心跳检测。简单的说,周期性的ping这些服务器,能在指定时间内收到ack说明与该服务器之间的网络没问题。
当时使用了一个小众的开源组件tatsushid/go-fastping
来做ping。 该组件介绍如下图所示:
问题现象
在做性能测试时,管理了1000台服务器,差不多4天后发现系统越来越慢,查看CPU使用情况,结果发现CPU使用率已经达到100%。
排查性能问题主要使用pprof,关于pprof的使用方法及原理介绍在请参照相关章节。
使用pprof查看CPU使用情况,主要是查看CPU都在忙什么:
从上图可以看出,CPU主要是被runtime包占用了,其中第二行runtime.siftdownTimer
正是timerproc中的一个动作。
再使用pprof查看函数调用栈,主要看是哪些函数在使用CPU:
从上图可以看出,CPU主要是被ping模块占用,其中ping.(*Pinger).Run
正是开源组件的一个接口。
经过pprof分析可以很清晰的指出问题出在go-fastping组件的Run()接口中,而且是与timer相关的。问题定位到这里,解决就很简单了。
此处,可以先总结一下Ticker资源泄露的现象:
- CPU使用率持续升高
- CPU使用率缓慢升高
源码分析
出问题的源码在ping.go的run()方法中。为叙述方便,对代码做了适当简化:
func (p *Pinger) run() { timeout := time.NewTicker(p.Timeout) // 创建Ticker timeout interval := time.NewTicker(p.Interval) // 创建Ticker for { select { case <-p.done: // 正常退出,未关闭Ticker wg.Wait() return case <-timeout.C: // 超时退出,未关闭Ticker close(p.done) wg.Wait() return case <-interval.C: if p.Count > 0 && p.PacketsSent >= p.Count { continue } err = p.sendICMP(conn) if err != nil { fmt.Println("FATAL: ", err.Error()) } case r := <-recv: err := p.processPacket(r) if err != nil { fmt.Println("FATAL: ", err.Error()) } } if p.Count > 0 && p.PacketsRecv >= p.Count { // 退出,未关闭Ticker close(p.done) wg.Wait() return } } }
该段代码可以看出,这个函数是有出口的,但在出口处没有关闭Ticker,导致资源泄露。
这个问题已经被修复了,可以看到修复后的局部代码如下:
timeout := time.NewTicker(p.Timeout) defer timeout.Stop() // 使用defer保证Ticker最后被关闭 interval := time.NewTicker(p.Interval) defer interval.Stop() // 使用defer保证Ticker最后被关闭
总结
有一种情况使用Ticker不主动关闭也不会造成资源泄露,比如,函数创建Ticker后就不会退出,直到进程结束。这种情况下不会持续的创建Ticker,也就不会造成资源泄露。
但是,不管哪种情况,创建一个Ticker后,紧跟着使用defer语句关闭Ticker总是好的习惯。因为,有可能别人无意间拷贝了你的部分代码,而忽略了关闭Ticker的动作。
赠人玫瑰手留余香,如果觉得不错请给个赞~
本篇文章已归档到GitHub项目,求星~ 点我即达

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Javascript 模块化指北
前言 随着 Web 技术的蓬勃发展和依赖的基础设施日益完善,前端领域逐渐从浏览器扩展至服务端(Node.js),桌面端(PC、Android、iOS),乃至于物联网设备(IoT),其中 JavaScript 承载着这些应用程序的核心部分,随着其规模化和复杂度的成倍增长,其软件工程体系也随之建立起来(协同开发、单元测试、需求和缺陷管理等),模块化编程的需求日益迫切。 JavaScript 对模块化编程的支持尚未形成规范,难以堪此重任;一时间,江湖侠士挺身而出,一路披荆斩棘,从刀耕火种过渡到面向未来的模块化方案; 更多关于我的文章和项目,欢迎关注@x-cold 概念 模块化编程就是通过组合一些__相对独立可复用的模块__来进行功能的实现,其最核心的两部分是__定义模块__和__引入模块__; 定义模块时,每个模块内部的执行逻辑是不被外部感知的,只是导出(暴露)出部分方法和数据; 引入模块时,同步 / 异步去加载待引入的代码,执行并获取到其暴露的方法和数据; 刀耕火种 尽管 JavaScript 语言层面并未提供模块化的解决方案,但利用其可__面向对象__的语言特性,外加__设计模式__加持...
- 下一篇
ActiveMQ (二)
今天继续给大家分享的是ActiveMQ,如有不足,敬请指教。 上次我们说到,我们发现消费者每次只能消费一条消息。当队列中有多条消息的时候,我们需要多次运行消费者,才能消费完这些消息。很麻烦!!!!如何解决这个问题呢? 这就需要使用ActiveMQ监听器来监听队列,持续消费消息。 一、ActiveMQ监听器 1.1 配置步骤说明 创建一个监听器对象。 修改消费者代码,加载监听器 1.2 配置步骤 1.2.1 创建监听器MyListener类 package com.xkt.listener; import javax.jms.JMSException; import javax.jms.Message; import javax.jms.MessageListener; import javax.jms.TextMessage; /** * @author lzx * */ public class MyListener implements MessageListener { @Override public void onMessage(Message message) { i...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2全家桶,快速入门学习开发网站教程
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,CentOS8安装Elasticsearch6.8.6
- 2048小游戏-低调大师作品
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- Windows10,CentOS7,CentOS8安装Nodejs环境
- CentOS7安装Docker,走上虚拟化容器引擎之路