“據說”驚羣問題已經是一個很古老的問題了，並且在大多數系統中已經得到有效解決，但對我來說，仍舊是一個比較新的概念，因此有必要記錄一下。
什麼是驚羣
舉一個很簡單的例子，當你往一羣鴿子中間扔一塊食物，雖然最終只有一個鴿子搶到食物，但所有鴿子都會被驚動來爭奪，沒有搶到食物的鴿子只好回去繼續睡覺， 等待下一塊食物到來。這樣，每扔一塊食物，都會驚動所有的鴿子，即爲驚羣。對於操作系統來說，多個進程/線程在等待同一資源是，也會產生類似的效果，其結 果就是每當資源可用，所有的進程/線程都來競爭資源，造成的後果：
1）系統對用戶進程/線程頻繁的做無效的調度、上下文切換，系統系能大打折扣。
2）爲了確保只有一個線程得到資源，用戶必須對資源操作進行加鎖保護，進一步加大了系統開銷。
最常見的例子就是對於socket描述符的accept操作，當多個用戶進程/線程監聽在同一個端口上時，由於實際只可能accept一次，因此就會產生驚羣現象，當然前面已經說過了，這個問題是一個古老的問題，新的操作系統內核已經解決了這一問題。
linux內核解決驚羣問題的方法
對於一些已知的驚羣問題，內核開發者增加了一個“互斥等待”選項。一個互斥等待的行爲與睡眠基本類似，主要的不同點在於：
1）當一個等待隊列入口有 WQ_FLAG_EXCLUSEVE 標誌置位, 它被添加到等待隊列的尾部. 沒有這個標誌的入口項, 相反, 添加到開始.
2）當 wake_up 被在一個等待隊列上調用時, 它在喚醒第一個有 WQ_FLAG_EXCLUSIVE 標誌的進程後停止。
也就是說，對於互斥等待的行爲，比如如對一個listen後的socket描述符，多線程阻塞accept時，系統內核只會喚醒所有正在等待此時間的隊列 的第一個，隊列中的其他人則繼續等待下一次事件的發生，這樣就避免的多個線程同時監聽同一個socket描述符時的驚羣問題。
根據以上背景信息，我們來比較一下常見的Server端設計方案。
方案2：主線程負責監聽，通過線程池方式處理連接。（通常的方法）
方案3：主線程負責監聽，客戶端連接上來後由主線程分配實際的端口，客戶端根據此端口重新連接，然後處理數據。
先考慮客戶端單連接的情況：
方案1：每當有新的連接到來時，系統內核會從隊列中以FIFO的方式選擇一個監聽線程來服務此連接，因此可以充分發揮系統的系能並且多線程負載均衡。對於單連接的場景，這種方案無疑是非常優越的。遺憾的是，對於select、epoll，內核目前無法解決驚羣問題。(nginx對於驚羣問題的解決方法)
方案2：由於只有一個線程在監聽，其瞬時的併發處理連接請求的能力必然不如多線程。同時，需要對線程池做調度管理，必然涉及資源共享訪問，相對於方案一來說管理成本要增加不少，代碼複雜度提高，性能也有所下降。
方案3：與方案2有不少類似的地方，其優勢是不需要做線程調度。缺點是增加了主線程的負擔，除了接收連接外還需要發送數據，而且需要兩次連接，孰優孰劣，有待測試。
再考慮客戶端多連接的情況：
對於數據傳輸類的應用，爲了充分利用帶寬，往往會開啓多個連接來傳輸數據，連接之間的數據有相互依賴性，因此Server端要想很好的維護這種依賴性，把同一個客戶端的所有連接放在一個線程中處理是非常有必要的。
A、同一客戶端在一個線程中處理
方案1：如果沒有更底層的解決方案的話，Server則需要維護一個全局列表，來記錄當前連接請求該由哪個線程處理。多線程需要同時競爭一個全局資源，似乎有些不妙。
方案2：主線程負責監聽並分發，因此與單連接相比沒有帶來額外的性能開銷。僅僅會造成主線程忙於更多的連接請求。
方案3：較單線程來說，主線程工作量沒有任何增加，由於多連接而造成的額外開銷由實際工作線程分擔，因此對於這種場景，方案3似乎是最佳選擇。
B、同一客戶端在不同線程中處理
方案1：同樣需要競爭資源。
方案2：沒理由。
方案3：不可能。
另外：
讀《UNIX網絡編程》第二版的第一卷時，發現作者在第27章“客戶-服務器程序其它設計方法”中的27.6節“TCP預先派生子進程服務器程序，accept無上鎖保護”中提到了一種由子進程去競爭客戶端連接的設計方法，用僞碼描述如下:
服務器主進程:
|
服務器服務子進程:
|
初識上述代碼，真有眼前一亮的感覺，也正如作者所說，以上代碼確實很少見（反正我讀此書之前是確實沒見過）。作者真是構思精巧，巧妙地繞過了常見的預先創建 子進程的多進程服務器當主服務進程接收到新的連接必須想辦法將這個連接傳遞給服務子進程的“陷阱”，上述代碼通過共享的傾聽套接字，由子進程主動地去向內 核“索要”連接套接字，從而避免了用UNIX域套接字傳遞文件描述符的“淫技”。
不過，當接着往下讀的時候，作者談到了“驚羣” （Thundering herd)問題。所謂的“驚羣”就是，當很多進程都阻塞在accept系統調用的時候，即使只有一個新的連接達到，內核也會喚醒所有阻塞在accept上 的進程，這將給系統帶來非常大的“震顫”，降低系統性能。
除了這個問題，accept還必須是原子操作。爲此，作者在接下來的27.7節講述了加了互斥鎖的版本：
|
原子操作的問題算是解決了，那麼“驚羣”呢？文中只是提到在Solaris系統上當子進程數由75變成90後，CPU時間顯著增加，並且作者認爲這是因爲進 程過多，導致內存互換。對“驚羣”問題回答地十分含糊。通過比較書中圖27.2的第4列和第7列的內容，我們可以肯定“真兇”絕對不是“內存對換”。
“元兇”到底是誰？
仔細分析一下，加鎖真的有助於“驚羣”問題麼？不錯，確實在同一時間只有一個子進程在調用accept，其它子進程都阻塞在了lock語句，但是，當 accept返回並unlock之後呢？unlock肯定是要喚醒阻塞在這個鎖上的進程的，不過誰都沒有規定是喚醒一個還是喚醒多個。所以，潛在的“驚 羣”問題還是存在，只不過換了個地方，換了個形式。而造成Solaris性能驟降的“罪魁禍首”很有可能就是“驚羣”問題。
崩潰了！這麼說所有的鎖都有可能產生驚羣問題了？
似乎真的是這樣，所以減少鎖的使用很重要。特別是在競爭比較激烈的地方。
作者在27.9節所實現的“傳遞文件描述符”版本的服務器就有效地克服了“驚羣”問題，在現實的服務器實現中，最常用的也是此節所提到的基於“分配”形式。
把“競爭”換成“分配”是避免“驚羣”問題的有效方法，但是也不要忽視“分配”的“均衡”問題，不然後果