Golang mysql 上线的一个坑 Db.close重要性
Posted C# 风的放松天地
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Golang mysql 上线的一个坑 Db.close重要性相关的知识,希望对你有一定的参考价值。
急冲冲完成的mysql的一个监控自动处理程序上线了,线下处理是正常的,没想到线上才半小时就奔溃了。
现在时间是晚上11点,心慌焦虑涌上心头,需要熬夜?肾上腺素激增。
程序主要是一个定时任务的处理程序,主要是对mysql 的处理,初看没啥问题,操作语句都是网上搬下来的,检查了下代码,
奔溃都在什么rows.close,stmt.close,还有query这时候,非法defer,这个奔溃的最多次,还都是内存指针异常。。。 golang这调试,说实在连c++都不如,在可能我还用不惯吧,我用的是liteide
随便截取段代码:
rows, err := db.Query("select * from user;") if err != nil { log.Fatal(err) } defer rows.Close()
基本上网上大部分都是这种情况,rows.close,stmt.close 等都有,但是唯独没有db.close。为什么? 他们说有
Db.SetMaxOpenConns(200) Db.SetMaxIdleConns(100) Db.Ping()
线程池。所有代码中都说不需要close,但是那是有条件的。
我们查看官方的解释
// It is rare to Close a DB, as the DB handle is meant to be
// long-lived and shared between many goroutines.
但在实际使用中,都说了是定时任务自然是go func的,然后使用一个公共的Db,还有一个注意的问题,虽然连接放进连接池,但是服务器依然会单方面断开一个的连接。
关键是而且使用Db.Ping()依然不能解决这个问题,原因没细查。
现在知道了原因,解决起来就容易多了,结尾一定加
Db.Close()
什么rows.close,stmt.close反而不重要,后面测试发现可有可无,凌晨1点了,收工。
今早上起来,一切OK,运行了1个晚上
以上是关于Golang mysql 上线的一个坑 Db.close重要性的主要内容,如果未能解决你的问题,请参考以下文章