由数据库链接池想到的----处理他人未释放的资源

发现问题

    前些日子维护编写的通信服务器时遇到了这么一个问题：在通信服务器里有一个数据库链接池，为他人提供数据库链接服务，结果发如今使用过程当中链接有时会耗尽，这个问题经过调试跟踪发现，有“客户”在使用数据库链接时，老是不释放链接（已提供了释放链接的方法）。其实问题很好解决，找出未释放链接的那个“客户”而后按照GetConnection，ReleaseConnection的方式来正确调用就能够了。

解决问题？

    可是找出那个“客户”很容易吗？看看咱们的整个系统吧，多达五个子系统插件在使用这个服务，并且其中的数据库链接调用不少，这样找可费了大劲了。在通过大量的代码审核后，终于找出未释放链接的那个客户，解决了这个问题。

思考之下，做为一个关键的公共服务是否是能够作相应优化来应对这种“客户”犯下的错误。

采用RAII机制，把释放连接的那个方法也写入析构函数中

    举例（采用伪码加不标准类写法方式，主要是说明思路；参考effective c++章节2 构造/析构）

class ConnectionPool
{
public:

  ...

  ~ConnectionPool( void);
  {
     if (!bRelease)
    {
      Release链接();
    }
  }

   void  ReleaseConnection()
  {
    Release链接();
    bRelease = true;
  }
private:

  bool  bRelease;     (初始化为 false)
};

这样”客户“若是是采用栈或智能指针实例化的对象来使用服务，即便忘记释放链接均可以利用RAII机制安全释放；

可是若是”客户“直接用new出的对象使用服务忘记释放链接呢，又回到了最早遇到的问题上，在一大推调用里找到底是谁未释放链接。继续解决：

    既然如今咱们的困扰集中在找违规”客户“的麻烦上，想一想图书馆借书，谁借去了必须把他的名字登记下来，谁谁谁借走了这本书，到时候即便他不还，咱也有办法找到他让他给咱还回来。因而咱们能够再改造一下这个服务，在每一个”客户“得到链接时都传入他的标识而后把这个链接和标识捆绑起来。这样，哪一个”客户“未释放链接一目了然了吧，立马找到他让他改正。OK，快速解决。