雙緩衝訊息佇列-減少鎖競爭
** 在網路應用伺服器端, 為了效能和防止阻塞, 經常會把邏輯處理和i/o處理分離:
i/o網路執行緒處理i/o事件: 資料報的接收和傳送, 連線的建立和維護等.
邏輯執行緒要對收到的資料報進行邏輯處理.
通常網路執行緒和邏輯執行緒之間是通過資料報佇列來交換資訊, 簡單來說就是乙個生產者-消費者模式.
這個佇列是多個執行緒在共享訪問必須加鎖, 意味著每次訪問都要加鎖。如何更好的如何減少鎖競爭次數呢 ?
方案一 雙緩衝訊息佇列:
兩個佇列，乙個給邏輯執行緒讀，乙個給io執行緒用來寫，當邏輯執行緒讀完佇列後會將自己的佇列與io執行緒的佇列相調換。
io執行緒每次寫佇列時都要加鎖，邏輯執行緒在調換佇列時也需要加鎖，但邏輯執行緒在讀佇列時是不需要加鎖的.
佇列緩衝區的大小要根據資料量的大小進行調整的，如果緩衝區很小，就能更及時的處理資料，但吞吐量以及出現資源競爭的機率大多了。
可以給緩衝佇列設定最大上限，超過上限的數量之後，將包丟棄不插入佇列。
另外，雙緩衝的實現也有不同策略的，
一是讀操作優先，就是生產者只要發現空閒緩衝，馬上swap，
二是寫執行緒只有在當前的緩衝區寫滿了，才進行swap操作。
三是上層邏輯按照幀率來處理，每一幀的時候將雙層緩衝佇列調換一下，取乙個佇列來處理即可
方案二 提供乙個佇列容器:
提供乙個佇列容器，裡面有多個佇列，每個佇列都可固定存放一定數量的訊息。網路io執行緒要給邏輯執行緒投遞訊息時，會從佇列容器中取乙個空佇列來使用，直到將該佇列填滿後再放回容器中換另乙個空佇列。而邏輯執行緒取訊息時是從佇列容器中取乙個有訊息的佇列來讀取，處理完後清空佇列再放回到容器中。
這樣便使得只有在對佇列容器進行操作時才需要加鎖，而io執行緒和邏輯執行緒在操作自己當前使用的佇列時都不需要加鎖，所以鎖競爭的機會大大減少了。
這裡為每個佇列設了個最大訊息數，看來好像是打算只有當io執行緒寫滿佇列時才會將其放回到容器中換另乙個佇列。那這樣有時也會出現io執行緒未寫滿乙個佇列，而邏輯執行緒又沒有資料可處理的情況，特別是當資料量很少時可能會很容易出現[這個可以通過設定超時來處理, 如果當前時間-向佇列放入第乙個包的時間 > 50 ms, 就將其放回到容器中換另乙個佇列]。
通常我們邏輯伺服器會以場景來劃分執行緒,不同執行緒執行不同場景.乙個執行緒可以執行多個場景.因為玩家屬於場景,我們會把玩家資料,包括其緩衝池丟給場景 去處理.
雙緩衝佇列
前段時間，做了個 雙緩衝佇列 可是測試的效果就是不怎麼明顯，理論完全都在這裡，可是就是看不到效果。昨天在胡總的提示下，終於意識到不該用阻塞佇列，換成普通的list物件，這樣效果就明顯多啦 又重新寫了一篇文件，如下 好，31毫秒。這是我們的第一種解決方法，下面再來看第二種解決方法 其實我們在facto...
雙緩衝佇列
例一 首先，使用arrayblockingqueue類建立乙個大小為10的雙緩衝佇列queue 然後，迴圈20次向佇列queue中新增元素，如果5秒內元素仍沒有入隊到佇列中，則返回false 如下 public class demo03 catch interruptedexception e 測試...
伺服器雙緩衝訊息佇列方案
雙緩衝訊息佇列 減少鎖競爭 收藏 雙緩衝訊息佇列 減少鎖競爭 在網路應用伺服器端,為了效能和防止阻塞,經常會把邏輯處理和i o處理分離 i o網路執行緒處理i o事件 資料報的接收和傳送,連線的建立和維護等.邏輯執行緒要對收到的資料報進行邏輯處理.通常網路執行緒和邏輯執行緒之間是通過資料報佇列來交換...