問題的背景：在建立連接的時候，Nginx處于充分發揮多核CPU架構性能的考慮，使用了多個worker子進程監聽相同端口的設計，這樣多個子進程在accept建立新連接時會有爭搶，這會帶來著名的“驚群”問題，子進程數量越多越明顯，這會造成系統性能的下降。如何解決驚群問題-post事件處理機制很多操作系統的最新版本的內核已經在事件驅動機制中解決了驚群問題，但Nginx作為可移植性極高的web服務器，還是在自身的應用層面上較好的解決了這一問題。Nginx規定了同一時刻只有唯一一個worker子進程監聽web端口，這一就不會發生驚群了，此時新連接事件只能喚醒唯一的正在監聽端口的worker子進程。如何限制在某一時刻是有一個子進程監聽web端口呢？在打開accept_mutex鎖的情況下，只有調用ngx_trylock_accept_mutex方法后，當前的worker進程才會去試著監聽web端口。我的問題：假定當前所有的woker進程處于休眠狀態，當連接事件發生的時候 ，是不是所有的wokrer進程都會 嘗試獲取鎖，如果獲取成功就會 處理連接事件。 那么這種情況下 不也 回導致 連接事件發生時，喚醒所有的wokrer進程 去競爭獲取鎖嗎？驚群 問題 就是解決 如下問題的而 使用鎖的解決方案中 如何避免多個worker進程 被喚醒競爭鎖？？