不知道你有沒有遇到過這種靈異事件開了十個(gè)線程去抓數(shù)據(jù)邏輯寫得挺小心結(jié)果數(shù)據(jù)不是少幾條就是偶爾重復(fù)又或者模塊明明限制了并發(fā)數(shù)高峰期服務(wù)還是被打穿連接數(shù)一路往上飆。排查了半天鎖也加了隊(duì)列也做了問題依然在。這時(shí)候你十有八九是缺了一個(gè)叫信號(hào)量的東西。信號(hào)量Semaphore是操作系統(tǒng)里最老牌的并發(fā)同步原語(yǔ)之一核心作用用一句話說清讓多個(gè)線程或進(jìn)程對(duì)有限資源做到有條不紊地使用。它不只是加鎖還能做流量控制、連接池管理、生產(chǎn)者消費(fèi)者模型這一大票事情屬于并發(fā)編程繞不過去的基本功。這篇文章我會(huì)從一個(gè)最簡(jiǎn)單的排隊(duì)場(chǎng)景講起把信號(hào)量的原理、P/V 兩個(gè)核心操作、三種主流語(yǔ)言里面的實(shí)際寫法以及工程項(xiàng)目里踩過的坑全部過一遍。適合剛上手多線程編程、對(duì)鎖和信號(hào)量分不太清的人也適合寫了好幾年業(yè)務(wù)代碼、想系統(tǒng)補(bǔ)一下并發(fā)基礎(chǔ)的老開發(fā)。1. 信號(hào)量到底是什么從排隊(duì)打飯說起想象一下食堂只有三個(gè)窗口來了二十個(gè)人。硬件資源就這么點(diǎn)窗口只能同時(shí)服務(wù)三個(gè)人剩下十七個(gè)人要么站著等要么先去干點(diǎn)別的。信號(hào)量干的事情就是給這個(gè)場(chǎng)景配一個(gè)計(jì)數(shù)器計(jì)數(shù)器等于 3 的時(shí)候說明三個(gè)窗口都空著每進(jìn)來一個(gè)人打飯計(jì)數(shù)器減一誰打完了計(jì)數(shù)器加一同時(shí)叫醒一個(gè)排隊(duì)的人。就這么簡(jiǎn)單本質(zhì)上是一個(gè)計(jì)數(shù)器加一個(gè)等待隊(duì)列。和鎖最本質(zhì)的差別也在這一層。鎖關(guān)注的是“互斥”同一時(shí)刻只允許一個(gè)人進(jìn)臨界區(qū)信號(hào)量關(guān)注的是“數(shù)量”它天生就能表達(dá)“允許多少個(gè)訪問”。所以信號(hào)量的計(jì)數(shù)可以大于 1這意味著它處理的不只是競(jìng)爭(zhēng)問題更重要的是容量問題。1.1 一個(gè)計(jì)數(shù)器的自我修養(yǎng)信號(hào)量?jī)?nèi)部就兩個(gè)成員一個(gè)整數(shù)計(jì)數(shù)器一個(gè)等待隊(duì)列。理解了這兩個(gè)成員就理解了信號(hào)量的一切。計(jì)數(shù)器表示當(dāng)前還有多少個(gè)可用的資源。資源可以是空閑連接、剩余容量、可以進(jìn)入的線程額度任何你能量化成“坑位”的東西都行。等待隊(duì)列放著那些因?yàn)槟貌坏劫Y源而被掛起的線程等有人釋放資源時(shí)再?gòu)年?duì)列里挑一個(gè)喚醒。操作系統(tǒng)保證“檢查計(jì)數(shù)、修改計(jì)數(shù)”這兩個(gè)動(dòng)作是原子的。這個(gè)原子性特別關(guān)鍵。比如計(jì)數(shù)器是 3兩個(gè)線程同時(shí)申請(qǐng)資源如果沒有原子性它們可能同時(shí)讀到 3、同時(shí)減一結(jié)果以為有 6 個(gè)資源。信號(hào)量在實(shí)現(xiàn)上會(huì)關(guān)中斷或者用硬件原子指令從內(nèi)核層面保證這點(diǎn)。這也是為什么用戶態(tài)代碼不能自己折騰一個(gè)變量假裝是信號(hào)量——你做不到在檢查與修改之間不被別人插隊(duì)。另外有個(gè)細(xì)節(jié)新手容易懵有些實(shí)現(xiàn)里計(jì)數(shù)器減出來的負(fù)數(shù)表示有多少線程正在等待。計(jì)數(shù)值變成 -2意味著資源已經(jīng)耗盡還有兩個(gè)線程排隊(duì)?？幢O(jiān)控日志的時(shí)候看到負(fù)數(shù)不用慌這恰恰說明一切正常隊(duì)列在起作用。1.2 二值信號(hào)量與計(jì)數(shù)信號(hào)量信號(hào)量最常見的兩種形態(tài)二值信號(hào)量計(jì)數(shù)只能取 0 或 1。它解決的問題和互斥鎖很像但語(yǔ)義并不一樣。互斥鎖有“所有者”概念誰加的鎖誰負(fù)責(zé)解信號(hào)量沒有誰都可以釋放。計(jì)數(shù)信號(hào)量計(jì)數(shù)大于 1允許多個(gè)線程同時(shí)訪問有限資源。連接池、限流器、任務(wù)隊(duì)列容量都是典型場(chǎng)景。用停車場(chǎng)類比最好理解。普通互斥鎖是只有一個(gè)車位的停車場(chǎng)車進(jìn)去門就鎖死二值信號(hào)量也是這個(gè)觀感但細(xì)節(jié)上不同。計(jì)數(shù)信號(hào)量就是有 N 個(gè)車位的停車場(chǎng)入口顯示屏上寫著剩余車位車進(jìn)一輛減一出一輛加一滿員時(shí)新車在外面排隊(duì)。1.3 信號(hào)量適合解決的經(jīng)典場(chǎng)景我工作中用得最多的幾個(gè)場(chǎng)景連接池?cái)?shù)據(jù)庫(kù)連接、外部服務(wù)連接都是稀缺資源不能無限創(chuàng)建用信號(hào)量把并發(fā)連接數(shù)釘死。API 限流第三方接口的并發(fā)承受能力有限比如最多允許 5 個(gè)請(qǐng)求同時(shí)打過去信號(hào)量天然適合。生產(chǎn)者消費(fèi)者緩沖區(qū)有空位才能放數(shù)據(jù)、有數(shù)據(jù)才能取數(shù)據(jù)“空位數(shù)”和“數(shù)據(jù)量”各用一個(gè)信號(hào)量控制。任務(wù)閘門批量任務(wù)要等所有子任務(wù)跑完再匯總可以初始化信號(hào)量為任務(wù)總數(shù)每個(gè)任務(wù)結(jié)束釋放一次主任務(wù)集中獲取 N 次。信號(hào)量不是萬能的。它不適合保護(hù)共享數(shù)據(jù)結(jié)構(gòu)因?yàn)槿鄙偎袡?quán)和重入檢查誤用容易出隱蔽死鎖。下面這章把兩個(gè)核心操作講透你自然就知道哪里能用、哪里不能。2. 兩個(gè)核心操作P/V 背后的設(shè)計(jì)與原理信號(hào)量有兩個(gè)核心操作不同語(yǔ)言里名字不同底層思想完全一致一個(gè)是申請(qǐng)資源一個(gè)是釋放資源。操作系統(tǒng)教材里習(xí)慣叫 P 操作和 V 操作大學(xué)課堂上的經(jīng)典命名。P 大致對(duì)應(yīng)“探查并占用”V 大致對(duì)應(yīng)“增加并喚醒”。理解這兩個(gè)操作比背任何 API 都管用。2.1 P 操作資源不夠就先排隊(duì)P 操作也叫 wait、down、acquire。它的邏輯是void P(sem_t *sem) { // 一直嘗試直到拿到資源 while (1) { if (sem-count 0) { sem-count--; break; } // 沒資源把自己掛進(jìn)等待隊(duì)列 sleep_on(sem-wait_queue); } }這是示意邏輯真實(shí)實(shí)現(xiàn)里檢查和修改必須原子完成。重點(diǎn)在于為什么是 while 而不是 if因?yàn)榫€程被喚醒之后并不意味著一定拿到了資源?？赡芏鄠€(gè)線程同時(shí)被喚醒資源已經(jīng)被別人搶走所以必須重新檢查條件。這就是教科書里常說的“喚醒不一定代表成功需要自旋式地再次確認(rèn)”。很多自己手寫同步邏輯的人在這里翻車用 if 判斷一次醒過來直接往下走結(jié)果資源早就沒了。用健身房?jī)?chǔ)物柜類比每個(gè)柜子是資源你到前臺(tái)問“有沒有空柜子”有就插卡占用沒有就在旁邊等著。這中間不能有另一個(gè)人同時(shí)問你、同時(shí)把最后一個(gè)柜子搶走。聽起來很簡(jiǎn)單但并發(fā)環(huán)境下必須靠原子操作才能保證公平和正確。2.2 V 操作歸還資源叫醒一個(gè)等待者V 操作也叫 signal、up、release。邏輯更簡(jiǎn)單void V(sem_t *sem) { sem-count; if (sem-wait_queue is not empty) { wake_up_one(sem-wait_queue); } }釋放資源就是把計(jì)數(shù)器加一然后從等待隊(duì)列里叫醒一個(gè)線程。注意這里的“叫醒”只是讓它進(jìn)入可運(yùn)行狀態(tài)不代表它立刻就能上 CPU 跑。調(diào)度器可能讓它再等一會(huì)兒所以被喚醒的線程回到 P 操作里還是要重新檢查計(jì)數(shù)器。V 操作有個(gè)容易被忽略但極其重要的特性它不需要由“持有者”調(diào)用?；コ怄i要求誰鎖誰開信號(hào)量沒有這個(gè)限制。任何線程都可以釋放信號(hào)量資源哪怕它從來沒用過這個(gè)資源。這不是缺陷反而是生產(chǎn)者和消費(fèi)者模型能成立的關(guān)鍵生產(chǎn)者占用“空位”消費(fèi)者負(fù)責(zé)歸還“空位”兩者根本不需要知道對(duì)方是誰。2.3 為什么說信號(hào)量沒有“所有者”這是信號(hào)量和互斥鎖之間最深的一道分水嶺?；コ怄i內(nèi)部記錄了持有者線程的 ID可以做到重入檢查同一個(gè)線程重復(fù)加鎖不會(huì)死鎖。信號(hào)量只是一個(gè)計(jì)數(shù)器它不關(guān)心資源是被誰拿走的也不關(guān)心釋放的人是不是當(dāng)初拿走的人。所以用二值信號(hào)量模擬互斥鎖時(shí)如果線程 A 加鎖后異常退出線程 B 理論上可以幫忙調(diào)用 release把計(jì)數(shù)恢復(fù)成 1。看起來是“修復(fù)”了死鎖實(shí)際上臨界區(qū)可能被兩個(gè)線程同時(shí)進(jìn)入事故更大。信號(hào)量的所有者在應(yīng)用層是不存在的設(shè)計(jì)的時(shí)候必須自己約定誰負(fù)責(zé)釋放釋放幾次。各語(yǔ)言的標(biāo)準(zhǔn)庫(kù)提供了互斥鎖所以保護(hù)臨界區(qū)的首選一定是鎖而不是信號(hào)量。一句話總結(jié)鎖管“能不能進(jìn)”信號(hào)量管“能進(jìn)幾個(gè)”。搞混了代碼就會(huì)在詭異的時(shí)間點(diǎn)出問題。2.4 各語(yǔ)言里的“同名不同姓”速查表同一個(gè)概念不同語(yǔ)言的名字五花八門剛切換語(yǔ)言時(shí)很容易暈。記住這張表操作通用叫法C 語(yǔ)言PythonGoJava申請(qǐng)資源P / wait / downsem_waitacquirechannel 發(fā)送acquire釋放資源V / signal / upsem_postreleasechannel 接收release非阻塞申請(qǐng)trywaitsem_trywaitacquire(blockingFalse)select defaulttryAcquire超時(shí)申請(qǐng)timed waitsem_timedwaitacquire(timeout秒)select time.AftertryAcquire(超時(shí))看到?jīng)]有C 里叫 wait/postPython 和 Java 里叫 acquire/releaseGo 里甚至沒有專門的信號(hào)量類型而是用帶緩沖的 channel 實(shí)現(xiàn)。換語(yǔ)言時(shí)別被 API 名字帶偏認(rèn)準(zhǔn)背后是“申請(qǐng)/釋放”這對(duì)操作就行。3. 實(shí)操三種常用語(yǔ)言里的信號(hào)量寫法光講原理不夠我直接給出三套實(shí)戰(zhàn)可用的代碼覆蓋不同的開發(fā)場(chǎng)景。你先復(fù)制跑通再回頭對(duì)照原理看印象會(huì)深很多。3.1 C 語(yǔ)言的 POSIX 信號(hào)量一個(gè)生產(chǎn)者消費(fèi)者示例C 語(yǔ)言用的是 POSIX 信號(hào)量頭文件semaphore.h。下面這個(gè)例子維持一個(gè)容量為 4 的環(huán)形緩沖區(qū)一個(gè)生產(chǎn)者線程往里面放數(shù)據(jù)一個(gè)消費(fèi)者線程往外面取數(shù)據(jù)。空位信號(hào)量empty初始化為 4數(shù)據(jù)信號(hào)量full初始化為 0。#include stdio.h #include pthread.h #include semaphore.h #include unistd.h #define CAPACITY 4 sem_t empty, full; pthread_mutex_t lock PTHREAD_MUTEX_INITIALIZER; int buf[CAPACITY]; int head 0, tail 0; void *producer(void *arg) { for (int i 0; i 10; i) { sem_wait(empty); // 申請(qǐng)一個(gè)空位 pthread_mutex_lock(lock); buf[tail] i; tail (tail 1) % CAPACITY; pthread_mutex_unlock(lock); sem_post(full); // 數(shù)據(jù)量加一 usleep(100000); } return NULL; } void *consumer(void *arg) { for (int i 0; i 10; i) { sem_wait(full); // 申請(qǐng)一個(gè)數(shù)據(jù) pthread_mutex_lock(lock); int val buf[head]; head (head 1) % CAPACITY; pthread_mutex_unlock(lock); sem_post(empty); // 空位加一 printf(got %d\n, val); usleep(200000); } return NULL; } int main() { sem_init(empty, 0, CAPACITY); sem_init(full, 0, 0); pthread_t pt, ct; pthread_create(pt, NULL, producer, NULL); pthread_create(ct, NULL, consumer, NULL); pthread_join(pt, NULL); pthread_join(ct, NULL); sem_destroy(empty); sem_destroy(full); return 0; }編譯時(shí)記得加-pthread。sem_init的第二個(gè)參數(shù) 0 表示線程間共享如果改成非 0信號(hào)量就可以用于進(jìn)程間同步但前提是該內(nèi)存區(qū)域必須能被兩個(gè)進(jìn)程同時(shí)看到通常是共享內(nèi)存。這個(gè)參數(shù)很多人初始化時(shí)隨手填 1進(jìn)程間同步時(shí)發(fā)現(xiàn)兩個(gè)進(jìn)程各搞各的就是這個(gè)原因。還有一個(gè) C 語(yǔ)言特有的坑sem_wait可能被信號(hào)打斷返回 -1 并設(shè)置 errno 為 EINTR。嚴(yán)謹(jǐn)?shù)拇a要循環(huán)重試或者用sem_wait的 GNU 擴(kuò)展自動(dòng)重試。生產(chǎn)環(huán)境不要裸調(diào)一次就放心。3.2 Python 的 threading.Semaphore限流五秒上手Python 的寫法簡(jiǎn)潔得多。下面是一個(gè)限制最多 3 個(gè)并發(fā)請(qǐng)求的限流器import threading import time import random sem threading.Semaphore(3) def request(url): with sem: print(fstart {url}) time.sleep(random.uniform(0.2, 1.0)) print(fdone {url}) threads [threading.Thread(targetrequest, args(i,)) for i in range(5)] for t in threads: t.start() for t in threads: t.join()關(guān)鍵點(diǎn)在with sem它會(huì)自動(dòng)執(zhí)行 acquire 和 release就算中間拋了異常也會(huì)正確釋放。我強(qiáng)烈建議能用with就不要手動(dòng)寫 try/finally少寫一行少一個(gè)事故。一個(gè)進(jìn)階建議線上代碼優(yōu)先用threading.BoundedSemaphore而不是Semaphore。普通信號(hào)量允許 release 任意多次計(jì)數(shù)可能漲到初始值以上這通常意味著邏輯 bugBoundedSemaphore 會(huì)在計(jì)數(shù)超過初始值時(shí)拋出 ValueError讓錯(cuò)誤盡早暴露。這個(gè)細(xì)節(jié)很多老手都不知道但你一旦遇到過計(jì)數(shù)器暴漲把限流變成放行的坑就會(huì)回來把它寫進(jìn)規(guī)范里。3.3 Go 的 channel沒有信號(hào)量類型卻有信號(hào)量的魂Go 語(yǔ)言沒有專門的 semaphore 類型但帶緩沖的 channel 完全可以充當(dāng)計(jì)數(shù)信號(hào)量。緩沖大小就是資源總量往 channel 里發(fā)一個(gè)值相當(dāng)于 acquire從 channel 里收一個(gè)值相當(dāng)于 release。package main import ( fmt sync time ) func main() { ch : make(chan struct{}, 3) // 最大 3 個(gè)并發(fā) var wg sync.WaitGroup for i : 0; i 10; i { wg.Add(1) go func(id int) { defer wg.Done() ch - struct{}{} // 獲取資源 defer func() { -ch }() // 釋放資源 fmt.Println(start, id) time.Sleep(300 * time.Millisecond) fmt.Println(done, id) }(i) } wg.Wait() }用struct{}而不是int或bool是因?yàn)榭战Y(jié)構(gòu)體不占內(nèi)存純粹占位。想實(shí)現(xiàn)非阻塞獲取用 select 加 defaultselect { case ch - struct{}{}: // 拿到了 default: // 沒拿到落入這里的邏輯 }注意發(fā)送ch - struct{}{}一定要放在 worker goroutine 里。如果寫成主協(xié)程先發(fā) 3 個(gè)、再創(chuàng)建 goroutine很容易變成主協(xié)程自己把自己阻塞代碼還特別難查。知道的人看起來很好笑第一次踩的人都懵很久。3.4 Java 的 Semaphore公平模式與超時(shí)獲取Java 的java.util.concurrent.Semaphore功能最全幾個(gè)細(xì)節(jié)非常實(shí)用。構(gòu)造時(shí)傳第二個(gè)參數(shù)true表示公平模式先申請(qǐng)的先拿到資源避免線程饑餓。默認(rèn)非公平模式性能更好但有概率讓某些線程長(zhǎng)時(shí)間吃不到資源。import java.util.concurrent.Semaphore; import java.util.concurrent.TimeUnit; public class SemaphoreDemo { public static void main(String[] args) { Semaphore sem new Semaphore(3, true); for (int i 0; i 6; i) { new Thread(() - { boolean acquired false; try { acquired sem.tryAcquire(500, TimeUnit.MILLISECONDS); if (!acquired) { System.out.println(timeout, drop task); return; } System.out.println(running); Thread.sleep(2000); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { if (acquired) { sem.release(); } } }).start(); } } }tryAcquire帶超時(shí)時(shí)間是線上防雪崩的利器。寧可超時(shí)丟棄一部分任務(wù)也不要讓所有線程無限期掛在信號(hào)量上。finally 里釋放是鐵律Java 的 InterruptedException 在等待期間隨時(shí)可能拋出來如果不在 finally 處理信號(hào)量被永久占住后面所有任務(wù)只能排隊(duì)等到天荒地老。4. 工程案例用信號(hào)量管住有限資源前面是入門樣例這一章我直接講兩個(gè)真實(shí)場(chǎng)景的設(shè)計(jì)思路你會(huì)發(fā)現(xiàn)信號(hào)量的實(shí)際價(jià)值比教科書大得多。4.1 一個(gè)連接池的借用與歸還假設(shè)我要做一個(gè)數(shù)據(jù)庫(kù)連接池最大連接數(shù) 3。連接對(duì)象存在一個(gè)列表里信號(hào)量負(fù)責(zé)控制可用的“坑位”。初始化 idle [conn1, conn2, conn3] sem Semaphore(3) 借連接 sem.acquire() 從 idle 里取一個(gè)連接 還連接 把連接放回 idle sem.release()這與前面代碼的原理一模一樣只是資源從整數(shù)換成了真實(shí)對(duì)象。設(shè)計(jì)時(shí)要注意幾點(diǎn)借出連接后要記錄借用超時(shí)時(shí)間超時(shí)了要回收并釋放信號(hào)量防止連接泄漏。idle 列表要加鎖保護(hù)因?yàn)樗鼤?huì)被并發(fā)修改。信號(hào)量管數(shù)量鎖管安全兩者是配合關(guān)系不是替代關(guān)系。壓測(cè)時(shí)觀察信號(hào)量計(jì)數(shù)的波動(dòng)可以判斷連接池是否夠用。如果計(jì)數(shù)長(zhǎng)期為 0且大量請(qǐng)求在等待就該調(diào)大最大連接數(shù)或者優(yōu)化單連接耗時(shí)。4.2 任務(wù)閘門等所有子任務(wù)跑完再繼續(xù)還有一個(gè)場(chǎng)景是“任務(wù)閘門”比如一個(gè)批量導(dǎo)出任務(wù)要把 10 個(gè)子任務(wù)全部跑完才能合并結(jié)果。很多人第一反應(yīng)是用 sleep 輪詢低效且容易誤判。用信號(hào)量的思路是初始化一個(gè)計(jì)數(shù)信號(hào)量為 0每個(gè)子任務(wù)結(jié)束時(shí) release 一次主任務(wù) acquire 10 次次數(shù)夠了就繼續(xù)。sem Semaphore(0) 每個(gè)子任務(wù)結(jié)束后 sem.release() 主任務(wù) for i in range(10): sem.acquire() 合并結(jié)果這里有一個(gè)關(guān)鍵點(diǎn)信號(hào)量初始值是 0。這不是錯(cuò)誤是“事件通知”用法。每次 release 相當(dāng)于一次完成事件acquire 相當(dāng)于等待一次完成事件。很多語(yǔ)言里還有更高級(jí)的 CountDownLatch、WaitGroup本質(zhì)都是同一個(gè)思想的改良版。理解了信號(hào)量的計(jì)數(shù)語(yǔ)義再看這些工具就一片透明。4.3 與互斥鎖、條件變量怎么選我在技術(shù)評(píng)審里經(jīng)常被問“這場(chǎng)景到底用鎖還是用信號(hào)量”。我的選型標(biāo)準(zhǔn)非常固定同步原語(yǔ)核心語(yǔ)義推薦場(chǎng)景典型風(fēng)險(xiǎn)互斥鎖互斥訪問保護(hù)共享變量、臨界區(qū)死鎖、重入問題條件變量等待某個(gè)條件成立生產(chǎn)者消費(fèi)者中等待“有數(shù)據(jù)”虛假喚醒、忘記喚醒信號(hào)量控制可用數(shù)量限流、資源池、任務(wù)閘門忘記釋放、無所有者屏障/閘門等待 N 個(gè)任務(wù)到達(dá)多階段并行計(jì)算提前超時(shí)誤判我的原則是三個(gè)“不”臨界區(qū)是改共享變量用鎖不硬湊信號(hào)量。要等待某個(gè)具體條件成立用條件變量或 channel信號(hào)量表達(dá)條件語(yǔ)義很費(fèi)勁。要做并發(fā)數(shù)限制、資源池、流量控制優(yōu)先信號(hào)量別用鎖加全局計(jì)數(shù)的方式硬扛。工具本身沒有高下之分選型的依據(jù)永遠(yuǎn)是你要表達(dá)的語(yǔ)義。5. 常見問題與排查技巧實(shí)錄信號(hào)量相關(guān)的問題一旦出 bug多半是“看起來卡住了”或者“并發(fā)數(shù)失控”。下面這些場(chǎng)景都是我真實(shí)遇到過或者幫別人排過的整理成速查表遇到類似癥狀可以直接對(duì)照。5.1 信號(hào)量相關(guān)的經(jīng)典事故事故一忘記 release服務(wù)慢慢卡死現(xiàn)象線上請(qǐng)求越來越慢線程全部堆積數(shù)據(jù)庫(kù)連接數(shù)掉到 0?？淳€程棧大片線程停在 semaphore 的 acquire 方法上。原因多半是某個(gè)異常分支里沒有執(zhí)行 release。排查時(shí)除了看代碼還要看信號(hào)量的當(dāng)前計(jì)數(shù)值如果長(zhǎng)期是 0且沒有一個(gè) release 來源基本就是泄漏。事故二release 寫錯(cuò)位置計(jì)數(shù)器失控普通信號(hào)量允許無限 release某天把 release 放在了循環(huán)外面或者重復(fù)調(diào)用計(jì)數(shù)器一路飆升限流形同虛設(shè)系統(tǒng)被瞬間打爆。Python 用 BoundedSemaphore 能擋住這種問題Java 和 C 就得靠 code review 和自己小心了。事故三多個(gè)信號(hào)量互相等待死鎖線程 A 持有信號(hào)量 S1等待 S2線程 B 持有 S2等待 S1。這種死鎖比鎖死鎖更難發(fā)現(xiàn)因?yàn)樾盘?hào)量的“持有”語(yǔ)義很隱晦。建議多個(gè)信號(hào)量的獲取順序全局一致或者改用帶超時(shí)的獲取方法讓死鎖變成超時(shí)報(bào)錯(cuò)。事故四把二值信號(hào)量當(dāng)互斥鎖用前面已經(jīng)強(qiáng)調(diào)過信號(hào)量沒有所有者線程 B 可以釋放線程 A 持有的資源。代碼里一旦出現(xiàn)“某個(gè)線程釋放另一個(gè)線程獲取的信號(hào)量”這種操作基本等于挖坑。最怕的是異常兜底邏輯里順手調(diào)一下 release看起來是在“救火”實(shí)際把互斥性徹底破壞了。事故五跨進(jìn)程共享信號(hào)量時(shí)初始化參數(shù)不對(duì)進(jìn)程間同步時(shí)sem_init的第二個(gè)參數(shù)必須傳非 0并且信號(hào)量要放在兩個(gè)進(jìn)程都能訪問的共享內(nèi)存里。很多人只改了初始化參數(shù)忘記處理內(nèi)存映射導(dǎo)致 A 進(jìn)程的修改 B 進(jìn)程完全看不見詭異問題層出不窮。5.2 排查手段從現(xiàn)場(chǎng)抓到根因遇到信號(hào)量問題我一般按這個(gè)順序查看當(dāng)前計(jì)數(shù)值。監(jiān)控系統(tǒng)里直接看信號(hào)量計(jì)數(shù)如果長(zhǎng)期為 0 或者異常巨大問題范圍立刻縮窄。抓線程棧?？从卸嗌倬€程阻塞在 acquire 上、它們的調(diào)用棧長(zhǎng)什么樣能快速定位是誰在申請(qǐng)資源、為什么沒人釋放?？聪到y(tǒng)調(diào)用。Linux 下可以用跟蹤工具觀察 futex 相關(guān)系統(tǒng)調(diào)用確認(rèn)線程是在正常排隊(duì)還是真的死鎖。放大復(fù)現(xiàn)。寫一個(gè)壓測(cè)腳本把關(guān)鍵操作循環(huán)一萬次打印每次 acquire 前后的計(jì)數(shù)值通常很快就能看到哪一步把計(jì)數(shù)改壞了。5.3 我的四個(gè)實(shí)操習(xí)慣這些坑踩多了我現(xiàn)在寫并發(fā)代碼有幾條固定習(xí)慣。第一默認(rèn)選擇帶邊界檢查的信號(hào)量比如 Python 的 BoundedSemaphore發(fā)現(xiàn)亂 release 立刻炸出聲寧可報(bào)錯(cuò)也不要沉默地放大故障。第二獲取資源盡量用帶超時(shí)的版本不裸等哪怕超時(shí)后只是記一條日志也比全員掛起強(qiáng)。第三release 一定放在 finally 或 defer 里絕不散落在正常路徑中異常路徑容易忘。第四上線前把信號(hào)量初始值和實(shí)時(shí)計(jì)數(shù)接入監(jiān)控告警閾值設(shè)成 0長(zhǎng)時(shí)間歸零就要警惕。信號(hào)量這東西原理一句話能說完但在生產(chǎn)環(huán)境里能不能用得穩(wěn)全靠這些細(xì)節(jié)。我見過太多因?yàn)樯賹懸粋€(gè) release 引發(fā)的線上事故也見過用信號(hào)量把并發(fā)控制做得極其漂亮的系統(tǒng)。希望這篇能幫你把這個(gè)老牌原語(yǔ)真正吃透下次寫并發(fā)代碼時(shí)第一步想到的不再只是鎖而是先問自己一個(gè)問題這里到底要互斥還是要控量想清楚這個(gè)技術(shù)選型就不會(huì)出錯(cuò)。