Go-Gin服务器端口耗尽排查：TIME_WAIT连接异常分析

问题背景 #

运行Go-Gin Web服务器时出现无响应情况，因未设置超时逻辑，导致请求一直处于等待状态。在Windows机器上通过netstat排查，发现有大量3306端口处于TIME_WAIT状态（约80个），怀疑是数据库连接未正确关闭导致端口耗尽。以下是使用database/sql库的代码实现，想确认该连接使用方式是否正确，是否需要手动关闭连接。

代码实现 #

main.go

//main.go
func createDBPool(connectionString string, maxConnections int) (*sql.DB, error) {
    db, err := sql.Open("mysql", connectionString)
    if err != nil {
        return nil, err
    }
    db.SetMaxOpenConns(maxConnections) // Set the maximum number of open connections
    return db, nil
}

func main() {
// Initialize database connection => field GlobalDBPool *sql.DB
//config.GlobalDbCon => "dbusername:dbuserpassword@tcp(dbip:dbport)/databasename
config.GlobalDBPool, err = createDBPool(config.GlobalDbCon, 30)
    if err != nil {
        sC.Logger.Error("Couldn't initialize database connection to global database.", "Error", err)
        os.Exit(1)
    }
    defer config.GlobalDBPool.Close()
//..Some other initialization codes are here
//This is how I distribute my config which contains database connection and other stuff
RSSServices := sC.RSSServices{ServerConfig: config}
userService := sC.UserService{ServerConfig: config}
subService := sC.SubscriptionService{ServerConfig: config}

//Again some code here and then routes come in place
r.GET("/some-endpoint", userService.SomeEndPointGET())
r.POST("/another-endpoint", subService.AnotherEndpointPOST())
err = r.Run(":80")
if err != nil {
        sC.Logger.Error("Server couldn't be initialized.", "Error", err)
        os.Exit(3)
    }
}

SubscriptionService.go

//SubscriptionService.go
type UserService struct {
    ServerConfig *models.Config
}

func (us *UserService) AnotherEndpointPOST() func(c *gin.Context) {
    sqlStatement := `PLACEHOLDER-SQL-STATEMENT-FOR-PRIVACY`

    err := us.ServerConfig.GlobalDBPool.QueryRow(sqlStatement, "param1").Scan(&var1, &var2, &var3)
    if err != nil {
        c.JSON(400, gin.H{"code": "some-error-code-string"})
            return
    }

    outputVar := fmt.Sprintf("\\\\%s\\%s\\%s", var1, var2, var3)

    c.JSON(200, gin.H{"code": "outputVar"})
}

问题解答 #

1. 当前连接使用方式的正确性 #

你的连接池初始化逻辑整体是正确的：

• sql.Open不会直接建立数据库连接，而是创建一个连接池管理对象，实际连接会在执行SQL操作时按需创建
• 设置SetMaxOpenConns(30)控制了最大同时打开的连接数，这一步是合理的

但存在几个关键疏漏：

• 缺少闲置连接管理配置：仅限制最大打开连接数，未配置闲置连接的数量和超时时间，导致闲置连接长期占用端口，最终进入TIME_WAIT状态
• 未设置请求超时：请求无超时控制，会导致大量请求堆积，进一步消耗连接池资源，加剧服务无响应问题
• QueryRow的极端场景风险：虽然QueryRow会在Scan后自动关闭结果集，但如果Scan前发生错误，极少数场景下可能存在连接未正确归还到池中的情况

2. 是否需要手动关闭连接？ #

不需要手动关闭单个数据库连接，database/sql的连接池会自动负责连接的复用、闲置销毁等管理工作。但要注意：

• 如果使用Query获取Rows结果集，必须手动调用Rows.Close()关闭，否则会导致连接泄漏；你当前用的QueryRow不存在这个问题，它的结果集会自动处理
• 必须确保连接池配置合理，避免闲置连接长期占用系统资源

3. 解决TIME_WAIT与服务无响应的具体方案 #

优化连接池配置

添加闲置连接相关配置，让连接池自动清理闲置连接，避免端口被长期占用：

func createDBPool(connectionString string, maxConnections int) (*sql.DB, error) {
    db, err := sql.Open("mysql", connectionString)
    if err != nil {
        return nil, err
    }
    db.SetMaxOpenConns(maxConnections)
    db.SetMaxIdleConns(20) // 最大闲置连接数，建议小于等于最大打开连接数
    db.SetConnMaxIdleTime(5 * time.Minute) // 连接闲置超过5分钟则自动销毁
    db.SetConnMaxLifetime(30 * time.Minute) // 连接最长生命周期30分钟，避免长期占用端口
    return db, nil
}

添加请求超时逻辑

给Gin服务添加全局超时中间件，避免请求无限等待：

// 全局超时中间件，设置5秒超时
func timeoutMiddleware() gin.HandlerFunc {
    return func(c *gin.Context) {
        ctx, cancel := context.WithTimeout(c.Request.Context(), 5*time.Second)
        defer cancel()
        c.Request = c.Request.WithContext(ctx)
        c.Next()
    }
}

// 在路由注册前使用中间件
r.Use(timeoutMiddleware())

完善错误处理

确保所有数据库操作的错误都被正确捕获和处理，避免因未处理的错误导致连接无法正常归还到连接池。

关于TIME_WAIT的补充说明

TIME_WAIT是TCP连接关闭后的正常状态，Windows系统默认会保留约4分钟。如果数量过多，除了连接池配置问题，也可能是短时间内有大量连接建立和关闭，通过上述连接池优化可以有效缓解这一问题。

内容的提问来源于stack exchange，提问作者Shino Lex