年底了，也差不多兩個(gè)多月沒(méi)有更新過(guò)這個(gè)blog了，是沒(méi)什么內(nèi)容好寫(xiě)，也是因?yàn)樽约簯辛恕＿@一晃，一年過(guò)去了，對(duì)于已過(guò)而立之年的人來(lái)說(shuō)，日子過(guò)得總是那么快。回首看看自己這一年，沒(méi)什么收獲，工資沒(méi)變、本事沒(méi)漲，虛度了這365天，多多少少有些失落。人生就是一張單程車(chē)票，過(guò)去了也就過(guò)去了，好好珍惜接下來(lái)的每一天吧。

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

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

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


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




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


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



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



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

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


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