Go语言中mgo驱动连接泄漏问题的根源与解决方案-Golang

mgo驱动默认连接池过大（4096）导致高并发下连接数失控，即使正确调用`session.close()`仍持续占用tcp连接；根本解法是显式限制`maxpoolsize`并规范会话生命周期管理。

在基于 Go + mgo + MongoDB 构建 REST API 时，一个常见但隐蔽的性能陷阱是连接泄漏（connection leak）——表现为进程持续累积 ESTABLISHED 状态的 TCP 连接，最终耗尽系统文件描述符（如达到 ulimit 1024 上限），导致服务不可用。

问题本质并非 session.Copy() 或 session.Close() 调用遗漏，而是 mgo 的底层连接池机制设计：mgo.Dial() 默认启用连接池，且 maxPoolSize 默认值高达 4096（见 mgo source）。当并发请求频繁 Copy() 会话时，mgo 会按需创建新连接填充池；而 session.Close() 仅将连接归还至池中，而非真正关闭底层 socket——只要池未满、连接空闲，它们就长期保持 ESTABLISHED 状态。

✅ 正确做法：主动约束连接池规模，并确保会话及时释放：

// 初始化全局 master session（单例）
info := &mgo.DialInfo{
    Addrs:    []string{"localhost:27017"},
    Timeout:  10 * time.Second,
    PoolLimit: 16, // ? 关键！显式设为合理值（如 8–32，依QPS和DB负载调整）
}
session, err := mgo.DialWithInfo(info)
if err != nil {
    log.Fatal("Failed to dial MongoDB:", err)
}
defer session.Close() // master session 通常不 Close，供 Copy 使用

// 每个 HTTP 请求中：
func handleRequest(w http.ResponseWriter, r *http.Request) {
    // Copy 新会话（轻量，复用底层连接）
    s := session.Copy()
    defer s.Close() // ✅ 必须 defer，确保每次请求结束归还连接

    // 执行数据库操作
    c := s.DB("mydb").C("users")
    var user User
    err := c.FindId("abc123").One(&user)
    if err != nil {
        http.Error(w, err.Error(), http.StatusInternalServerError)
        return
    }
    // ... 响应逻辑
}

⚠️ 注意事项：