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