mgo 默认连接池过大（maxpoolsize=4096）导致并发请求中 session.copy() 后未及时回收连接，引发连接数持续增长直至耗尽系统文件描述符。根本解法是显式限制连接池大小并规范 session 生命周期管理。
在基于 mgo 的 Go Web 服务中，常见的“连接泄漏”现象往往并非真正意义上的泄漏（如 Session 忘记 Close），而是由 mgo 的连接池机制与高并发场景不匹配所致。mgo.Dial() 默认启用一个极大连接池（maxPoolSize=4096），而每次调用 session.Copy() 并非创建全新物理连接，而是从池中获取或新建连接；当大量请求高频 Copy → Use → Close 时，mgo 会倾向于保留在活跃期后仍处于空闲状态的连接以备复用——但若应用 QPS 波动大、连接复用率低，这些“闲置连接”会长时间滞留，最终累积突破系统级限制（如 ulimit -n 默认 1024），表现为 lsof | grep :27017 显示大量 ESTABLISHED 连接无法释放。
正确做法是主动约束连接池行为：
-
显式设置合理的连接池参数（推荐在初始化 master session 时配置）：
info := &mgo.DialInfo{ Addrs: []string{"localhost:27017"}, Timeout: 10 * time.Second, PoolLimit: 32, // 关键！替代默认的 4096，按实际并发量调整（建议 16–64） } session, err := mgo.DialWithInfo(info) if err != nil { log.Fatal("Failed to dial MongoDB:", err) } defer session.Close() // master session 全局复用，仅在程序退出时关闭 -
确保每个请求的 session.Copy() 后严格调用 Close()（即使发生 panic，也应使用 defer）：
func handleUserRequest(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(r.URL.Query().Get("id")).One(&user) if err != nil { http.Error(w, err.Error(), http.StatusNotFound) return } json.NewEncoder(w).Encode(user) }
⚠️ 注意事项：
- session.Copy() 返回的是可安全并发使用的独立会话副本，其 Close() 仅归还连接至池中（非立即断开 TCP），因此必须调用，否则该副本占用的连接将永久保留在池中；
- 不要对 Copy() 后的 session 调用 Clone() 或再次 Copy()，这会进一步放大连接消耗；
- PoolLimit 值需结合应用最大并发请求数、平均响应时间及 MongoDB 服务器资源综合评估，通常设为 预期峰值 QPS × 平均处理耗时（秒）× 1.5 是较稳妥的起点；
- 若升级到现代项目，强烈建议迁移到官方驱动 go.mongodb.org/mongo-driver/mongo，其连接池设计更透明、可控性更强，且已不再维护 mgo。
通过精简连接池规模 + 严谨的生命周期管理，可彻底规避此类“伪泄漏”，无需依赖提升系统 ulimit——后者只是掩盖问题，而非解决根本。
