在網絡應用服務器端, 為了性能和防止阻塞, 經常會把邏輯處理和I/O處理分離:
I/O網絡線程處理I/O事件: 數據包的接收和發送, 連接的建立和維護等.
邏輯線程要對收到的數據包進行邏輯處理.
通常網絡線程和邏輯線程之間是通過數據包隊列來交換信息, 簡單來說就是一個生產者-消費者模式.
這個隊列是多個線程在共享訪問必須加鎖, 意味著每次訪問都要加鎖。如何更好的如何減少鎖競爭次數呢 ?
方案一 雙緩沖消息隊列:
兩個隊列，一個給邏輯線程讀，一個給IO線程用來寫，當邏輯線程讀完隊列后會將自己的隊列與IO線程的隊列相調換。
IO線程每次寫隊列時都要加鎖，邏輯線程在調換隊列時也需要加鎖，但邏輯線程在讀隊列時是不需要加鎖的.
隊列緩沖區的大小要根據數據量的大小進行調整的，如果緩沖區很小，就能更及時的處理數據，但吞吐量以及出現資源競爭的幾率大多了。
可以給緩沖隊列設置最大上限，超過上限的數量之后，將包丟棄不插入隊列。
另外，雙緩沖的實現也有不同策略的，
一是讀操作優先，就是生產者只要發現空閑緩沖，馬上swap，
二是寫線程只有在當前的緩沖區寫滿了，才進行swap操作。
三是上層邏輯按照幀率來處理，每一幀的時候將雙層緩沖隊列調換一下，取一個隊列來處理即可
方案二 提供一個隊列容器:
提供一個隊列容器，里面有多個隊列，每個隊列都可固定存放一定數量的消息。網絡IO線程要給邏輯線程投遞消息時，會從隊列容器中取一個空隊列來使用，直到將該隊列填滿后再放回容器中換另一個空隊列。而邏輯線程取消息時是從隊列容器中取一個有消息的隊列來讀取，處理完后清空隊列再放回到容器中。
這樣便使得只有在對隊列容器進行操作時才需要加鎖，而IO線程和邏輯線程在操作自己當前使用的隊列時都不需要加鎖，所以鎖競爭的機會大大減少了。
這里為每個隊列設了個最大消息數，看來好像是打算只有當IO線程寫滿隊列時才會將其放回到容器中換另一個隊列。那這樣有時也會出現IO線程未寫滿一個隊列，而邏輯線程又沒有數據可處理的情況，特別是當數據量很少時可能會很容易出現[這個可以通過設置超時來處理, 如果當前時間-向隊列放入第一個包的時間 > 50 ms, 就將其放回到容器中換另一個隊列]。
通常我們邏輯服務器會以場景來劃分線程,不同線程執行不同場景.一個線程可以執行多個場景.因為玩家屬于場景,我們會把玩家數據,包括其緩沖池丟給場景 去處理.