最近在使用go语言操作数据库的时候遇到个隐藏的问题,这种问题很难定位,最后经过多方测试、尝试、猜测最后才确认问题,问题是这样的:

然后最后测试测出来不知道什么原因,经过一段时间的测试,服务卡死了,所有的访问都无法正常访问;最开始是找路由框架的问题,找了半天也没找到问题,后面又猜测是非法字符操作的问题,最后经过各种测试发现是功能函数里面有个系统函数没用对,导致线程池到达上限,所有访问卡死。具体的导致原因和解决方法如下所示:

        我们在线程池设置的地方是这样设置的:

const (
	dbMaxLiftTime  = 2 * time.Hour
	dbMaxIdleConns = 30
	dbMaxOpenConns = 100
)

G_dbpap, err := sql.Open("mysql", mysqlurl)
if err != nil {
	golog.Error(err)
	return err
}
G_dbpap.SetMaxIdleConns(dbMaxIdleConns)   //连接池的空闲数大小
G_dbpap.SetMaxOpenConns(dbMaxOpenConns)   //设置最大打开连接数
G_dbpap.SetConnMaxLifetime(dbMaxLiftTime) //设置连接的最大生存时间

上面的代码中,我们打开了一个G_dbpap的全局操作mysql数据库的变量,然后我们设置了线程池,最大打开访问连接数为100,这个设置是导致我出现问题的关键,另外两个根据字面上的意思也能理解,记住这个100

然后我代码中有个API接口函数是这样写的:

sql_cmd := `DELETE FROM TABLEDATA`
_,err := G_dbpap.Query(sql_cmd)
if err != nil{
    return err
}

注意这个G_dbpap.Query,我看了他函数源码里面他的第一个返回值是Rows指针,下面附上了源代码

func (db *DB) Query(query string, args ...any) (*Rows, error) {
	return db.QueryContext(context.Background(), query, args...)
}

我之前也看了很多资料知道这个rows返回值用完必须要手动close,但是就是因为这个地方我图方便,因为是删除语句,我不需要处理返回值就用了下划线略过返回值,其实是有问题的,这个rows不close的话,这一次的请求线程就会一直占用,不会释放,所以接口测试超过100次,这个线程占用就会达到100次,然后上面设置的线程池最大连接数就是100次,所以就导致100次的接口测试后,所有使用G_dbpap句柄操作数据库的访问请求都会卡死。因为设置了最大线程池大小,达到最大后,访问请求就会等到之前的线程释放掉才会响应。

当时的心情真的很激动,折磨好久的问题终于定位到原因,然后怎么解决呢,两种方法:

1、像上面那种数据库操作请求,因为不需要返回值,所有只需将Query换成Exec执行数据库即可,如下所示

sql_cmd := `DELETE FROM TABLEDATA`
_,err := G_dbpap.Exec(sql_cmd)
if err != nil{
    return err
}

2、如果不像上面的那种,需要处理返回值的数据库操作,如select的,需要再使用完rows后close掉,如下所示

sql_cmd := `SELECT * FROM TABLEDATA`
rows,err := G_dbpap.Query(sql_cmd)
if err != nil{
    return err
}

for rows.Next() {
    //获取rows的返回值操作

}

rows.Close()

这样用完操作然后Close掉才不会出现问题。

备注:从上面的情况来看,其实出现原因也是我自己的问题,删除操作数据库的操作函数不该用Query函数,但是其实我也非常感谢我用错,不用错,我就不会深刻理解用了Query没有Close会导致什么严重的后果。还有就是有人或许会说,如果数据库线程池操作那个不设置那100的限制,应该也不会出现这个问题,其实大家再仔细想想,如果前面没有设置那100的限制(好像默认是无上限),那么最后出现问题可能是灾难性的,设想没有释放的线程越来越多,最后导致系统崩了,到那时可能定位问题更是艰难无比了。

以上就是我此次遇到的问题和解决方法,记录于此,希望对后面的朋友有所帮助。