本文详解 mgo 驱动中因未合理配置连接池导致的连接泄漏问题，指出默认 `maxpoolsize=4096` 是并发请求下连接数失控的主因，并提供安全、高效的 session 复用与释放实践。
在使用 mgo（一个已归档但仍在部分遗留项目中使用的 Go MongoDB 驱动）构建高并发 REST API 时，开发者常采用“单 master session + 每请求 Copy()”的模式，意图复用连接并避免重复拨号。然而，这种做法若未配合正确的连接池配置，极易引发隐蔽而严重的连接泄漏——表现为 lsof -i :27017 显示大量处于 ESTABLISHED 状态的 TCP 连接持续累积，最终耗尽系统文件描述符（如达到 ulimit 1024 上限），导致服务不可用。
根本原因在于：mgo.Dial() 默认启用连接池，且 maxPoolSize 默认值为 4096。每次调用 session.Copy() 并非简单克隆轻量级句柄，而是可能从池中获取（或新建）底层网络连接；而 session.Close() 仅将连接归还至池中，而非真正关闭 TCP 连接。当并发请求数波动较大或存在长尾请求时，连接池会持续保有大量空闲连接以备后续复用——这本是性能优化设计，但在未限制池大小、又缺乏主动回收机制的场景下，便演变为资源泄漏。
✅ 正确解决方案如下：
-
显式限制连接池大小
在初始化 master session 时，通过 mgo.DialWithInfo 或 mgo.DialWithTimeout 配置 MaxPoolSize（注意：mgo 中对应字段名为 PoolLimit）：
info := &mgo.DialInfo{
Addrs: []string{"localhost:27017"},
Timeout: 10 * time.Second,
PoolLimit: 32, // 关键：将默认 4096 降至合理值（如 16–64，依 QPS 和集群节点数调整）
}
session, err := mgo.DialWithInfo(info)
if err != nil {
log.Fatal("Failed to dial MongoDB:", err)
}
defer session.Close() // master session 通常生命周期与应用一致，只需在退出时关闭-
严格遵循 Copy/Close 模式（但理解其语义）
每个 HTTP 请求中仍应 Copy() 并 Close()，但需确保 Close() 被确定执行（推荐用 defer）：
func handleUserRequest(w http.ResponseWriter, r *http.Request) {
// Copy 会创建新 session，共享底层连接池
s := session.Copy()
defer s.Close() // 归还连接至池，非销毁
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
}
json.NewEncoder(w).Encode(user)
}⚠️ 注意事项：
- 不要对 Copy() 后的 session 再次调用 Copy() —— 层叠复制会加剧连接占用；
- 避免在 goroutine 中忘记 defer s.Close()，否则连接永不归还；
- mgo 已停止维护（官方推荐迁移到 mongo-go-driver），新项目应直接使用官方驱动，其连接池行为更透明（Client 自带可配置的 MaxPoolSize 和 MinPoolSize）；
- 若必须使用 mgo，建议同时设置 Timeout 和 SocketTimeout 防止慢查询长期占用连接。
总结：mgo 的连接泄漏并非 Copy()/Close() 模式本身错误，而是开发者忽略了其背后连接池的默认激进配置。通过显式约束 PoolLimit，辅以严谨的 session 生命周期管理，即可彻底解决 ESTABLISHED 连接无限增长的问题，无需依赖提升系统 ulimit 这一治标不治本的方案。
