年底了，也差不多兩個多月沒有更新過這個blog了，是沒什么內容好寫，也是因為自己懶了。這一晃，一年過去了，對于已過而立之年的人來說，日子過得總是那么快。回首看看自己這一年，沒什么收獲，工資沒變、本事沒漲，虛度了這365天，多多少少有些失落。人生就是一張單程車票，過去了也就過去了，好好珍惜接下來的每一天吧。

        好了，言歸正傳，說說這個主題的內容吧。客戶碰到這么個問題，他把他們的連接池的初始、最大連接數(initial/max capacity)均設定為某一值，但運行一段時間后，他時常發現max capacity不起作用了，也就是說，從監控來看，當前活動連接數(current active connections)經常大于max capacity。開始懷疑這可能是個console的bug，后來跟客戶確認netstat的結果，結果是網絡連接數和active connections一致。好了，這說明跟console沒有關系，連接池的問題，為什么連接池的max capacity不起作用呢？之前沒有聽說過類似的bug啊，要了客戶的jdbc config，發現連接池配置中有如下信息：

        
        懷疑和pinned-to-thread的設置有關系，做了個測試，嘗試重現這個問題，不出所料，問題真的重現出來了。至于pinned-to-thread有什么左右，問什么它會導致max-capacity不起作用，我們后面再說。先看看我們問題的重現過程。

        我也配置了一個connection pool，初始、最大連接數均設定成5，連接池啟動后，連接數監控如下：


         寫一個jsp, jsp中從datasource獲取一個連接，然后關閉該連接，通過apache的ab執行一個壓力測試，60個請求(每次并發15個), 然后監控連接使用情況如下：




       從netstat的結果來看，WLS到Oracle的連接數的確也是15個，如下：


        好了，現在我們再來看看pinned-to-thread是干什么的，為什么它會導致max capacity不起作用。pinned-to-thread在WLS中是用于提高connection reserver性能的選項，當我們選中這個選項后，WLS中執行線程在處理應用請求的使用，如果應用通過datasource.getConnection()申請連接，WLS首先從當前線程的thread local變量中檢查時候有連接已經綁定，如果有，使用這個連接，如果沒用，則從連接池中申請連接。thread local中storage[7]存儲的就是連接信息，從debug信息來看，conns為空，即當前線程還沒有獲得綁定連接，所以連接最終會從connection pool中獲取。



        連接申請成功，客戶使用完連接后，客戶端調用connection.close()來釋放這個連接，即我們通常意義上的還池。對于普通的connection pool，WLS的確是這么做的，連接被清理，然后還池并等待其他線程申請，但對于pinned-to-thread的連接池來說，雖然你調用connection.close()，實際連接并不會還池，為了性能嘛，還池的話，還得去重新申請，那就不存在性能調優的說法了。WLS不讓這個連接還池，那不就泄露了嗎？不會，WLS會將這個不還池的連接綁定到我們前面所說的當前線程的thread local中，這樣下次這個線程處理其他請求需要使用連接的時候，連接就不用申請了，直接拿這個綁定連接即可。下面我們再來看看連接colse()，



        看到了吧，連接關閉的時候，WLS只是把連接放到ConnectionPool$ConnectionStore中去了。

        下面我們再看看為什么pinned-to-thread會導致max capacity不起作用。pinned-to-thread被選中后，如果連接池中有5個連接，這五個連接分別被5個執行線程取走并綁定給自己的話，如果此時某一個應用請求被分配到這5個線程以外的線程，如果max-capacity生效，那么這個線程將永遠不能獲取到連接(除非拿到連接的線程被destory掉，我們最終用戶可干不了這事兒，這事得WLS的work manager自己處理)，這對于用戶而言是不可以接受的。因為我已有的5個連接可能根本就沒有被使用(連接被綁定到執行線程后，對于連接池而言它就是active的，對于其他的用戶而言是unavailable的)，為什么其他線程拿不到連接，導致請求無法處理，所以WLS為了防止這種情況出現，在連接池被激活的時候，解除了max-capacity的限制，如下：


        好了，pinned-to-thread是干什么的你該清楚了吧，至于要不要選中它，需要你自己去把握。它是把雙刃劍，好壞需要你去權衡。好壞大概如下：
        1：好處是，可以一定程度上提高connection reserve的性能，少了reserve時候和其他線程的同步。
        2：壞處是：可能會導致連接數不受管理，從而導致database端的session數達到上限。這跟應用線程并發量有一定關系，如果預估好最大并發請求，還是可控的。