客戶端連線過來後，多個空閒的程序，會競爭這個連線，很容易看到，這種競爭會導致不公平，如果某個程序得到 accept 的機會比較多，它的空閒連線很快就用完了，如果不提前做一些控制，當 accept 到乙個新的 tcp 連線後，因為無法得到空閒連線，而且無法將此連線轉交給其它程序，最終會導致此 tcp 連線得不到處理，就中止掉了。很顯然，這是不公平的，有的程序有空餘連線，卻沒有處理機會，有的程序因為沒有空餘連線，卻人為地丟棄連線。那麼，如何解決這個問題呢？首先，nginx 的處理得先開啟 accept_mutex 選項，此時，只有獲得了 accept_mutex 的程序才會去新增accept事件，也就是說，nginx會控制程序是否新增 accept 事件。nginx 使用乙個叫 ngx_accept_disabled 的變數來控制是否去競爭 accept_mutex 鎖。在第一段**中，計算 ngx_accept_disabled 的值，這個值是 nginx 單程序的所有連線總數的八分之一，減去剩下的空閒連線數量，得到的這個 ngx_accept_disabled 有乙個規律，當剩餘連線數小於總連線數的八分之一時，其值才大於 0，而且剩餘的連線數越小，這個值越大。再看第二段**，當 ngx_accept_disabled 大於 0 時，不會去嘗試獲取 accept_mutex 鎖，並且將 ngx_accept_disabled 減 1，於是，每次執行到此處時，都會去減 1，直到小於 0。不去獲取 accept_mutex 鎖，就是等於讓出獲取連線的機會，很顯然可以看出，當空餘連線越少時，ngx_accept_disable 越大，於是讓出的機會就越多，這樣其它程序獲取鎖的機會也就越大。不去 accept，自己的連線就控制下來了，其它程序的連線池就會得到利用，這樣，nginx 就控制了多程序間連線的平衡了。
白話說就是，nginx 會設定乙個 單個程序的可連線總數的 八分之一 作為切換連線的標準， 當這個標準 減去 單個程序的剩餘連線數 大於0 時，即所剩的連線數已經小於 總連線數的八分之一時，會讓該程序讓出 連線機會，即在該程序連線數所剩不多時，切換連線程序。
上**
ngx_accept_disabled = ngx_cycle->connection_n / 8- ngx_cycle->free_connection_n;
if (ngx_accept_disabled > 0
) else
if(ngx_accept_mutex_held)
else
}}
Nginx原始碼分析 程序管理之worker程序
本文著手分析一下worker程序的情況。首先找到worker程序的入口地方 ngx worker process cycle。這個函式不光是worker程序的入口函式，同時也是worker程序迴圈工作的主體函式，看函式名含有乙個cycle嘛。進入這個cycle函式，第一件事就是呼叫ngx worke...
C 記憶體是如何分配的
c 程式在執行時，將記憶體劃分為4個區域 1 區 存放函式體的二進位制 由作業系統進行管理的。存放cpu執行的機器指令，區是共享的，共享的目的是對於頻繁被執行的程式，只需要在記憶體中有乙份 就行了。區是唯讀的，使其唯讀的原因是防止程式意外修改了它的指令。2 全域性區 存放全域性變數和靜態變數以及常量...
C C 程式是如何分配記憶體的？
一 乙個c c 編譯的程式所占用的記憶體分為以下5部分 名稱英文 存放變數型別 分配方式 核心特點 棧區stack 函式的引數值，區域性變數等 程式執行時由編譯器自動分配，程式結束時由編譯器自動釋放。操作方式類似於資料結構中的棧 棧記憶體分配運算內置於處理器的指令集中，效率很高，但是分配的記憶體容量...