一、背景

xx服务内存持续上涨。内存占用10%以内，在QPS无明显变化的前提下，内存占用50%左右。

dump了一下heap内存，发现主要是 InitUserCacheRefresh 任务代码占用

正常来说，dao层查完数据库之后，对象应该会释放，最终被gc回收，但这里 InitUserCacheRefresh 代码里的对象长期持有引用，占用内存达400M+，感觉发生了内存泄露，所以排查下。

核心代码逻辑

该代码主要用于权限服务刷新用户权限缓存，在服务启动时会初始化50个协程通过 chan 等待用户权限刷新任务，刷新任务由 RefreshAllPermission/RefreshUserPermission 接口触发

// 使用伪码减少逻辑理解成本
func InitUserCacheRefresh() {ctx := context.Background()for i := 0; i < 50; i++ {go func() {// ...updateUserCache(ctx)}()}
}func updateUserCache(ctx context.Context) {db := client.GetDB(ctx)for {task := <-qpsChana := dao.SelectXX(ctx, db, xxx)// TODOb := dao.SelectXXX(ctx, db, xxx)// TODOredis.GetClient().Set(xxx, xxx)}
}

二、排查

一开始怀疑是 updateUserCache 方法内 db 变量在查询完结果后，有可能还持有结果引用，而 for 循环导致 db 变量一直无法回收，引用无法释放，导致内存泄露。

尝试本地复现：按照线上的逻辑写了个类似的代码尝试复现，但没有复现出来

给gorm提交oncall，咨询了下相关用法会不会导致数据引用无法释放，但也没结论

于是尝试在xx服务测试环境复现，部署服务后尝试调用几次 RefreshAllPermission 后dump内存，发现和线上基本一致，也持有 gorm 的很多对象（事情已经成功了百分之八十）。直接找到占用内存最大的对象 PreparedStmtDB，查看查询走到的逻辑（图1），prepare方法会优先在db.Stmts这个map中看存不存在对应query（SQL），如果存在就直接返回，如果不存在会创建一个新的放到这个map中。

在触发了几次 RefreshAllPermission 后，直接在图1断点处打上断点，发现db.Stmts有大量的SQL缓存

查看 PreparedStmtDB.Stmts 字段是一个 map，缓存SQL和对应的Stmt

type PreparedStmtDB struct {Stmts       map[string]StmtPreparedSQL []stringMux         *sync.RWMutexConnPool
}

看图2 感觉 PreparedStmtDB.Stmts 对象无限增长，没有清理策略，看 prepare_stmt.go 代码
只有在 close 的时候，以及err != nil的时候会清理

func (db *PreparedStmtDB) Close() {db.Mux.Lock()defer db.Mux.Unlock()for _, query := range db.PreparedSQL {if stmt, ok := db.Stmts[query]; ok {delete(db.Stmts, query)go stmt.Close()}}
}func (db *PreparedStmtDB) QueryContext(ctx context.Context, query string, args ...interface{}) (rows *sql.Rows, err error) {stmt, err := db.prepare(ctx, db.ConnPool, false, query)if err == nil {rows, err = stmt.QueryContext(ctx, args...)if err != nil {db.Mux.Lock()defer db.Mux.Unlock()go stmt.Close()delete(db.Stmts, query)}}return rows, err
}

所以感觉已经真相大白，只有在DB配置PrepareStmt为true情况会缓存SQL，尝试把DB的这个置为false，再次尝试，对应对象已经没了，调用多次后内存没有明显变化。详细的解决方案可以看下文结论中的解决方案

三、结论

根因

1. xx服务DB配置开启了 PrepareStmt，也就是 PrepareStmt 配置为 true，gorm会缓存查询的SQL
2. dao层使用的SQL没有使用预占符，而是通过 fmt.Sprintf 拼接查询，SQL中某个id或其他查询条件不一样就会导致gorm生成的SQL也不一样，gorm会将这些SQL都缓存下来，且没有容量上线和清理机制（使用map缓存），导致占用了大量内存。

解决方案

方式1

gorm 修复，缓存SQL的map改成LRU，设置容量，达到容量值时淘汰缓存的SQL。

方式2

xx服务更改DB配置，关闭PrepareStmt模式，将 PrepareStmt 配置改为 false。但PrepareStmt模式可以大幅提高SQL查询性能，建议在单独sql处使用。

方式3

xx服务的查询，动态SQL改成预占符

// 建议
Where(fmt.Sprintf("%v.role_status = ?", roleEntityTableName), 1)// 不建议
Where(fmt.Sprintf("%v.role_status = %d", roleEntityTableName, 1))

部署服务，再看断点处数据，缓存的SQL只有预占符的SQL，没有带id参数的，只有五条，不会占用大量内存

倾向选择方式3，也建议SQL使用预占符，而不是通过 fmt.Sprintf 拼接。另外也给gorm提交，反馈后续会修复，将缓存SQL的map改为LRU缓存