Go 中使用 mgo 驱动时的连接泄漏问题及正确会话管理方案-Golang

mgo 默认连接池过大（4096）导致高并发下连接数激增、资源耗尽；通过合理配置 `maxpoolsize` 并规范 `copy()`/`close()` 使用方式，可彻底解决连接泄漏问题。

在 Go 应用中使用 mgo 作为 MongoDB 官方推荐的第三方驱动时，一个常见却隐蔽的陷阱是：看似正确的 session.Copy() + session.Close() 模式，仍可能引发连接泄漏。根本原因并非代码未调用 Close()，而是 mgo.Session 的设计机制与连接池行为未被充分理解。

mgo.Dial() 创建的 master session 内部维护一个全局连接池（默认 MaxPoolSize = 4096），每次调用 session.Copy() 并非新建物理连接，而是从池中获取或创建一个轻量级会话副本（共享底层 socket 连接）。而 session.Close() 的作用是将该副本归还给连接池，并不立即关闭底层 TCP 连接——连接会持续复用，直到连接池自身触发清理（如空闲超时）或程序退出。

因此，在高并发场景下，若未显式限制连接池大小，大量并发请求会快速占满默认 4096 连接上限，同时因连接复用和内核 TIME_WAIT 状态累积，lsof 将持续显示大量 ESTABLISHED 状态的 MongoDB 连接，最终触发系统文件描述符限制（如 ulimit -n 1024），导致服务不可用。

✅ 正确做法如下：

1. 显式配置连接池参数（关键！）
   在 mgo.DialWithInfo() 或 mgo.Dial() 中设置合理的 MaxPoolSize 和 Timeout：

info := &mgo.DialInfo{
    Addrs:    []string{"localhost:27017"},
    Timeout:  10 * time.Second,
    PoolLimit: 100, // 替代已废弃的 MaxPoolSize；mgo v2+ 推荐用 PoolLimit
}
session, err := mgo.DialWithInfo(info)
if err != nil {
    log.Fatal("Failed to dial MongoDB:", err)
}
defer session.Close() // master session 只需在应用生命周期结束时关闭一次

⚠️ 注意：mgo 原始版本中 MaxPoolSize 字段已被弃用，应使用 PoolLimit（v2+ 分支）或确保使用兼容版本并明确设置。

2. 每个请求中安全使用 Copy/Close 模式