這次來聊一個很多 Python 開發(fā)者都遇到過的現(xiàn)象機器明明是 4 核程序也開了 4 個線程結(jié)果 CPU 占用率一直上不去4 個核沒有一個跑滿。第一反應(yīng)通常是線程寫得不對或者操作系統(tǒng)調(diào)度有問題。但如果你的代碼是純 Python 的 CPU 密集計算那么問題大概率出在 CPython 解釋器內(nèi)置的 GIL 上。GIL 的全稱是 Global Interpreter Lock中文一般叫全局解釋器鎖。網(wǎng)上講 GIL 的文章很多但多數(shù)停留在概念解釋。這篇博客會從“現(xiàn)象”出發(fā)用兩個可以直接運行的 Python 實驗把結(jié)論驗證出來CPU 密集場景下多線程在 CPython 里基本不能利用多核想榨干多核要換 multiprocessing 多進程。同時也會說明經(jīng)常被忽略的另一面如果是 I/O 密集場景比如爬蟲、文件讀寫、網(wǎng)絡(luò)請求多線程依然非常有用。這篇文章適合正在學 Python 并發(fā)的同學也適合已經(jīng)寫了幾年 Python 但一直被“多線程和 GIL 說不清”困擾的開發(fā)者。讀完你會得到一份可以收藏備用的排查清單先看任務(wù)類型再看解釋器最后決定用線程池、進程池還是異步方案。1. GIL 到底鎖了什么核心知識點速覽先把結(jié)論放出來GIL 鎖的不是某個變量也不是某段業(yè)務(wù)代碼而是 CPython 解釋器里 Python 字節(jié)碼的執(zhí)行權(quán)限。也就是說一個進程里同時只能有一個線程真正在執(zhí)行 Python 字節(jié)碼其他線程就算已經(jīng)創(chuàng)建成功也只能等待 GIL 釋放。項目說明GIL 全稱Global Interpreter Lock全局解釋器鎖鎖的粒度進程級別一個 Python 進程只有一個 GIL鎖住的是什么Python 字節(jié)碼的解釋執(zhí)行權(quán)限受影響最大的場景純 Python 寫的 CPU 密集計算不受影響的場景I/O 等待、網(wǎng)絡(luò)請求、文件讀寫、部分會釋放 GIL 的 C 擴展典型的替代方案multiprocessing、concurrent.futures.ProcessPoolExecutor、任務(wù)隊列多線程適合的場景I/O 密集任務(wù)爬蟲、批量請求、文件處理多進程適合的場景CPU 密集任務(wù)大量計算、圖像算法、數(shù)據(jù)清洗判斷方法運行任務(wù)時打開任務(wù)管理器或 htop 看各核占用率這里有個很容易混淆的點GIL 是 CPython 的實現(xiàn)細節(jié)不是 Python 語言規(guī)范的一部分。Java 沒有 GILJython 或 IronPython 也沒有 CPython 這種 GIL。但絕大多數(shù)開發(fā)者在命令行敲 python 啟動的解釋器就是 CPython所以討論 GIL 對日常開發(fā)是有實際意義的。還要強調(diào)一下GIL 不等于線程安全。很多新手以為有了 GIL多線程操作共享變量就不會出問題。實際上 GIL 只保證單個字節(jié)碼指令級別的安全并不保證一段多步操作的完整性。業(yè)務(wù)代碼里的共享數(shù)據(jù)該用 Lock 還是得用 Lock。2. 什么時候用多線程什么時候換多進程場景邊界判斷該用多線程還是多進程核心是看任務(wù)是 CPU 密集還是 I/O 密集。這個判斷比“哪個 API 更快”更重要。選錯模型代碼寫得再漂亮性能也上不去。任務(wù)特點優(yōu)先方案原因CPU 密集純 Python 計算multiprocessingProcessPoolExecutor每個進程有獨立 GIL能真正使用多核I/O 密集大量等待threadingThreadPoolExecutor等待 I/O 時線程會讓出 GIL其他線程可以運行混合型任務(wù)計算量大且有外部調(diào)用多進程做粗粒度并行進程內(nèi)再用多線程處理 I/O既利用多核又能高并發(fā)處理外部請求高并發(fā) Web 服務(wù)、長連接、異步事件asyncio 事件循環(huán)單線程配合異步 I/O資源占用更小用真實場景來解釋更直觀。如果你在寫一個批量爬蟲大部分時間花在等待對方服務(wù)器響應(yīng)這時候用多線程是對的。線程在 socket 等待期間會釋放 GIL讓其他線程去發(fā)請求整體并發(fā)量能大幅提升。反過來如果任務(wù)是遍歷一個很大的列表做數(shù)學計算比如統(tǒng)計質(zhì)數(shù)、處理圖像像素計算本身不涉及任何外部等待那么多線程就幫不上忙。因為每個線程搶到 GIL 后只執(zhí)行一小段字節(jié)碼又要讓給下一個線程表面上開了 4 個線程實際是在一個核上輪流干活還要搭上切換開銷。有一個特殊情況也要知道如果計算發(fā)生在 numpy、PyTorch 這類 C 擴展內(nèi)部很多底庫在執(zhí)行計算時會主動釋放 GIL這時候多線程可能也能看到一定并行效果。但這種情況并不穩(wěn)定依賴具體庫的實現(xiàn)不能把“多線程對 CPU 密集計算有效”當成通用結(jié)論。最穩(wěn)妥的原則是純 Python 循環(huán)級別的 CPU 密集任務(wù)優(yōu)先考慮多進程。3. 為什么 4 個線程跑不滿 4 個核回到標題里“4 個線程沒跑滿 4 個核”的現(xiàn)象。要理解這個問題得先知道 GIL 在解釋器內(nèi)部是怎么工作的。每個 CPython 進程啟動時都會創(chuàng)建一把 GIL。線程要執(zhí)行 Python 字節(jié)碼第一件事就是嘗試獲取這把鎖。拿到鎖的線程可以連續(xù)執(zhí)行一定數(shù)量的字節(jié)碼指令到了切換點或者被操作系統(tǒng)強制搶占時釋放 GIL然后其他線程才有機會去搶。問題在于純 CPU 計算任務(wù)里沒有任何阻塞等待點線程不會主動讓出 GIL只能靠解釋器的指令計數(shù)切換和操作系統(tǒng)的線程調(diào)度。結(jié)果就是4 個線程反復(fù)競爭同一把鎖但同一時刻只有一個線程在真正計算。用系統(tǒng)監(jiān)視器看 CPU 曲線通常是一個核接近滿載其他核大部分時間低占用偶爾因為鎖切換和調(diào)度露出一些“小尖峰”。四核機器上多線程 CPU 密集任務(wù)的執(zhí)行時間不僅不會縮短甚至可能比單線程略慢。因為線程從創(chuàng)建、切換到銷毀都有成本GIL 競爭還會讓線程頻繁阻塞和喚醒。很多人覺得“Python 多線程沒用”其實說的是這一類場景。如果你遇到了“線程數(shù)等于核數(shù)、CPU 卻沒打滿”的情況排查順序應(yīng)該是先確認任務(wù)是不是真的純 CPU 計算里面有沒有隱藏的 I/O 等待比如打印日志、讀寫文件、請求數(shù)據(jù)庫。再確認運行的 Python 是不是標準 CPython 構(gòu)建。如果你用的是 Python 3.13 的實驗性 Free-Threaded 版本行為會不一樣但那不是大多數(shù)環(huán)境的默認情況。最后才看自己的并發(fā)代碼本身是不是線程之間加了不必要的鎖或者在循環(huán)里頻繁打印導(dǎo)致性能退化。只有先排除掉這些因素才能比較確定地說是 GIL 限制了并行。4. CPU 密集場景驗證多線程 vs 多進程理論不能只靠背下面直接跑實驗驗證。實驗代碼只用了 Python 標準庫不需要安裝第三方依賴。4.1 環(huán)境準備建議使用 Python 3.8 以上的版本測試機器有 4 核或更多。操作系統(tǒng)不限但下面看 CPU 占用時Windows 用任務(wù)管理器macOS 用活動監(jiān)視器Linux 用 top 或 htop?？梢韵扔靡欢蚊畲_認環(huán)境信息python --version python -c import os; print(os.cpu_count())4.2 實驗代碼復(fù)制下面的代碼保存為 gil_demo.py。邏輯很簡單找出 150000 以內(nèi)的質(zhì)數(shù)數(shù)量分別用單線程、多線程、多進程跑相同量級的工作比較耗時。import os import time from concurrent.futures import ProcessPoolExecutor, ThreadPoolExecutor def is_prime(n: int) - bool: if n 2: return False if n in (2, 3): return True if n % 2 0 or n % 3 0: return False i 5 while i * i n: if n % i 0 or n % (i 2) 0: return False i 6 return True def count_primes(limit: int) - int: counts 0 for num in range(2, limit): if is_prime(num): counts 1 return counts def run_single(limit: int) - float: start time.perf_counter() count_primes(limit) return time.perf_counter() - start def run_threads(limit: int, workers: int) - float: start time.perf_counter() with ThreadPoolExecutor(max_workersworkers) as pool: list(pool.map(count_primes, [limit] * workers)) return time.perf_counter() - start def run_processes(limit: int, workers: int) - float: start time.perf_counter() with ProcessPoolExecutor(max_workersworkers) as pool: list(pool.map(count_primes, [limit] * workers)) return time.perf_counter() - start if __name__ __main__: LIMIT 150_000 WORKERS os.cpu_count() or 4 print(f邏輯核數(shù): {WORKERS}, 計算范圍: {LIMIT}) single run_single(LIMIT) thread run_threads(LIMIT, WORKERS) process run_processes(LIMIT, WORKERS) print(f單線程基線: {single:.2f} s) print(f{WORKERS} 個線程: {thread:.2f} s) print(f{WORKERS} 個進程: {process:.2f} s)運行命令python gil_demo.py4.3 運行效果與判斷標準不同機器跑出來的絕對時間不一樣但趨勢基本一致執(zhí)行模式預(yù)期趨勢單線程作為基線假設(shè)耗時為 T多線程大約接近 N 倍 T甚至比 N 倍 T 還高一點幾乎沒有加速多進程接近 T / N受核數(shù)、調(diào)度、序列化開銷影響判斷實驗是否成功的標準有三個多線程耗時沒有明顯低于單線程多進程耗時明顯下降運行多進程期間系統(tǒng)監(jiān)視器能看到多個核被同時拉高。這就是“CPU 密集任務(wù)該換多進程”的直接證據(jù)。如果你把 LIMIT 調(diào)大比如到 500000多線程和多進程的差距會更明顯。但第一次測試建議先用較小的值跑通避免本機計算時間過長。這里有一個注意事項ProcessPoolExecutor 在 Windows 上依賴 spawn 方式創(chuàng)建子進程要求主模塊可以安全導(dǎo)入。所以進程池的啟動代碼必須放在 ifname main: 里面不要直接在模塊頂層執(zhí)行。這也是很多 Windows 用戶跑多進程代碼時反復(fù)崩潰的原因。5. I/O 密集場景驗證多線程的優(yōu)勢看到多線程在 CPU 密集任務(wù)中沒有加速很容易產(chǎn)生“Python 多線程沒用”的想法。但這是錯誤的。下面驗證 I/O 密集場景也就是真正適合多線程的領(lǐng)域。5.1 用 sleep 模擬 I/O 等待真實網(wǎng)絡(luò)請求需要外部服務(wù)配合環(huán)境不穩(wěn)定。為了便于復(fù)現(xiàn)先用 time.sleep 模擬阻塞等待。sleep 會讓線程進入等待狀態(tài)并釋放 GIL行為和網(wǎng)絡(luò)請求、文件讀取的基本模式一致都可以反映線程并發(fā)的收益。import time from concurrent.futures import ThreadPoolExecutor def fetch_one(url: str) - str: # 真實場景替換為 requests.get(url) 或 urllib.request.urlopen(url) time.sleep(1) # 模擬網(wǎng)絡(luò)等待 return url def run_single(urls): start time.perf_counter() for url in urls: fetch_one(url) return time.perf_counter() - start def run_thread(urls): start time.perf_counter() with ThreadPoolExecutor(max_workers8) as pool: list(pool.map(fetch_one, urls)) return time.perf_counter() - start if __name__ __main__: urls [fhttps://example.com/news/{i} for i in range(8)] single_used run_single(urls) thread_used run_thread(urls) print(f串行耗時: {single_used:.2f} s) print(f線程池耗時: {thread_used:.2f} s)運行結(jié)果會顯示8 個任務(wù)每個等待 1 秒串行大約是 8 秒左右線程池只需要 1 秒多。這就是 I/O 密集場景下多線程的核心價值線程在等待期間釋放 GIL其他線程可以繼續(xù)執(zhí)行。5.2 真實爬蟲場景擴展把 sleep 換掉就是典型的并發(fā)爬蟲雛形?？梢杂?urllib 標準庫做真實請求測試但要遵守目標站點的訪問頻率和授權(quán)要求這里不指向任何具體站點示例僅僅演示寫法import urllib.request def fetch_real(url: str) - int: with urllib.request.urlopen(url, timeout10) as resp: body resp.read() return len(body)然后用 ThreadPoolExecutor.map 批量請求邏輯和上面的 sleep 示例一樣。真實場景里還會涉及連接復(fù)用、超時控制、重試策略、限速等這些屬于并發(fā)工程的延伸問題。核心結(jié)論不變只要任務(wù)大部分時間在等待外部資源多線程就值得用。6. 換多進程后要小心的四個細節(jié)多進程雖然能繞開 GIL但它不是免費的補丁。項目里把多線程直接改成多進程往往會遇到新問題。6.1 進程創(chuàng)建與入口保護multiprocessing 和 ProcessPoolExecutor 在 Windows 上會以 spawn 方式啟動新進程子進程要重新導(dǎo)入主模塊。如果主模塊頂層直接執(zhí)行了創(chuàng)建進程池的代碼就會遞歸創(chuàng)建進程最后報錯或卡死。解決方法是把啟動邏輯放進 ifname main: 保護塊。即使你的代碼只跑在 Linux也建議養(yǎng)成這個習慣因為框架、打包工具和不同平臺的部署方式會讓問題隱性出現(xiàn)。6.2 傳參數(shù)必須可以被 pickle多進程傳參時任務(wù)函數(shù)和參數(shù)都需要被序列化。模塊級函數(shù)、基本類型、普通自定義類通常沒問題但 lambda、局部函數(shù)、鎖對象、文件句柄這類東西不能直接傳給子進程。遇到 EOFError 或者 pickle 相關(guān)報錯時優(yōu)先檢查傳進去的對象類型。如果業(yè)務(wù)上必須傳大對象比如一個很大的 DataFrame不要直接傳可以先保存成文件子進程讀取文件路徑這樣可以避免巨額序列化開銷。6.3 進程間通信要換思路多線程共享同一個進程內(nèi)存多線程操作同一個 list、dict 很方便。多進程里每個進程有獨立內(nèi)存空間不能直接共享復(fù)雜數(shù)據(jù)結(jié)構(gòu)?；A(chǔ)做法有三種multiprocessing.Queue 用于傳遞任務(wù)結(jié)果Pipe 適合兩個進程之間通信Value 和 Array 適合簡單的共享數(shù)值。再復(fù)雜的數(shù)據(jù)共享可以使用 multiprocessing.Manager 或 shared_memory但都要付出同步或序列化成本。設(shè)計多進程任務(wù)時盡量把數(shù)據(jù)流設(shè)計成“輸入?yún)?shù)進輸出結(jié)果回”避免頻繁雙向通信。6.4 進程數(shù)量不等于越多越好邏輯核數(shù)來自 os.cpu_count()但超線程會讓這個數(shù)字翻倍。進程數(shù)開太多會被 CPU 調(diào)度和內(nèi)存帶寬限制收益不再線性增長反而可能出現(xiàn)性能回退。通常的做法是先按物理核數(shù)或邏輯核數(shù)的一半設(shè)置初始值再根據(jù)實際 CPU 占用折線圖調(diào)整。另外每個子進程都有獨立的 Python 解釋器和內(nèi)存空間進程數(shù)量開大會讓內(nèi)存占用成倍增長內(nèi)存不夠時很容易觸發(fā)交換分區(qū)性能反而更差。7. 資源占用與性能觀察方法很多時候不需要復(fù)雜的 profiler只看系統(tǒng)自帶的資源監(jiān)視器就能判斷是不是 GIL 問題。Windows 用戶打開任務(wù)管理器切到性能標簽頁把 CPU 視圖改成“邏輯處理器”運行任務(wù)時能直接看到每個核的占用曲線。如果只是個別核跑高總占用很低說明并行沒有真正發(fā)生。macOS 用戶用活動監(jiān)視器的 CPU 歷史窗口也可以看到每個邏輯核的活動。Linux 用戶最方便的方式是 htop按 1 鍵展開每個核的占用條。如果想在代碼里記錄 CPU 占用可以安裝 psutilpip install psutil然后采樣當前每個邏輯核的占用率import time import psutil while True: per_cpu psutil.cpu_percent(interval1, percpuTrue) print(per_cpu) time.sleep(1)跑這個采樣腳本再并行執(zhí)行前面的 gil_demo.py對比現(xiàn)象更直觀。多進程實驗運行時你應(yīng)該能看到大部分核的占用被拉高。多線程實驗運行時占用率曲線會集中在少數(shù)核上而且整體曲線波動明顯。需要留意的還有一個指標內(nèi)存。多進程實驗如果開 8 個進程每個進程都要加載解釋器和任務(wù)依賴內(nèi)存占用可能比多線程高好幾倍。做批量任務(wù)時要同時觀察內(nèi)存和 CPU不要只看其中一個。用 psutil 可以統(tǒng)計當前進程樹的總內(nèi)存import os import psutil def current_memory_mb() - float: proc psutil.Process(os.getpid()) return proc.memory_info().rss / 1024 / 10248. 常見問題與排查方法下面這份表格基本覆蓋了從“線程沒跑滿”到“進程池報錯”的高頻問題。遇到問題先對號入座能省不少排查時間。問題現(xiàn)象可能原因排查方式解決方案線程數(shù)量和核數(shù)相同CPU 占用仍不是 N 倍純 Python CPU 密集任務(wù)受 GIL 限制打開任務(wù)管理器或 htop 看各核占用CPU 密集改用多進程多進程代碼運行報 EOFError 或窗口反復(fù)啟動Windows 下缺少入口保護檢查子進程是否重復(fù)導(dǎo)入主模塊把進程池代碼放進 ifname mainProcessPoolExecutor 報無法 pickle傳給子進程的是 lambda、局部函數(shù)或不可序列化對象定位傳參對象類型改用模塊級函數(shù)只傳可序列化參數(shù)多進程明顯變慢每個任務(wù)傳入數(shù)據(jù)量太大序列化開銷過高對比傳大對象和傳文件路徑的耗時使用文件路徑、數(shù)據(jù)庫 ID 或共享內(nèi)存子進程打印信息混亂多進程共享標準輸出的緩沖行為不同觀察打印順序和內(nèi)容加 flushTrue或改為寫日志文件多線程在 I/O 密集任務(wù)中也沒有提升線程數(shù)過高導(dǎo)致上下文切換或存在資源爭用嘗試不同線程數(shù)做壓測適當限制并發(fā)使用連接池復(fù)用資源共享變量出現(xiàn)臟數(shù)據(jù)錯誤地認為 GIL 可以保護業(yè)務(wù)代碼檢查變量更新是否為多步操作使用 threading.Lock 或改用不可變數(shù)據(jù)內(nèi)存快速增長后自動退出子進程數(shù)量過多內(nèi)存翻倍觀察任務(wù)峰值內(nèi)存降低進程數(shù)分批處理任務(wù)最后一個值得單獨強調(diào)的問題不要因為 Python 有 GIL就把“原子性”理解成“事務(wù)性”。GIL 保證的只是解釋器每次執(zhí)行一個字節(jié)碼期間內(nèi)存管理安全不等于你的兩條 Python 語句之間不會被其他線程插入。比如一個計數(shù)器自增操作在字節(jié)碼層面不是單條指令多線程同時執(zhí)行時不加鎖依然會丟計數(shù)。GIL 不能替代業(yè)務(wù)鎖。9. 最佳實踐與使用建議到這里GIL 對多線程的限制已經(jīng)清楚了。最后給出一套可以直接落到代碼里的工程建議。第一先跑最小基線。在任何并發(fā)優(yōu)化之前先用單線程版本跑一遍任務(wù)記錄耗時間和 CPU 占用。沒有基線后面很難判斷多線程、多進程到底有沒有收益。第二按任務(wù)類型選并發(fā)模型。任務(wù)大部分時間在等待網(wǎng)絡(luò)、磁盤、數(shù)據(jù)庫用 ThreadPoolExecutor 或 asyncio任務(wù)大部分時間在做純 Python 計算用 ProcessPoolExecutor 或 multiprocessing任務(wù)兩者都有先按粗粒度切分成多進程進程內(nèi)部再用多線程做 I/O。不要一上來就上進程池也不要因為 GIL 存在就不用線程。第三并發(fā)代碼要加日志和錯誤隔離。批量任務(wù)尤其重要。把每個子任務(wù)的輸入、輸出、異常都記錄下來任務(wù)失敗時先重試再進入死信隊列。很多線上問題不是并發(fā)模型錯了而是沒有日志失敗任務(wù)把整個隊列堵住。第四接口服務(wù)和 UI 類項目要特別關(guān)注資源限制。多進程會成倍占用內(nèi)存如果是帶界面的 Python 應(yīng)用或者 Web 服務(wù)里直接開大量進程要設(shè)計好進程池上限。如果你在 ComfyUI 這類工具里做節(jié)點批量處理看到的“任務(wù)并行”往往更多是調(diào)度和 I/O 等待帶來的效果不是 Python 線程在做多核計算兩者不要搞混。第五數(shù)據(jù)請求要合法合規(guī)。用多線程寫爬蟲或者批量調(diào)用第三方接口時確認目標服務(wù)是否允許這種頻率的訪問遵守對方的使用條款和 robots 規(guī)范。涉及用戶數(shù)據(jù)、版權(quán)內(nèi)容務(wù)必獲得明確授權(quán)。講完這些回到標題的問題4 個線程跑不滿 4 個核是 GIL 限制了純 Python 字節(jié)碼在同一進程內(nèi)的并行執(zhí)行。想利用多核CPU 密集任務(wù)就該換多進程但換之前先確認任務(wù)真的是 CPU 密集而不是被隱藏的 I/O 拖慢了。建議收藏備用。把 gil_demo.py 跑一遍記錄本機的基線和 CPU 占用曲線后面做并發(fā)選型時這就是你的第一手判斷依據(jù)。下一步可以繼續(xù)看兩個方向如果你是網(wǎng)絡(luò)請求和爬蟲為主往 asyncio 和任務(wù)隊列方向深入如果你是計算和數(shù)據(jù)處理為主研究 multiprocessing 的數(shù)據(jù)分發(fā)策略和共享內(nèi)存。