由數據庫鏈接池想到的----處理他人未釋放的資源

發現問題

    前些日子維護編寫的通信服務器時遇到了這麼一個問題：在通信服務器裏有一個數據庫鏈接池，爲他人提供數據庫鏈接服務，結果發如今使用過程當中鏈接有時會耗盡，這個問題經過調試跟蹤發現，有「客戶」在使用數據庫鏈接時，老是不釋放鏈接（已提供了釋放鏈接的方法）。其實問題很好解決，找出未釋放鏈接的那個「客戶」而後按照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，快速解決。