io執行緒模型一直在演化，由最開始的單執行緒模型，到bio方式的單執行緒接受請求執行緒池執行緒具體處理單個請求的讀寫事件，再到nio的單執行緒接受請求執行緒池裡面的單個執行緒可以處理不同請求的讀寫事件，乙個字沒有最快，只有更快。最近發現還有個leader-follower執行緒模型，其的出現是為了解決單執行緒接受請求執行緒池執行緒處理請求下執行緒上下文切換以及執行緒間通訊資料拷貝的開銷，並且不需要維護乙個佇列。
上圖就是l/f多執行緒模型的狀態變遷圖，共6個關鍵點：
（1）執行緒有3種狀態：領導leading，處理processing，追隨following
（2）假設共n個執行緒，其中只有1個leading執行緒（等待任務），x個processing執行緒（處理），餘下有n-1-x個following執行緒（空閒）
（3）有一把鎖，誰搶到就是leading
（4）事件/任務來到時，leading執行緒會對其進行處理，從而轉化為processing狀態，處理完成之後，又轉變為following
（5）丟失leading後，following會嘗試搶鎖，搶到則變為leading，否則保持following
（6）following不幹事，就是搶鎖，力圖成為leading
優點：不需要訊息佇列
適用場景：執行緒能夠很快的完成工作任務
有人說「併發量大時，l/f的鎖容易成為系統瓶頸，需要引入乙個訊息佇列解決。」
此觀點不對，乙個訊息佇列，其仍是臨界資源，仍需要一把鎖來保證互斥，只是鎖競爭從leading移到了訊息佇列上，此時訊息佇列僅僅只能起到訊息緩衝的作用。
根本解決方案是降低鎖粒度（例如多個佇列）。
leader follower 模型讀書筆記
douglas c.schmidt,carlos o ryan,michael kircher,i n pyarali,and frank buschmann 1.傳統的乙個執行緒select io 多個執行緒 worker 處理模型的缺點 a.io執行緒收到訊息後，需要動態分配記憶體，將請求放在該...
Leader Follower 程序池設計思路
看了 url 的分析文章 url 之後，覺得裡面的圖非常好地描述了 apache 的結構。也嘗試用 visio 畫一下 url 的結構。對圖中各個部分的說明 1.masterserver 通過 fork 建立 processmanager processpool 作為 processmanager ...
對於線線問題
以下是乙個大佬的總結 authorlcy註明出處，摘自 1 n條直線最多分平面問題 題目大致如 n條直線，最多可以把平面分為多少個區域。析 可能你以前就見過這題目，這充其量是一道初中的思考題。但乙個型別的題目還是從簡單的入手，才容易發現規律。當有n 1條直線時，平面最多被分成了f n 1 個區域。則...