一、前言
IO線程模型一直在演化，由最開始的單線程模型，到BIO方式的單線程接受請求線程池線程具體處理單個請求的讀寫事件，再到NIO的單線程接受請求線程池裏面的單個線程可以處理不同請求的讀寫事件，一個字沒有最快，只有更快。最近發現還有個Leader-follower線程模型，其的出現是爲了解決單線程接受請求線程池線程處理請求下線程上下文切換以及線程間通信數據拷貝的開銷，並且不需要維護一個隊列。
二、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移到了消息隊列上，此時消息隊列僅僅只能起到消息緩衝的作用。
根本解決方案是降低鎖粒度（例如多個隊列）。