labix.org/mgo包连接池泄漏问题

问题复现

labix.org/mgo是golang常用的mongo driver，笔者的项目中重度依赖，不过项目年久失修，已经不维护。所以结论是用官方包。

最近在使用中，我发现了一个问题，服务对mongo的长连接一直缓慢增长，形似mongo连接泄漏。

查看了下mgo源码，发现mgo内部维护了连接池，而默认连接池大小socketsPerServer是4096，连接池的连接新增是惰性的，不会在初始化时建立所有连接，而是在有新请求且当前无剩余可用连接时，建立新连接，使用结束后就放入连接池中供以后使用，期待连接池所维护的最多连接数是4096个。连接池大小限制代码如下，请注意mongoServer.unusedSockets(空闲的连接)和mongoServer.liveSockets(生效过的连接)的含义：

// 连接池大小：
var socketsPerServer = 4096
// 连接池大小设置：
func SetPoolLimitPerServer(limit int) {
    socketsPerServer = limit
}
// 连接池管理结构
type mongoServer struct {
  ...
    unusedSockets []*mongoSocket // 空闲的连接
    liveSockets   []*mongoSocket // 生效过的连接，这里记录所有建立的连接，当连接使用结束会复制一份进unusedSockets，但是不会从liveSockets删除
    ... 
}

如上代码，socketsPerServer是可以通过方法SetPoolLimitPerServer改写的，于是我在下面的代码中，OpenDB里调用SetPoolLimitPerServer将连接池上限改成了20，但是通过并发测试发现，连接池的限制并不准确，实际运行下来最后建立的连接依然会超过20。

主要代码如下，我插入200条数据，为了防止数据库压力，通过笔者写的goworker以稳定的并发90写入，其他会进行排队。

最后通过mgo提供的GetStats()接口(或者在服务端通过db.serverStatus()也能看到连接数量connections.current)，能够看到池里的连接为SocketsAlive 59个，远远超过了20，这是为什么呢？

// 测试mgo连接泄露问题
func main() {
    db := OpenDB(xl, fmgo.Config{Config: mgo3.Config{Host: "127.0.0.1:27017", DB: "test_black", Coll: "connectiontest", Mode: "strong", SyncTimeoutInS: 5}})
    defer db.Close()
    mgo.SetStats(true)
    // 初始化 goworker，并发不超过90
    worker := goworker.New(goworker.WorkerConfig{
        ConcurrencyNum: 90,
    })
    // 总共插入200条数据
    for i := 0; i < 200; i++ {
        var j = i
        worker.Add(func() {
            db.Insert(mgoDBInfo{Name: strconv.Itoa(j) + "_name"})
        })
    }
    worker.IsDone()
    stats := mgo.GetStats()
    fmt.Printf("%+v", stats)
 // 输出：{Clusters:0 MasterConns:59 SlaveConns:0 SentOps:459 ReceivedOps:259 ReceivedDocs:259 SocketsAlive:59 SocketsInUse:0 SocketRefs:0}
    time.Sleep(100 * time.Second)
}

问题定位

问题出现在当有新的请求时，mgo 的连接池管理逻辑，当需要新建一个连接时，并发情况下会有问题，精简代码如下

func (server *mongoServer) AcquireSocket(limit int, timeout time.Duration) (socket *mongoSocket, abended bool, err error) {
     for {
      server.Lock()
    n := len(server.unusedSockets)
    // 判断当前正在使用的连接，是否到连接池上限，如果到了上限就退出等待
        if len(server.liveSockets)-n >= limit {
            server.Unlock()
            return nil, false, errSocketLimit
        }
   
    if n > 0{
      // 拿一个可用的 unusedSockets
    } else {
        server.Unlock()
      // bug here
      // 这里 unlock->connect->lock，是因为如果不unlock，新建连接时间太长，导致阻塞所有并发AcquireSocket的请求
      // 这样做在并发时就会有一个bug，如果连接池大小是20，而同时并发的进入30个AcquireSocket，所有的请求都会走到下面的Connect()，并正常的拿到连接，加入liveSockets，返回成功，导致连接池里有30个连接
      socket, err = server.Connect()
      if err == nil {
                server.Lock()
                if server.closed {
          server.UnLock()
          return nil, abended, errServerClosed
        }
                server.liveSockets = append(server.liveSockets, socket)
                server.Unlock()
      }
    }
    return
  }
  panic("unreachable")
}

 

问题解决

从代码逻辑看，mgo对连接池的理解和一般的理解不同：

• 一般而言，连接池大小，就代表有多少个长连接维持在池里，也就是 正在使用的连接+未使用的连接 <= 连接池大小

• mgo的连接池管理里，从上面的方法里用if len(server.liveSockets)-n >= limit判断连接池是否已经满可以看出， mgo认为当前正在用的连接数 <= 连接池大小 就可以了，没有使用的连接不应该受连接池大小控制。（注意，第一部分已经强调，liveSockets是历史建立的所有连接数量，不是正在使用socket的数量）

很明显，mgo的定义是不对的，这样会导致真实建立的连接(正在使用的+池里未使用的)>连接池限制。

针对这一点，我们在拿到新连接并加锁后，判断一下当前建立的连接是否已经超限，超限就关闭当前连接并等待，解决这个问题。

这个解决方案，会放弃新建的连接，对资源是有一定的浪费的，因为毕竟新建连接是耗时的。但是一旦建立后，就导致了连接泄漏，所以是不得已而为之。

func (server *mongoServer) AcquireSocket(limit int, timeout time.Duration) (socket *mongoSocket, abended bool, err error) {
     socket, err = server.Connect()
      if err == nil {
                server.Lock()
                if server.closed {
          server.UnLock()
          return nil, abended, errServerClosed
        }
        // fix bug start
        // +1 是要算上当前新建的这个连接
        if limit > 0 && len(server.liveSockets)-n+1 > limit {
                    server.Unlock()
                    socket.Release()
                    socket.Close()
                    return nil, false, errSocketLimit
                }
        // fix bug end
                server.liveSockets = append(server.liveSockets, socket)
                server.Unlock()
      }
}