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