最近工作上是在處理一個線程安全的問題,如何保證對某個資源的訪問是獨占的,不會有并發的隱患。在此過程中接了checkthread,一個線程安全的靜態分析工具,通過annotation標記在編譯期檢查可能的并發隱患,提供了一個eclipse插件,有興趣可以看看他的 example。這個東西有個最不好的地方就是要依賴他的自定義annotation,如果不介意的話還是不錯的選擇,一些常見的隱患都能夠標示出來。
另外就是去了解了下netty3,jboss的子項目,netty2和mina作者的另一個作品,關注它是因為在他的benchmark中,netty3的表現很優秀,可以看這篇報告《Performance comparision between java nio framework》。大概看了下他的設計思路,其實與mina并無多大區別,不過使用了一些有意思的trick,例如對于write的處理,一般的nio框架都是放入一個隊列,然后注冊寫事件(隊列為空的時候),等待寫,寫通常也是單線程去寫。而netty3做了一個優化,發送消息時同樣有一個隊列,在放入隊列后判斷當前是否正在寫循環中,如果正在寫,那么就注冊一個WriteTask喚醒selector等待寫;如果沒有,那么發送線程立即就去執行這個寫操作,這里的一個好處是少了兩個開銷:注冊事件等待觸發以及線程切換。Selector.wakeup的操作是比較昂貴的,netty3也做了優化。更多東西等待探索。
山寨nio框架yanf4j已經挺久沒有做出任何改進,這次索性將很多過去考慮不成熟、實踐中證明不必要的代碼刪除和簡化,然后做了個與mina 2.0 -M5的性能對比,采用的netty3作者的benchmark源碼,yanf4j的Echo Server如下:
Echo Server
最后的分析報表,可以看到yanf4j的性能與mina2的性能相近,不過mina在內存使用上非常狠。此外,Xmemcached 1.1.3 將采用最新的yanf4j 0.7.0。
(橫坐標是并發連接數,縱坐標是吞吐量,單位為M/s,測試JDK為1.6.4,具體硬件環境不再詳細列出,與xmemcached的benchmark同)
四張圖分別是在消息長度為64、256、1024、4096字節下的對比。




另外就是去了解了下netty3,jboss的子項目,netty2和mina作者的另一個作品,關注它是因為在他的benchmark中,netty3的表現很優秀,可以看這篇報告《Performance comparision between java nio framework》。大概看了下他的設計思路,其實與mina并無多大區別,不過使用了一些有意思的trick,例如對于write的處理,一般的nio框架都是放入一個隊列,然后注冊寫事件(隊列為空的時候),等待寫,寫通常也是單線程去寫。而netty3做了一個優化,發送消息時同樣有一個隊列,在放入隊列后判斷當前是否正在寫循環中,如果正在寫,那么就注冊一個WriteTask喚醒selector等待寫;如果沒有,那么發送線程立即就去執行這個寫操作,這里的一個好處是少了兩個開銷:注冊事件等待觸發以及線程切換。Selector.wakeup的操作是比較昂貴的,netty3也做了優化。更多東西等待探索。
山寨nio框架yanf4j已經挺久沒有做出任何改進,這次索性將很多過去考慮不成熟、實踐中證明不必要的代碼刪除和簡化,然后做了個與mina 2.0 -M5的性能對比,采用的netty3作者的benchmark源碼,yanf4j的Echo Server如下:

最后的分析報表,可以看到yanf4j的性能與mina2的性能相近,不過mina在內存使用上非常狠。此外,Xmemcached 1.1.3 將采用最新的yanf4j 0.7.0。
(橫坐標是并發連接數,縱坐標是吞吐量,單位為M/s,測試JDK為1.6.4,具體硬件環境不再詳細列出,與xmemcached的benchmark同)
四張圖分別是在消息長度為64、256、1024、4096字節下的對比。



