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），导致服务不可用。
✅ 正确做法如下：
-
显式配置连接池参数（关键！）
在 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+ 分支）或确保使用兼容版本并明确设置。
-
每个请求中安全使用 Copy/Close 模式
func handleRequest(w http.ResponseWriter, r *http.Request) { // 从 master session 复制新会话（线程安全） s := session.Copy() defer s.Close() // 必须确保执行，建议用 defer // 执行数据库操作 c := s.DB("mydb").C("users") var user User err := c.FindId("123").One(&user) if err != nil { http.Error(w, err.Error(), http.StatusInternalServerError) return } // ...响应逻辑 } -
避免常见误用
- ❌ 不要在循环中频繁 Copy() 而忘记 Close()；
- ❌ 不要将 session.Copy() 结果跨 goroutine 共享（mgo.Session 非并发安全）；
- ✅ 始终用 defer s.Close() 保证释放，或在 error 分支中显式关闭。
? 补充建议：
- 升级至更现代的驱动（如官方 mongo-go-driver）以获得更好的上下文控制、连接池监控和 context-aware 操作；
- 在生产环境启用 MongoDB 连接池指标（如 db.currentOp() 或 Prometheus exporter）进行实时观测；
- 对于长周期服务，定期调用 session.Refresh() 可主动清理失效连接（谨慎使用）。
综上，连接泄漏的本质是“池配置失控”而非“代码漏关”，通过精准调控 PoolLimit、严格遵循 Copy/Close 生命周期，并辅以可观测性建设，即可稳定支撑高并发 MongoDB 访问。
