昨天在看Cache Client代碼的時(shí)候，發(fā)現(xiàn)在從資源池中獲取SocketIO部分代碼在高并發(fā)情況下效率不高，因此考慮通過(guò)一些變通的方式來(lái)提高效率，下面說(shuō)的內(nèi)容僅僅是當(dāng)前自己琢磨出來(lái)可以部分提高效率的方法，希望看了這篇文章的同學(xué)能夠有更好的方式或者算法來(lái)提高效率。
情景：
Cache Client 的SocketIO資源池是一個(gè)兩級(jí)的Map，具體定義為：ConcurrentMap<String, ConcurrentMap<SockIO, Integer>>。第一級(jí)Map以Host作為Key，第二級(jí)Map以SockIO本身作為Key，三種SockIO狀態(tài)（可用，占用，廢棄）作為value。之所以采用一個(gè)Pool來(lái)存儲(chǔ)三種狀態(tài)主要是考慮到在高并發(fā)下，多個(gè)池之間保持原子性的復(fù)雜。
每一次獲取可用的SocketIO的操作需要經(jīng)歷：1.遍歷Host所在的Map。2.逐個(gè)比較狀態(tài)。3.原子方法獲取可用SocketIO。（并發(fā)問(wèn)題所要求的，具體代碼可以下載：http://memcache-client-forjava.googlecode.com/files/alisoft-xplatform-asf-cache-2.5.1-src.jar ）。
在修改過(guò)去的版本里面，首先遍歷的過(guò)程是一個(gè)固定順序的過(guò)程（keyset），這樣會(huì)導(dǎo)致在高并發(fā)的情況下，越來(lái)越多的資源申請(qǐng)命中率會(huì)下降，因?yàn)閴毫偸锹湓?/span>keyset靠前的那些SockIO上（重復(fù)比較）。需要考慮通過(guò)什么手段可以提高在高并發(fā)下的申請(qǐng)命中率。
思考：
1． 資源申請(qǐng)的越早，被釋放的可能性越高，因此是否可以考慮采用更新SockIO最后申請(qǐng)時(shí)間來(lái)作為后續(xù)申請(qǐng)的初步依據(jù)。（本身復(fù)雜度帶來(lái)的耗時(shí)可能會(huì)超過(guò)命中率降低帶來(lái)的損耗）
2． 采用隨機(jī)數(shù)的方式來(lái)確定keyset的起始游標(biāo)，也就不是每次都從keyset第一位開(kāi)始（可以把keyset看作一個(gè)首尾相接的數(shù)組）。
3． 在每次資源回收的時(shí)候紀(jì)錄下該資源為可用（當(dāng)前為每一個(gè)Host就記錄一個(gè)可能可用的資源，簡(jiǎn)單化操作），作為申請(qǐng)的首選嘗試。（嘗試不成功在去遍歷）。
當(dāng)前實(shí)現(xiàn)了2,3組合，發(fā)現(xiàn)效果明顯，在500個(gè)并發(fā)下，每個(gè)線(xiàn)程200次操作（一系列動(dòng)作），壓力測(cè)試結(jié)果如下：
Cache test consume(cache測(cè)試總共耗時(shí))，average boundle consume（每個(gè)線(xiàn)程總耗時(shí)），average per request（每個(gè)線(xiàn)程每次操作總耗時(shí)）
沒(méi)有作任何改動(dòng)以前的測(cè)試結(jié)果：
cache test consume: 11507741, average boundle consume: 57538, average per request :115
采用了2策略以后的測(cè)試結(jié)果：
cache test consume: 10270512, average boundle consume: 51352, average per request :102
采用了2，3策略以后的測(cè)試結(jié)果：
cache test consume: 9140660, average boundle consume: 45703, average per request :91