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

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 连接无法释放。

正确做法是主动约束连接池行为：

1. 显式设置合理的连接池参数（推荐在初始化 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 全局复用，仅在程序退出时关闭

2. 确保每个请求的 session.Copy() 后严格调用 Close()（即使发生 panic，也应使用 defer）：