莊周夢蝶

   充分利用jprofile等工具觀察性能瓶頸，才能對癥下藥，盲目的優化只是在浪費時間，并且效果可能恰恰相反
1、 觀察到CountDownLatch.await占據最多CPU時間，一開始認為是由于jprofiler帶來的影響，導致這個方法調用時間過長，從而忽 略了這一點，導致后面走了不少彎路。實際上await方法占用50%的CPU，而網絡層和序列化開銷卻比較低，這恰恰說明這兩者的效率低下，沒辦法充分利 用CPU時間，后來觀察spymemcached的CPU占用情況，await占用的時間低于30％，優化后的結果也是如此。

2、因為沒有深入理解這一點，我就盲目地開始優化，先從優化協議匹配算法開始，匹配ByteBuffer一開始用簡單匹配(O(m*n)復雜 度），后來替代以KMP算法做匹配，想當然以為會更快，比較了兩者效率之后才發現KMP的實現竟然比簡單匹配慢了很多，馬上google，得知比之kmp 算法效率高上幾倍的有BM算法，馬上實現之，果然比KMP和簡單匹配都快。換了算法后，一測試，有提升，但很少，顯然這不是熱點。然后開始嘗試改線程模型并測試，一開始想的是往上加線程，畢竟序列化是計算密集型，搞cpu個數的線程去發送command，調整讀Buffer的線程數，測試效率沒有提升甚至 有所降低，期間還測試了將協議處理改成批處理模式等，全部以失敗告終。

3、此時才想起應該觀察下spymemcached的CPU使用情況，才有了上面1點提到的觀察，記的在測試yanf4j的echo server的時候，我發現讀Buffer線程數設為0的事情下比之1的效率更高，也就是說僅啟動一個線程處理Select、OP_WRITE和 OP_READ的事件，對于echo這樣簡單的任務來說是非常高效的，難道memcached也如此？立馬設置為0并測試，果然提升很多，與 spymemcached的TPS差距一下減小了2000多，進一步觀察，由于xmemcached構建在yanf4j的基礎上，為了分層清晰導致在發送 和接收消息環節有很多冗余的操作，并且我還多啟動了一個線程做command發送和優化get、set操作，如果能磨平這些差異，擴展yanf4j，避免了隊列同步開銷，這樣也不用額外啟動線程，效率是否更高呢？得益于yanf4j的模塊化，修改工作順利進行，最后的測試結果也證明了我的猜測，效率已經接近 spymemcached甚至超過。