1. 一切要從“程序卡住”說起你在某個業(yè)務系統(tǒng)里寫過這樣一個功能批量拉取幾百家上游接口的數(shù)據(jù)然后逐條清洗入庫。第一次跑的時候你發(fā)現(xiàn)整個過程要花四十多分鐘而真正在“計算”的時間其實不到一半絕大部分時間都耗在了等待網(wǎng)絡響應上。于是你自然會想能不能讓多個請求同時發(fā)出去而不是一個個排隊等這個念頭就是并發(fā)編程最初的火花。我自己第一次感覺到該學并發(fā)編程也是在類似的場景。當時接手一個數(shù)據(jù)同步模塊每天凌晨抓取外部數(shù)據(jù)任務隊列一長運行時間直奔兩個小時。一開始我以為是網(wǎng)速問題后來加了日志才發(fā)現(xiàn)CPU使用率一直只有5%左右。換句話說整個機器大部分時間在“發(fā)呆”程序卻在按部就班地排隊。那不是機器慢是程序設計導致資源的巨大浪費。這篇博文不教某個語言的API也不帶你速成某個框架而是把并發(fā)編程的底子梳理一遍進程、線程、并發(fā)、并行、臨界區(qū)、鎖、調(diào)度、上下文切換一個個講清楚。無論你用Go、Java、Python還是C這些概念都是通用的是你判斷“并發(fā)方案該怎么設計”的地基。適合剛?cè)腴T并發(fā)編程的開發(fā)者也適合寫過一些多線程代碼但總覺得“差點意思”的人。再退一步說就算你現(xiàn)在主要寫業(yè)務邏輯理解這些概念也能幫你更早發(fā)現(xiàn)并發(fā)bug而不是等上線后讓它在生產(chǎn)環(huán)境教做人。2. 先分清臺前演員進程、線程與協(xié)程2.1 進程資源容器也是隔離邊界進程是操作系統(tǒng)進行資源分配的最小單位。這句話背下來很容易真正理解它需要想清楚“資源”包括什么內(nèi)存地址空間、文件描述符、環(huán)境變量、信號處理、線程列表……基本上一個正在運行的程序所擁有的家當都會被操作系統(tǒng)登記在一個叫做“進程控制塊”的結(jié)構(gòu)里。進程之間默認是互相隔離的。一個進程崩潰一般不會直接拖垮另一個進程。A進程里把內(nèi)存寫爛了錯誤也在A自己的地址空間里操作系統(tǒng)順手就把A終結(jié)了其他進程照常運行。這種隔離既是好處也是代價。好處是穩(wěn)定安全代價是進程間通信成本極高?？邕M程傳遞數(shù)據(jù)得走管道、消息隊列、共享內(nèi)存、套接字這些IPC機制每一樣都伴隨著數(shù)據(jù)的拷貝或者系統(tǒng)調(diào)用性能遠比不上同進程內(nèi)線程間的數(shù)據(jù)共享。在并發(fā)編程里進程通常不是我們“造并發(fā)”的第一選擇但它定義了“隔離”與“穩(wěn)定”的邊界。你在設計一個系統(tǒng)時如果不同模塊之間需要很強的故障隔離才考慮拆成多進程。2.2 線程真正干活的最小單位線程是CPU調(diào)度的最小單位。比進程更“輕”因為同一個進程內(nèi)的多個線程共享進程的資源同一塊堆內(nèi)存、同一個文件描述符表、同一種全局狀態(tài)。線程自己只保留一小塊獨立的?？臻g以及寄存器上下文。正因為共享內(nèi)存線程之間的數(shù)據(jù)交換變得特別簡單。你定義一個全局變量所有線程都能訪問不需要管道也不需要消息隊列。但也正因為共享麻煩事來了兩個線程同時改同一個變量結(jié)果可能錯亂。第三章和第五章會重點展開這部分。從模型上看一個進程至少有一個線程也可以有很多線程。線程由操作系統(tǒng)內(nèi)核來調(diào)度創(chuàng)建和切換都需要陷入內(nèi)核態(tài)這也就決定了線程不可能無限多——后面講上下文切換的時候你就能直觀感受到它的成本。2.3 協(xié)程用戶態(tài)里的“輕量級線程”協(xié)程常被叫做“用戶態(tài)線程”。它和線程最大的區(qū)別是協(xié)程的調(diào)度不依賴操作系統(tǒng)內(nèi)核而是由應用程序自己控制。線程是被操作系統(tǒng)搶來搶去地調(diào)度搶占式協(xié)程則是代碼主動讓出執(zhí)行權(quán)協(xié)作式。你用協(xié)程寫并發(fā)本質(zhì)上是在一個線程里交替執(zhí)行多段邏輯。當前協(xié)程遇到I/O等待比如網(wǎng)絡請求發(fā)出去了就主動把執(zhí)行權(quán)交給另一個協(xié)程讓CPU繼續(xù)干別的。因為切換發(fā)生在用戶態(tài)不需要陷入內(nèi)核所以協(xié)程切換的開銷比線程小一到兩個數(shù)量級。這也是“高并發(fā)”服務端廣泛采用協(xié)程的根本原因。大量請求同時進來如果為每個請求建一個線程線程數(shù)一多光切來切去系統(tǒng)就累垮了改用協(xié)程一個線程里可以掛著成千上萬個“輕量任務”I/O等待時自動讓位性能提升非常明顯。不過協(xié)程也有挑剔的地方如果代碼里某個操作是純CPU密集且不讓出那其他協(xié)程就只能干等著。協(xié)作式調(diào)度信任每個協(xié)程“自覺”遇到阻塞點要主動讓位。這也讓協(xié)程調(diào)試比線程更隱蔽——出問題往往不是“數(shù)據(jù)競爭”而是“某個協(xié)程卡住了整個線程”。2.4 一張表看三者關(guān)系維度進程線程協(xié)程資源分配單位是獨立地址空間否共享進程資源否在線程內(nèi)部調(diào)度CPU調(diào)度單位否是否由用戶態(tài)調(diào)度創(chuàng)建/切換成本最高較高極低數(shù)據(jù)隔離強弱共享內(nèi)存同線程內(nèi)共享適用場景強故障隔離、多實例服務多核并行計算、I/O并行海量I/O并發(fā)、請求密集場景選型上我的經(jīng)驗是需要強隔離就上進程需要壓榨多核CPU就上線程需要扛住海量并發(fā)I/O就上協(xié)程。很多成熟的運行時已經(jīng)把協(xié)程封裝得很好了你甚至不需要關(guān)心底層細節(jié)但知道這些邊界會讓你在調(diào)優(yōu)時少走彎路。3. 并發(fā)與并行很多新手栽在這里的一字之差3.1 并發(fā)邏輯上同時物理上交替并發(fā)強調(diào)的是“能同時處理多個任務”的能力。哪怕你的機器只有一個CPU核也可以并發(fā)操作系統(tǒng)把CPU時間切成一段段讓任務A跑一下、任務B跑一下、任務C跑一下切換得足夠快你感知上好像它們同時在跑。用生活里的例子講一個服務員要給三桌客人上菜。他不可能同時出現(xiàn)在三張桌子邊但他可以這一秒給A桌上菜下一秒給B桌上菜三桌人看起來都得到了服務。這是并發(fā)——交替處理但同一時刻手上只有一件事。在并發(fā)模型里這是任務之間的“交錯執(zhí)行”。每個任務都被分割成極小的時間片操作系統(tǒng)負責在多個任務間快速切換。你寫的多線程代碼在單核CPU上運行就是典型的并發(fā)而不是并行。3.2 并行物理上真的同時并行是“同時執(zhí)行多個任務”要求CPU提供多核支持每個核在同一個時刻各干各的?；氐椒諉T例子餐廳新雇了三個服務員一個盯A桌一個盯B桌一個盯C桌三桌同時被服務。這是并行。并行天然包含并發(fā)的思想但反過來不成立并發(fā)只表明“有同時處理多任務的能力”不保證物理層面的同時執(zhí)行。一個并發(fā)程序放到單核機器上照樣能跑但一個并行程序如果只有單核那它最多只能是并發(fā)。程序員經(jīng)常在這兩個詞上翻車最典型的是面試和討論時你說“我的程序是并發(fā)的”對方問“那并行了嗎”這倆不是同義詞別混著用。3.3 為什么你寫的并發(fā)程序不一定并行很多人寫完多線程代碼發(fā)現(xiàn)跑起來并沒有更快甚至更慢。原因很扎心你只制造了并發(fā)沒有制造并行。一個程序要真正做到并行至少得滿足幾個條件機器有多核CPU任務能被拆分到多個線程各個線程之間沒有強依賴不需要頻繁等待彼此線程切來切去的額外開銷小于并行帶來的收益。如果你只是把任務塞給線程池但任務本身全是共享變量上的串行操作那這些線程要么在搶鎖要么在等鎖真正的“并行執(zhí)行”只是一個幻覺。我之前寫過一個統(tǒng)計程序數(shù)據(jù)按切片分給8個線程去處理但主線程要等所有子線程的結(jié)果匯總。子線程之間不爭搶資源時性能確實逼近線性加速可一旦我在某個共享計數(shù)器上加了鎖8個線程變成輪流搶一把鎖速度立刻掉到比單線程還難看。那次之后我深刻明白并行的收益取決于你能否減少爭用而不是單純增加線程數(shù)。3.4 常見并發(fā)模型對照模型核心思想代表場景主要風險多線程共享內(nèi)存線程通過共享變量通信桌面應用、傳統(tǒng)后端服務數(shù)據(jù)競爭、死鎖Actor模型每個實體獨立只靠消息傳遞分布式系統(tǒng)消息設計復雜事件循環(huán)單線程循環(huán)處理事件非阻塞I/O前端JS、高性能網(wǎng)絡服務回調(diào)地獄、CPU密集任務卡循環(huán)數(shù)據(jù)并行同一操作作用于大量數(shù)據(jù)的不同切片圖像處理、數(shù)值計算負載均衡難做流水線并行任務分成多階段階段間接力處理生產(chǎn)消費者模型各階段速度不匹配時瓶頸明顯選哪種模型不是看哪個“高大上”而是看任務特性。I/O密集型任務適合事件循環(huán)和協(xié)程CPU密集型任務適合多線程加數(shù)據(jù)并行任務間邊界清晰、需要擴展性強時Actor模型是個好思路。3.5 并發(fā)能力由什么決定決定一個系統(tǒng)并發(fā)能力的不只是線程數(shù)。瓶頸往往在三個地方CPU核心數(shù)決定你真正能做到多少并行。I/O等待時間決定有多少時間被白白浪費這也是并發(fā)優(yōu)化的主要空間。共享資源爭用鎖、隊列、數(shù)據(jù)庫連接等爭用越大并發(fā)收益越小。所以評估并發(fā)方案時先問自己這個任務到底是CPU密集還是I/O密集如果是I/O密集協(xié)程或異步I/O能帶來巨大收益如果是CPU密集要多核并行才有意義此時要小心鎖競爭和線程數(shù)如果兩者混雜那就要做混合設計這也是很多真實系統(tǒng)最復雜的地方。4. 底層機制調(diào)度器、上下文切換與臨界區(qū)4.1 調(diào)度器在忙什么時間片只是個幌子操作系統(tǒng)的調(diào)度器負責決定“下一個該誰上CPU”。它有很多調(diào)度算法常見的思路包括優(yōu)先級調(diào)度、時間片輪轉(zhuǎn)、多級反饋隊列。實際運行中每個線程并不會老老實實跑完整個時間片因為I/O等待、鎖阻塞、時鐘中斷都會打斷它。大多數(shù)通用操作系統(tǒng)采用搶占式調(diào)度內(nèi)核認為某個線程用CPU太久了直接剝奪它的執(zhí)行權(quán)交給另一個線程。這種設計讓系統(tǒng)響應更及時但也意味著你的線程什么時候被切走是不確定的。這種不確定性是并發(fā)bug最難查的根源之一——你在本地跑一百次都對到生產(chǎn)環(huán)境偶發(fā)一次錯大概率就是調(diào)度時序變了。調(diào)度還分“內(nèi)核線程”和“用戶線程”。很多語言運行時把用戶線程協(xié)程/綠色線程映射到內(nèi)核線程上例如多對一模型、一對一模型、多對多模型。一對一模型下每個用戶線程對應一個內(nèi)核線程利用多核方便但線程一多內(nèi)核資源就緊張多對多模型則更靈活由運行時負責在有限的內(nèi)核線程上調(diào)度海量用戶任務。4.2 上下文切換的成本比你想的高得多上下文切換就是暫停當前線程、保存它的狀態(tài)寄存器、程序計數(shù)器、棧指針等然后加載另一個線程的狀態(tài)繼續(xù)執(zhí)行。聽起來只是“保存和恢復”但這個動作一點都不廉價。它包含幾部分開銷保存/恢復CPU寄存器更新內(nèi)核棧和調(diào)度數(shù)據(jù)結(jié)構(gòu)CPU緩存被新線程的狀態(tài)污染后續(xù)訪問緩存的命中率下降涉及用戶態(tài)和內(nèi)核態(tài)之間的切換如果切換對象是不同進程的線程還會涉及地址空間的切換代價更高。實測經(jīng)驗一次線程上下文切換通常耗時在微秒量級看起來不多但如果你有1000個線程在瘋狂爭搶CPU每秒可能出現(xiàn)幾萬次切換這些開銷會直接吃掉一整個核心的計算能力。這解釋了為什么“線程越多越好”是錯的。當線程數(shù)超過CPU核數(shù)太多時每個線程分到的時間片短切換開銷占比高整體吞吐量不升反降。我見過一個項目為了追求“并發(fā)量”把線程池調(diào)到500個結(jié)果監(jiān)控面板顯示系統(tǒng)CPU大量消耗在切換上業(yè)務進度反而比50個線程時更慢。后來把線程壓到與核心數(shù)相仿加上I/O等待時的主動讓位性能立刻回升。4.3 競態(tài)條件并發(fā)bug的源頭競態(tài)條件指的是程序的結(jié)果依賴于多個線程的執(zhí)行順序而這個順序又無法被保證。換句話說同樣的輸入每次運行的輸出可能不同。一個最簡單的例證兩個線程同時對共享變量count執(zhí)行“讀-加-寫”操作。假設初始值是0兩個線程都讀到了0各自加1后都寫回1最終結(jié)果是1雖然邏輯上應該是2。問題出在“讀-加-寫”這三步不是一個不可分割的原子操作線程A讀到0后可能被切走線程B也讀到0兩者互相覆蓋。這種bug致命的點是它不會每次都觸發(fā)可能跑幾千次才出現(xiàn)一次。你很難復現(xiàn)也很難定位。真實項目里競態(tài)往往和某種微妙的調(diào)度條件綁定比如恰好某個線程先跑了一小段時間、恰好內(nèi)存屏障沒生效、恰好兩個請求同時到達。它是并發(fā)編程里最典型的“隱形殺手”。4.4 臨界區(qū)與不可分割操作要解決競態(tài)核心是讓“讀-加-寫”這種復合操作變成不可分割的整體。這個不可分割執(zhí)行的區(qū)域就叫臨界區(qū)。進入臨界區(qū)之前線程需要獲取某種機制保護自己最常見的是鎖出了臨界區(qū)再釋放鎖確保同一時刻只有一個線程能執(zhí)行這段代碼。這樣即使線程在臨界區(qū)內(nèi)被切走其他線程也進不來必須等它把整個操作做完。這里有個容易被忽略的點臨界區(qū)必須覆蓋完整的關(guān)鍵操作序列既不能“缺斤少兩”也不應隨意擴大范圍。臨界區(qū)太小保護不全競態(tài)依然存在臨界區(qū)太大其他線程等著的時間變長并發(fā)性能大打折扣。劃定合適的臨界區(qū)邊界是并發(fā)編程的基本功也是性能調(diào)優(yōu)的重要發(fā)力點。比如更新共享計數(shù)器完整操作是“讀舊值、加增量、寫回”。你只給“加增量”那一步加鎖鎖等于白加你把從用戶提交請求到所有后續(xù)處理都鎖上那就成了串行程序。正確的做法是把“讀-加-寫”作為一個臨界區(qū)范圍盡量小。5. 并發(fā)控制工具箱鎖、原子操作、等待通知5.1 互斥鎖最樸素也最可靠的方案互斥鎖Mutex是最基礎(chǔ)的同步原語。它保證任何時刻最多只有一個線程能持有鎖。線程在進入臨界區(qū)前調(diào)用加鎖操作離開時調(diào)用解鎖操作。如果鎖已經(jīng)被其他線程持有后來的線程就會阻塞等待直到鎖被釋放。用互斥鎖要注意兩點第一加鎖和釋放必須成對出現(xiàn)異?；蛱崆胺祷貢r也要釋放鎖否則其他線程會永久阻塞。現(xiàn)代語言提供了try-with-resources、RAII、defer之類的機制來避免手動釋放的遺漏能用的盡量用。第二不要在持鎖期間調(diào)用可能長時間阻塞的操作比如網(wǎng)絡請求、等待用戶輸入。這會讓所有線程都堵在一個鎖上系統(tǒng)吞吐量瞬間歸零。5.2 讀寫鎖讀多寫少場景的優(yōu)化讀寫鎖把“讀”和“寫”分開對待。多個線程可以同時持有讀鎖但寫鎖是排他的持有寫鎖時其他線程既不能讀也不能寫。這樣設計是因為“純讀取共享數(shù)據(jù)”是安全的大家讀同一個值不會互相破壞。適用場景很典型配置表、路由表、詞庫等“讀多寫少”的數(shù)據(jù)結(jié)構(gòu)。假如用普通互斥鎖所有讀線程都必須串行白白浪費并發(fā)能力。換成讀寫鎖讀線程可以并行只有偶爾的更新才需要獨占寫鎖。但別天真地以為讀寫鎖一定更快。如果寫操作非常頻繁寫鎖經(jīng)常被持有讀線程也頻繁等待加上讀寫鎖本身的維護開銷可能比普通互斥鎖還慢。選讀寫鎖前先估一估讀寫比例經(jīng)驗上讀遠多于寫比如10:1以上才劃算。5.3 自旋鎖等著比切換更劃算自旋鎖的特點是線程拿不到鎖不進入阻塞而是原地循環(huán)“轉(zhuǎn)圈”持續(xù)嘗試獲取鎖直到拿到為止。因為線程沒有睡過去省去了上下文切換的開銷但代價是它占用著CPU空轉(zhuǎn)什么正事也不干。自旋鎖適合臨界區(qū)特別短、且鎖被持有的平均時間極短的場景。比如你要保護一個只有幾條指令的變量更新持鎖時間通常只有幾十納秒此時用互斥鎖光是切換線程的成本就超過了自旋空轉(zhuǎn)的成本自旋鎖反而更高效。實際使用時要小心如果臨界區(qū)較長或者多個線程競爭激烈自旋鎖會讓CPU浪費大量時間在空轉(zhuǎn)上。Linux內(nèi)核里就大量使用自旋鎖保護短臨界區(qū)但它在臨界區(qū)不允許睡眠。你寫用戶態(tài)代碼時下意識用互斥鎖通常更穩(wěn)妥只有確認臨界區(qū)極短且經(jīng)過性能測試后再換成自旋。5.4 原子操作無鎖的基石如果把“讀-加-寫”這種復合操作用一條特殊的CPU指令直接完成就不需要鎖了。這類由硬件提供支持、執(zhí)行過程中不可中斷的操作稱為原子操作。比如compare-and-swapCAS、fetch-and-add、load-link/store-conditional。CAS是最有代表性的一個它把“比較-交換”做成原子操作。線程讀取內(nèi)存值預期它是某個舊值如果是就寫入新值如果不是說明別人改過了那就重新讀取再試。這也就是所謂“無鎖編程”的基礎(chǔ)。無鎖意味著線程不會被阻塞但代價是編碼復雜度和調(diào)試難度遠高于加鎖版本。高性能場景中某些關(guān)鍵路徑用原子操作替代鎖可以顯著減少爭用。比如統(tǒng)計請求計數(shù)用原子自增就比每次加鎖輕量得多。一個非常經(jīng)典的提醒原子操作保護的是“單條指令”的原子性不是你業(yè)務邏輯的原子性。你用它解決計數(shù)器問題沒問題用CAS去模擬一個多步驟的業(yè)務事務就很容易出錯因為批處理中間時刻狀態(tài)的一致性需要額外手段保證。5.5 等待通知與條件變量很多時候線程要做的事情依賴某個“條件”成立。比如生產(chǎn)者線程往隊列里放數(shù)據(jù)消費者線程只有在隊列非空時才能取數(shù)據(jù)。如果消費者發(fā)現(xiàn)隊列為空它有兩種選擇一直問“有數(shù)據(jù)了嗎”忙等待或者睡過去等生產(chǎn)者通知它“有數(shù)據(jù)了”再醒來。條件變量就是為第二種方案設計的。它通常配合互斥鎖使用線程在循環(huán)中檢查條件不滿足就調(diào)用等待接口同時釋放鎖另外的線程修改條件后調(diào)用通知接口喚醒等待線程。這里有個新手容易犯的錯條件變量存在“虛假喚醒”線程被喚醒后條件可能還是不滿足所以必須在循環(huán)里重新檢查條件而不是用簡單的if判斷。規(guī)范寫法是# 偽代碼生產(chǎn)者消費者模型中的消費者 while queue.empty(): condition_var.wait() data queue.pop()這個while就是防止虛假喚醒以及多線程同時被喚醒時“搶不到數(shù)據(jù)”的保障。寫完代碼后檢查自己是否用的是while而不是if這個小細節(jié)能幫你躲開線上偶發(fā)的空隊列異常。6. 實踐中的四個大坑死鎖、活鎖、過量線程與偽共享6.1 死鎖互相等對方的鑰匙死鎖最經(jīng)典的定義一組線程中每個成員都在等待其他成員占用的資源沒人釋放全部永久卡死。舉個例子線程A先鎖lock1再鎖lock2線程B先鎖lock2再鎖lock1。如果A拿到lock1后、還沒拿到lock2時B恰好拿到了lock2接下來A等B釋放lock2B等A釋放lock1兩個線程永遠等下去。避免死鎖最實用的原則有兩條按固定順序加鎖。所有線程都按lock1再到lock2的順序獲取鎖就不會出現(xiàn)環(huán)路等待。加鎖設置超時。拿不到鎖在一定時間內(nèi)放棄釋放已持有的鎖重試或有條件地失敗退出。實際排查死鎖時多數(shù)語言的線程Dump工具能幫你看到每個線程等待的鎖以及持有它的線程是誰?？吹健皟蓚€線程互相等待彼此持有的鎖”這個環(huán)死鎖所在的位置基本就鎖定了。6.2 活鎖與饑餓讓線程“吃不上飯”的另一種方式活鎖的情況是線程并沒有阻塞而是在不停地響應另一個線程并讓出自己的執(zhí)行機會結(jié)果大家互相謙讓誰也無法前進。比如兩個并行任務在走廊相遇都想給對方讓路結(jié)果你閃到左邊我也閃到左邊你閃到右邊我也閃到右邊反復閃躲始終走不過去。活鎖比死鎖更難發(fā)現(xiàn)因為程序看起來還在“跑”只是沒有實際進展。解決思路通常是引入隨機退避或者固定優(yōu)先級讓一方先走打破僵局。饑餓則是某些線程遲遲得不到CPU時間或鎖資源雖然最終可能執(zhí)行但等待時間遠超合理范圍。常見原因是鎖的公平性設計不公平——高優(yōu)先級線程反復搶占低優(yōu)先級線程的資源導致低優(yōu)先級線程長期得不到執(zhí)行。使用公平鎖能緩解部分饑餓問題但公平鎖本身也有額外成本要結(jié)合實際場景權(quán)衡。6.3 線程不是越多越好上下文切換會吃掉性能很多人有個誤區(qū)并發(fā)能力線程數(shù)量。實際上線程太多時系統(tǒng)絕大部分時間在調(diào)度和切換真正干活的CPU時間被嚴重壓縮。經(jīng)驗公式可以參考CPU密集型任務線程數(shù)通常設置為CPU核心數(shù)的1到2倍左右I/O密集型任務可以多一些但也不能無限增加。更精細的做法是壓測找到“拐點”即線程數(shù)繼續(xù)增加但吞吐量不再上升甚至下降的點。我現(xiàn)在做服務端代碼時會開啟線程池的監(jiān)控指標觀察活躍線程數(shù)、隊列等待時長和任務耗時。一旦發(fā)現(xiàn)活躍線程數(shù)長期接近上限且任務耗時激增第一個懷疑對象就是線程數(shù)配多導致的切換開銷而不是業(yè)務代碼變慢了。6.4 偽共享一個詭異的性能黑洞偽共享是并發(fā)性能優(yōu)化中一個不那么直觀的坑。它的原理涉及CPU緩存CPU不是按單個變量去緩存數(shù)據(jù)而是按“緩存行”為單位常見大小是64字節(jié)。如果兩個線程需要頻繁訪問兩個不同的變量但這兩個變量恰好落在同一條緩存行上CPU為了保證緩存一致性會把這整條緩存行在多個核之間反復同步。于是線程A修改變量X時線程B訪問變量Y也會被拖慢盡管兩者根本沒有共享任何數(shù)據(jù)。解決辦法很直接讓兩個變量盡量分布到不同的緩存行上。可以通過填充字節(jié)、按緩存行大小對齊等方式實現(xiàn)。高級語言里一些框架直接提供了“緩存行填充”的工具類或注解比如Java的Contended、Go手寫結(jié)構(gòu)體填充等。排查偽共享的典型現(xiàn)象是你用多個線程并行修改不同字段但性能上不去加鎖似乎也不是瓶頸CPU緩存命中率異常低。用性能分析工具查看各線程的緩存失效情況時如果發(fā)現(xiàn)大量cache line bouncing八九不離十就是偽共享。7. 一個實際案例從串行爬蟲到并發(fā)任務隊列7.1 場景和數(shù)據(jù)用上面這些概念我拆一個真實做過的例子批量抓取外部網(wǎng)頁并解析。當時要處理大約5000個URL每個請求的響應耗時約200到500毫秒解析耗時約50毫秒。機器配置是4核8線程。串行版本的處理時間很容易估算假設平均每任務300毫秒響應50毫秒解析5000個任務就是5000×350毫秒約1750秒接近半小時。CPU利用率不超過20%因為大部分時間都在等待網(wǎng)絡I/O。這種任務的特征非常典型I/O密集任務之間無共享狀態(tài)天然適合并發(fā)。唯一要注意的是不要對目標系統(tǒng)造成過大壓力以及控制并發(fā)上限。7.2 串行版本先寫一個串行的偽代碼作為基線for url in urls: html fetch(url) # 網(wǎng)絡I/O耗時200-500ms result parse(html) # CPU解析約50ms save(result)邏輯簡單到不能再簡單缺點是明顯的每次都要等網(wǎng)絡響應網(wǎng)絡等待期間CPU和系統(tǒng)資源完全空閑。這也正是并發(fā)優(yōu)化最大的切入點。7.3 多線程版本與性能變化我換了線程池方案設計了兩個參數(shù)線程數(shù)和任務分片大小。初始線程數(shù)取16用Python的ThreadPoolExecutor跑with ThreadPoolExecutor(max_workers16) as pool: results pool.map(process_one, urls)運行結(jié)果很直觀總耗時從約1750秒降到了約160秒提升約10倍。16個線程時已經(jīng)接近理論最優(yōu)值。因為網(wǎng)絡等待時間遠大于CPU解析時間線程數(shù)量大于核心數(shù)幾倍是合理的但如果繼續(xù)沖到64個線程總耗時不僅沒有明顯下降反而因為過度請求和調(diào)度開銷出現(xiàn)延遲波動、對方服務器限流的問題。這個對比告訴我們一個道理并發(fā)收益跟線程數(shù)的關(guān)系是倒U形的前期增長明顯中途趨于平緩過了某個點開始惡化。找到那個拐點通常要靠實測而不是拍腦袋。7.4 問題定位與最終優(yōu)化跑完多線程版本后我遇到了一個經(jīng)典問題部分請求超時。我一開始以為是網(wǎng)絡波動后來看了監(jiān)控才發(fā)現(xiàn)線程數(shù)拉高到64時短時間內(nèi)的并發(fā)請求量太大觸發(fā)了對方接口的限流。這說明并發(fā)編程不只是“跑得快”還要尊重下游系統(tǒng)的承載能力。最終優(yōu)化方案包含三塊使用信號量限制最大并發(fā)數(shù)比如固定為20增加失敗重試和指數(shù)退避退避時間從1秒開始每次翻倍最多重試3次處理完一批再拉下一批而不是一次性把5000個任務全塞進去。優(yōu)化后總耗時回升到約180秒但系統(tǒng)穩(wěn)定性大幅提升整個批次沒有出現(xiàn)任務失敗CPU和內(nèi)存占用也都保持在合理范圍。7.5 我的體會和幾個可復用的建議在多個項目里用過并發(fā)之后我總結(jié)了幾條可以復用的經(jīng)驗送給剛?cè)腴T的同學。第一個先搞清楚任務是I/O密集還是CPU密集。這直接決定了線程模型和線程數(shù)量的選擇也是并發(fā)設計的分水嶺。第二個并發(fā)代碼一定要加“限流閥”。不管線程池多大都要通過信號量或者隊列長度限制同時進行中的任務數(shù)量。無限并發(fā)是生產(chǎn)事故的溫床。第三個能共享數(shù)據(jù)盡量少共享不能少共享就老老實實加鎖。很多并發(fā)bug最終都繞不開共享可變狀態(tài)。換一個角度思考——如果能把數(shù)據(jù)設計成不可變的、或者按線程隔離一切問題從根上消失比任何高級同步原語都可靠。第四個性能調(diào)優(yōu)時先用監(jiān)控數(shù)據(jù)說話。CPU使用率、線程切換次數(shù)、鎖等待時間、任務隊列深度這幾個指標能真實反映你的并發(fā)設計是否健康。沒有數(shù)據(jù)支撐的“感覺優(yōu)化”最后多半靠運氣。這篇內(nèi)容偏基礎(chǔ)但如果能把進程線程、并發(fā)并行、臨界區(qū)、鎖、死鎖這些概念的底層關(guān)系理清楚后續(xù)學任何語言的多線程API、任何并發(fā)框架都會順很多。