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

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

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

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


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




       從netstat的結(jié)果來看，WLS到Oracle的連接數(shù)的確也是15個，如下：


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



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



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

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


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