在網(wǎng)絡(luò)應(yīng)用服務(wù)器端, 為了性能和防止阻塞, 經(jīng)常會把邏輯處理和I/O處理分離:
I/O網(wǎng)絡(luò)線程處理I/O事件: 數(shù)據(jù)包的接收和發(fā)送, 連接的建立和維護(hù)等.
邏輯線程要對收到的數(shù)據(jù)包進(jìn)行邏輯處理.

通常網(wǎng)絡(luò)線程和邏輯線程之間是通過數(shù)據(jù)包隊列來交換信息, 簡單來說就是一個生產(chǎn)者-消費(fèi)者模式.
這個隊列是多個線程在共享訪問必須加鎖, 意味著每次訪問都要加鎖。如何更好的如何減少鎖競爭次數(shù)呢 ?

方案一 雙緩沖消息隊列:

兩個隊列，一個給邏輯線程讀，一個給IO線程用來寫，當(dāng)邏輯線程讀完隊列后會將自己的隊列與IO線程的隊列相調(diào)換。
IO線程每次寫隊列時都要加鎖，邏輯線程在調(diào)換隊列時也需要加鎖，但邏輯線程在讀隊列時是不需要加鎖的.

隊列緩沖區(qū)的大小要根據(jù)數(shù)據(jù)量的大小進(jìn)行調(diào)整的，如果緩沖區(qū)很小，就能更及時的處理數(shù)據(jù)，但吞吐量以及出現(xiàn)資源競爭的幾率大多了。

可以給緩沖隊列設(shè)置最大上限，超過上限的數(shù)量之后，將包丟棄不插入隊列。
另外，雙緩沖的實現(xiàn)也有不同策略的，

一是讀操作優(yōu)先，就是生產(chǎn)者只要發(fā)現(xiàn)空閑緩沖，馬上swap，
二是寫線程只有在當(dāng)前的緩沖區(qū)寫滿了，才進(jìn)行swap操作。
三是上層邏輯按照幀率來處理，每一幀的時候?qū)㈦p層緩沖隊列調(diào)換一下，取一個隊列來處理即可

方案二 提供一個隊列容器:

提供一個隊列容器，里面有多個隊列，每個隊列都可固定存放一定數(shù)量的消息。網(wǎng)絡(luò)IO線程要給邏輯線程投遞消息時，會從隊列容器中取一個空隊列來使用，直到將該隊列填滿后再放回容器中換另一個空隊列。而邏輯線程取消息時是從隊列容器中取一個有消息的隊列來讀取，處理完后清空隊列再放回到容器中。

這樣便使得只有在對隊列容器進(jìn)行操作時才需要加鎖，而IO線程和邏輯線程在操作自己當(dāng)前使用的隊列時都不需要加鎖，所以鎖競爭的機(jī)會大大減少了。

這里為每個隊列設(shè)了個最大消息數(shù)，看來好像是打算只有當(dāng)IO線程寫滿隊列時才會將其放回到容器中換另一個隊列。那這樣有時也會出現(xiàn)IO線程未寫滿一個隊列，而邏輯線程又沒有數(shù)據(jù)可處理的情況，特別是當(dāng)數(shù)據(jù)量很少時可能會很容易出現(xiàn)[這個可以通過設(shè)置超時來處理, 如果當(dāng)前時間-向隊列放入第一個包的時間 > 50 ms, 就將其放回到容器中換另一個隊列]。

通常我們邏輯服務(wù)器會以場景來劃分線程,不同線程執(zhí)行不同場景.一個線程可以執(zhí)行多個場景.因為玩家屬于場景,我們會把玩家數(shù)據(jù),包括其緩沖池丟給場景 去處理.