具體情況具體分析吧！如果你的網絡卡是1000Mb ps，1000兆的網路，1400的UDP包，每秒也就不到10萬個包，這個吞吐量下是不是無鎖佇列根本沒什麼區別，瓶頸不會在鎖上面。select可能是個問題，說實話，很多年沒有在Linux服務端用過select了，都是用epoll的，所以select這屬性如何我不知道，但是一定沒有epoll好。

值得注意一下，malloc free memcpy不能用太多了，流量密集型高併發應用忌諱過多操作記憶體，複製分配釋放都會成為瓶頸。比如ublock 的header 和data這倆記憶體，如果沒有記憶體池，那麼malloc 就是至少每秒幾十萬次的，對應的memcpy也是每秒幾十萬次，這個比鎖的開銷大多了啊。

關於更多的Lock Contention,可以參見glibc 中pthread_mutex_lock的原始碼實現，在沒有contention的時候，就是一條CAS指令，核心都沒有陷入，在contention發生的時候，就選擇陷入核心然後睡大覺，嘿嘿，等著某個執行緒nulock 後被喚醒。（詳見Futex ）

感謝，尚有不足，敬請斧正

如果你鎖的碰撞很少，那麼lock free的效能和mutex的效能沒多少差別。如果碰撞很多，lock free就變成了busy pull了，也不會提升多少效能。最主要是減小臨界區的大小，想辦法降低鎖的碰撞。這個才是關鍵。還有，lock free的程式碼編寫難度，不是你想想的那麼低。

如果你說的無鎖是atomicinteger，cas或者xch，而鎖是java裡lock/synchronize，c裡mutex。簡單來說，無鎖一定不慢於鎖。如果衝突不嚴重，差別不大。

一般鎖的實現有兩個分支，一條假設沒衝突，也用cas，所以差不多；如果發現衝突走另一分支。如果要深入瞭解google bias lock

在一個程式中，這些獨立執行的程式片斷叫作“執行緒”（Thread），利用它程式設計的概念就叫作“多執行緒處理”。