教程：深入理解 Sender 與 Receiver——Rust mpsc 通道的端到端實(shí)踐)
Comprehensive Rust 并發(fā)教程深入理解 Sender 與 Receiver——Rust mpsc 通道的端到端實(shí)踐【免費(fèi)下載鏈接】comprehensive-rustThis is the Rust course used by the Android team at Google. It provides you the material to quickly teach Rust.項(xiàng)目地址: https://gitcode.com/GitHub_Trending/co/comprehensive-rust本篇文章基于 Google Android 團(tuán)隊(duì)維護(hù)的 Rust 課程 comprehensive-rust 中「Senders and Receivers」一節(jié)展開(kāi)。它以 9 分鐘的授課篇幅講解了 Rust 標(biāo)準(zhǔn)庫(kù)std::sync::mpsc通道最核心的兩個(gè)端點(diǎn)SenderT與ReceiverT如何創(chuàng)建通道、如何發(fā)送與接收消息、多生產(chǎn)者單消費(fèi)者的語(yǔ)義以及通道關(guān)閉與Result錯(cuò)誤處理。讀完本文你將掌握 mpsc 通道的完整使用模式并能看懂課程倉(cāng)庫(kù)中「哲學(xué)家就餐」與「鏈接檢查器」兩個(gè)實(shí)戰(zhàn)練習(xí)里通道的真實(shí)用法。一、通道的兩個(gè)端點(diǎn)Sender 與 Receiver在 Rust 中通道channel是一種線程間傳遞消息message passing的同步原語(yǔ)。與共享內(nèi)存加鎖的方式不同通道讓數(shù)據(jù)通過(guò)管道流動(dòng)發(fā)送方把值放進(jìn)去接收方按順序取出來(lái)兩端無(wú)需直接接觸彼此的數(shù)據(jù)。Rust 的通道由兩部分組成SenderT發(fā)送端點(diǎn)把類(lèi)型為T(mén)的值送入通道ReceiverT接收端點(diǎn)從通道中取出T類(lèi)型的值。兩者通過(guò)內(nèi)部的通道連接在一起但對(duì)使用者而言你只能看到這兩個(gè)端點(diǎn)——通道本身是不可見(jiàn)的。發(fā)送方只能往里放接收方只能往外取這種隔離正是消息傳遞模型安全性的來(lái)源數(shù)據(jù)的所有權(quán)在端點(diǎn)之間轉(zhuǎn)移而不是被多個(gè)線程同時(shí)借用。二、最小可用示例創(chuàng)建通道、發(fā)送與接收課程給出了一個(gè)完整可運(yùn)行的示例直接演示了通道的創(chuàng)建、發(fā)送、接收與多生產(chǎn)者克隆use std::sync::mpsc; fn main() { let (tx, rx) mpsc::channel(); tx.send(10).unwrap(); tx.send(20).unwrap(); println!(Received: {:?}, rx.recv()); println!(Received: {:?}, rx.recv()); let tx2 tx.clone(); tx2.send(30).unwrap(); println!(Received: {:?}, rx.recv()); }逐行拆解這段代碼let (tx, rx) mpsc::channel();調(diào)用mpsc::channel()一次性返回一對(duì)端點(diǎn)(Sender, Receiver)。此處T由后續(xù)send的消息類(lèi)型推斷為i32因此實(shí)際類(lèi)型為Senderi32與Receiveri32。整個(gè)示例沒(méi)有顯式創(chuàng)建線程main線程既是生產(chǎn)者又是消費(fèi)者這便于先理解 API 本身再過(guò)渡到多線程場(chǎng)景。tx.send(10).unwrap();/tx.send(20).unwrap();通過(guò)Sender連續(xù)發(fā)送兩條消息。兩次rx.recv()按發(fā)送順序先進(jìn)先出接收消息。recv()返回的是ResultDebug格式化{:?}會(huì)打印出Ok(10)、Ok(20)。let tx2 tx.clone();克隆發(fā)送端點(diǎn)得到第二個(gè)生產(chǎn)者。此時(shí)通道中共有tx、tx2兩個(gè)發(fā)送端點(diǎn)但接收端rx仍只有一個(gè)。tx2.send(30).unwrap();從克隆出的第二個(gè)發(fā)送端發(fā)送第三條消息rx.recv()依然能收到Ok(30)。程序最終輸出Received: Ok(10) Received: Ok(20) Received: Ok(30)注意Sender是按值move語(yǔ)義發(fā)送消息的——send(10)會(huì)把10的所有權(quán)移交進(jìn)通道發(fā)送后原變量不再可用而recv()接收時(shí)則把消息的所有權(quán)從通道移交給接收方。三、mpsc 的含義多生產(chǎn)者單消費(fèi)者mpsc是Multi-Producer, Single-Consumer的縮寫(xiě)即多生產(chǎn)者、單消費(fèi)者這是理解 Rust 標(biāo)準(zhǔn)庫(kù)通道設(shè)計(jì)的關(guān)鍵多生產(chǎn)者Sender和SyncSender都實(shí)現(xiàn)了Clone。你可以通過(guò)克隆任意多個(gè)發(fā)送端讓多個(gè)線程同時(shí)向同一個(gè)通道投遞消息它們彼此共享同一個(gè)接收端。上面示例中的tx.clone()正是多生產(chǎn)者能力的直接體現(xiàn)。單消費(fèi)者Receiver不實(shí)現(xiàn)Clone每個(gè)通道只有一個(gè)接收端。這保證了所有消息以確定性的順序被唯一一個(gè)消費(fèi)者取出避免了多消費(fèi)者競(jìng)爭(zhēng)分配消息的復(fù)雜度。這個(gè)多對(duì)一的不對(duì)稱(chēng)設(shè)計(jì)使 mpsc 天然適合任務(wù)分發(fā) 單點(diǎn)匯總的經(jīng)典模式多個(gè)工作線程把計(jì)算結(jié)果發(fā)往同一個(gè)收集端。四、send 與 recv 的 Result通道關(guān)閉即錯(cuò)誤send()和recv()的返回值都是Result這是一個(gè)容易被初學(xué)者忽略、但極其重要的細(xì)節(jié)如果send()返回Err意味著對(duì)端的Receiver已被 drop通道已經(jīng)關(guān)閉消息無(wú)法送達(dá)如果recv()返回Err意味著所有Sender包括所有克隆體都已被 drop通道已關(guān)閉不會(huì)再有任何消息到來(lái)。通道的關(guān)閉不是顯式操作而是由端點(diǎn)生命周期自動(dòng)驅(qū)動(dòng)的當(dāng)某一側(cè)的端點(diǎn)全部被 drop 時(shí)通道即宣告關(guān)閉。正因?yàn)榉祷刂凳荝esult課程示例中一律使用.unwrap()簡(jiǎn)化處理而生產(chǎn)代碼中應(yīng)當(dāng)使用expect(...)提供上下文或通過(guò)match/?顯式處理通道提前關(guān)閉這一正常業(yè)務(wù)分支例如消費(fèi)者退出后生產(chǎn)者應(yīng)當(dāng)停止投遞。這一關(guān)閉語(yǔ)義在課程倉(cāng)庫(kù)的兄弟章節(jié)中有更完整的闡述在 無(wú)界通道章節(jié) 中明確send()在通道關(guān)閉時(shí)會(huì)以錯(cuò)誤中止這也是它返回Result的原因而通道在Receiver被 drop 時(shí)關(guān)閉在 有界通道章節(jié) 中補(bǔ)充與無(wú)界通道相同通道關(guān)閉時(shí)調(diào)用send()同樣會(huì)以錯(cuò)誤中止。五、通道的兩種形態(tài)無(wú)界與有界課程將通道劃分為兩種形態(tài)二者使用同一對(duì)Sender/Receiver端點(diǎn)差異在于緩沖與阻塞行為。先掌握mpsc::channel()無(wú)界、異步再看mpsc::sync_channel(n)有界、同步梯度非常清晰。5.1 無(wú)界通道m(xù)psc::channel()本節(jié)示例所用的mpsc::channel()創(chuàng)建的是無(wú)界且異步的通道通道會(huì)按需分配足夠的內(nèi)存來(lái)暫存所有待處理消息send()永遠(yuǎn)不會(huì)阻塞調(diào)用線程發(fā)送方可以持續(xù)投遞不必關(guān)心消費(fèi)者當(dāng)前的處理速度。無(wú)界通道章節(jié) 給出了多線程版本的完整示例子線程通過(guò)move閉包捕獲tx循環(huán)發(fā)送 10 條format!(Message {i})主線程sleep(100ms)后再通過(guò)for msg in rx消費(fèi)。Receiver實(shí)現(xiàn)了Iteratorfor循環(huán)會(huì)一直迭代到通道關(guān)閉即所有發(fā)送端被 drop為止——這是消費(fèi)通道消息最慣用的寫(xiě)法。5.2 有界通道m(xù)psc::sync_channel(n)若調(diào)用mpsc::sync_channel(3)則得到有界同步通道此時(shí)send()的語(yǔ)義發(fā)生關(guān)鍵變化send()會(huì)阻塞當(dāng)前線程直到通道內(nèi)有空間容納新消息如果沒(méi)有任何消費(fèi)者讀取發(fā)送線程可能無(wú)限期阻塞容量為 0 的有界通道被稱(chēng)為rendezvous channel會(huì)合通道每次send()都會(huì)阻塞直到另一個(gè)線程調(diào)用recv()實(shí)現(xiàn)握手式同步傳遞。有界通道章節(jié) 的示例正是用sync_channel(3)演示了這一行為子線程發(fā)送第 4 條消息時(shí)被阻塞直到主線程從for msg in rx中消費(fèi)出空位才繼續(xù)。選擇建議無(wú)界通道實(shí)現(xiàn)簡(jiǎn)單、永不阻塞發(fā)送方但消息積壓可能耗盡內(nèi)存有界通道通過(guò)背壓backpressure天然限制積壓代價(jià)是發(fā)送方可能阻塞——需要結(jié)合具體場(chǎng)景權(quán)衡。六、源碼佐證mpsc 在課程練習(xí)中的真實(shí)應(yīng)用Sender/Receiver并非停留在理論層面課程倉(cāng)庫(kù)的多個(gè)練習(xí)都用它構(gòu)建了真實(shí)的并發(fā)程序可以直接作為參照實(shí)現(xiàn)閱讀。6.1 哲學(xué)家就餐用SyncSender匯總思想輸出在 哲學(xué)家就餐練習(xí) 的參考答案中每個(gè)哲學(xué)家線程并不直接println!自己的思想而是把想法發(fā)給通道use std::sync::{Arc, Mutex, mpsc}; use std::thread; struct Philosopher { name: String, left_chopstick: ArcMutexChopstick, right_chopstick: ArcMutexChopstick, thoughts: mpsc::SyncSenderString, }主線程創(chuàng)建mpsc::sync_channel(10)得到(tx, rx)5 個(gè)哲學(xué)家線程各自tx.clone()獲得自己的發(fā)送端多生產(chǎn)者的實(shí)戰(zhàn)體現(xiàn)tx本身在循環(huán)外被保留最后在主線程drop(tx)Philosopher::think中通過(guò)self.thoughts.send(...)投遞String主線程末尾drop(tx)后執(zhí)行for thought in rx把 5 個(gè)生產(chǎn)者產(chǎn)出的所有思想消息按序打印。這里的drop(tx)至關(guān)重要它關(guān)閉了主線程手中的發(fā)送端確保當(dāng)所有哲學(xué)家線程結(jié)束、最后一個(gè)發(fā)送端也 drop 后for thought in rx能自然結(jié)束迭代——這正是上一節(jié)通道關(guān)閉語(yǔ)義的實(shí)戰(zhàn)運(yùn)用。同時(shí)哲學(xué)家們通過(guò)ArcMutexChopstick共享筷子、通過(guò)通道傳遞消息展示了 Rust 兩種并發(fā)模型的互補(bǔ)。6.2 鏈接檢查器雙通道 ArcMutexReceiver鏈接檢查器練習(xí)的參考答案是一個(gè)更復(fù)雜的生產(chǎn)者-消費(fèi)者架構(gòu)同時(shí)使用了兩對(duì)通道let (result_sender, result_receiver) mpsc::channel::CrawlResult(); let (command_sender, command_receiver) mpsc::channel::CrawlCommand(); spawn_crawler_threads(command_receiver, result_sender, 16); control_crawl(start_url, command_sender, result_receiver)一對(duì)CrawlCommand通道控制端向 16 個(gè)爬蟲(chóng)線程下發(fā)抓取指令一對(duì)多分發(fā)一對(duì)CrawlResult通道16 個(gè)爬蟲(chóng)線程把結(jié)果回傳給控制端多對(duì)一匯總。這里有兩個(gè)值得注意的細(xì)節(jié)16 個(gè)爬蟲(chóng)線程需要共享同一個(gè)ReceiverCrawlCommand但Receiver不可Clone于是源碼用ArcMutexReceiverCrawlCommand包裹接收端來(lái)實(shí)現(xiàn)共享見(jiàn)spawn_crawler_threads中l(wèi)et command_receiver Arc::new(Mutex::new(command_receiver));這是單消費(fèi)者約束下多線程共享讀取的慣用折中方案所有爬蟲(chóng)線程各持有一個(gè)result_sender的克隆多個(gè)生產(chǎn)者并發(fā)向單一消費(fèi)者回傳結(jié)果正是 mpsc 命名含義的完整實(shí)踐。七、從同步通道到異步通道Sender/Receiver思想的延伸掌握標(biāo)準(zhǔn)庫(kù) mpsc 后課程在異步控制流章節(jié)中進(jìn)一步展示了tokio::sync::mpsc的用法接口與標(biāo)準(zhǔn)庫(kù)高度相似use tokio::sync::mpsc; async fn ping_handler(mut input: mpsc::Receiver()) { let mut count: usize 0; while let Some(_) input.recv().await { count 1; println!(Received {count} pings so far.); } } #[tokio::main] async fn main() { let (sender, receiver) mpsc::channel(32); let ping_handler_task tokio::spawn(ping_handler(receiver)); for i in 0..10 { sender.send(()).await.expect(Failed to send ping.); } drop(sender); ping_handler_task.await.expect(Something went wrong in ping handler task.); }關(guān)鍵差異在于tokio的通道是有界容量此處為 32send().await與recv().await都是異步的遇到緩沖區(qū)滿/空時(shí)掛起而不是阻塞線程并且可以與其他future組合出復(fù)雜控制流。正如課程所述總體接口與早間課程中看到的同步通道相似——把本節(jié)Sender/Receiver的思想遷移到 async 世界學(xué)習(xí)曲線會(huì)平緩很多。課程還提示讀者嘗試把容量改為3觀察執(zhí)行變化或刪掉drop(sender)看會(huì)發(fā)生什么此時(shí)Receiver永遠(yuǎn)等不到通道關(guān)閉ping_handler不會(huì)結(jié)束。八、小結(jié)與課程配套練習(xí)本文完整覆蓋了課程「Senders and Receivers」一節(jié)的全部核心內(nèi)容并延伸到了兄弟章節(jié)與倉(cāng)庫(kù)練習(xí)核心要點(diǎn)說(shuō)明兩個(gè)端點(diǎn)SenderT發(fā)送、ReceiverT接收通道本身不可見(jiàn)mpsc 語(yǔ)義Multi-Producer, Single-ConsumerSender/SyncSender可CloneReceiver不可Result返回值send()/recv()返回Err即表示對(duì)端已 drop、通道已關(guān)閉無(wú)界通道m(xù)psc::channel()send()不阻塞見(jiàn) unbounded.md有界通道m(xù)psc::sync_channel(n)send()可能阻塞容量 0 即 rendezvous 通道見(jiàn) bounded.md實(shí)戰(zhàn)范例哲學(xué)家就餐dining-philosophers.rs、鏈接檢查器link-checker.rs異步延伸tokio 異步通道建議的進(jìn)階路徑先在哲學(xué)家就餐練習(xí)中把通道接入Philosopher結(jié)構(gòu)體并跑通cargo run注意需要本地 Cargo 環(huán)境參見(jiàn)本地運(yùn)行指南再挑戰(zhàn)鏈接檢查器的雙通道架構(gòu)。多思考一個(gè)問(wèn)題為什么 Rust 選擇讓send/recv返回Result而不是 panic答案正是本文反復(fù)強(qiáng)調(diào)的——通道關(guān)閉是程序正常流程的一部分消費(fèi)者先退出、生產(chǎn)者停止投遞應(yīng)當(dāng)作為可控的Err分支處理而不是崩潰。【免費(fèi)下載鏈接】comprehensive-rustThis is the Rust course used by the Android team at Google. It provides you the material to quickly teach Rust.項(xiàng)目地址: https://gitcode.com/GitHub_Trending/co/comprehensive-rust創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Comprehensive Rust 并發(fā)教程：深入理解 Sender 與 Receiver——Rust mpsc 通道的端到端實(shí)踐
Comprehensive Rust 并發(fā)教程深入理解 Sender 與 Receiver——Rust mpsc 通道的端到端實(shí)踐【免費(fèi)下載鏈接】comprehensive-rustThis is the Rust course used by the Android team at Google. It provides you the material to quickly teach Rust.項(xiàng)目地址: https://gitcode.com/GitHub_Trending/co/comprehensive-rust本篇文章基于 Google Android 團(tuán)隊(duì)維護(hù)的 Rust 課程 comprehensive-rust 中「Senders and Receivers」一節(jié)展開(kāi)。它以 9 分鐘的授課篇幅講解了 Rust 標(biāo)準(zhǔn)庫(kù)std::sync::mpsc通道最核心的兩個(gè)端點(diǎn)SenderT與ReceiverT如何創(chuàng)建通道、如何發(fā)送與接收消息、多生產(chǎn)者單消費(fèi)者的語(yǔ)義以及通道關(guān)閉與Result錯(cuò)誤處理。讀完本文你將掌握 mpsc 通道的完整使用模式并能看懂課程倉(cāng)庫(kù)中「哲學(xué)家就餐」與「鏈接檢查器」兩個(gè)實(shí)戰(zhàn)練習(xí)里通道的真實(shí)用法。一、通道的兩個(gè)端點(diǎn)Sender 與 Receiver在 Rust 中通道channel是一種線程間傳遞消息message passing的同步原語(yǔ)。與共享內(nèi)存加鎖的方式不同通道讓數(shù)據(jù)通過(guò)管道流動(dòng)發(fā)送方把值放進(jìn)去接收方按順序取出來(lái)兩端無(wú)需直接接觸彼此的數(shù)據(jù)。Rust 的通道由兩部分組成SenderT發(fā)送端點(diǎn)把類(lèi)型為T(mén)的值送入通道ReceiverT接收端點(diǎn)從通道中取出T類(lèi)型的值。兩者通過(guò)內(nèi)部的通道連接在一起但對(duì)使用者而言你只能看到這兩個(gè)端點(diǎn)——通道本身是不可見(jiàn)的。發(fā)送方只能往里放接收方只能往外取這種隔離正是消息傳遞模型安全性的來(lái)源數(shù)據(jù)的所有權(quán)在端點(diǎn)之間轉(zhuǎn)移而不是被多個(gè)線程同時(shí)借用。二、最小可用示例創(chuàng)建通道、發(fā)送與接收課程給出了一個(gè)完整可運(yùn)行的示例直接演示了通道的創(chuàng)建、發(fā)送、接收與多生產(chǎn)者克隆use std::sync::mpsc; fn main() { let (tx, rx) mpsc::channel(); tx.send(10).unwrap(); tx.send(20).unwrap(); println!(Received: {:?}, rx.recv()); println!(Received: {:?}, rx.recv()); let tx2 tx.clone(); tx2.send(30).unwrap(); println!(Received: {:?}, rx.recv()); }逐行拆解這段代碼let (tx, rx) mpsc::channel();調(diào)用mpsc::channel()一次性返回一對(duì)端點(diǎn)(Sender, Receiver)。此處T由后續(xù)send的消息類(lèi)型推斷為i32因此實(shí)際類(lèi)型為Senderi32與Receiveri32。整個(gè)示例沒(méi)有顯式創(chuàng)建線程main線程既是生產(chǎn)者又是消費(fèi)者這便于先理解 API 本身再過(guò)渡到多線程場(chǎng)景。tx.send(10).unwrap();/tx.send(20).unwrap();通過(guò)Sender連續(xù)發(fā)送兩條消息。兩次rx.recv()按發(fā)送順序先進(jìn)先出接收消息。recv()返回的是ResultDebug格式化{:?}會(huì)打印出Ok(10)、Ok(20)。let tx2 tx.clone();克隆發(fā)送端點(diǎn)得到第二個(gè)生產(chǎn)者。此時(shí)通道中共有tx、tx2兩個(gè)發(fā)送端點(diǎn)但接收端rx仍只有一個(gè)。tx2.send(30).unwrap();從克隆出的第二個(gè)發(fā)送端發(fā)送第三條消息rx.recv()依然能收到Ok(30)。程序最終輸出Received: Ok(10) Received: Ok(20) Received: Ok(30)注意Sender是按值move語(yǔ)義發(fā)送消息的——send(10)會(huì)把10的所有權(quán)移交進(jìn)通道發(fā)送后原變量不再可用而recv()接收時(shí)則把消息的所有權(quán)從通道移交給接收方。三、mpsc 的含義多生產(chǎn)者單消費(fèi)者mpsc是Multi-Producer, Single-Consumer的縮寫(xiě)即多生產(chǎn)者、單消費(fèi)者這是理解 Rust 標(biāo)準(zhǔn)庫(kù)通道設(shè)計(jì)的關(guān)鍵多生產(chǎn)者Sender和SyncSender都實(shí)現(xiàn)了Clone。你可以通過(guò)克隆任意多個(gè)發(fā)送端讓多個(gè)線程同時(shí)向同一個(gè)通道投遞消息它們彼此共享同一個(gè)接收端。上面示例中的tx.clone()正是多生產(chǎn)者能力的直接體現(xiàn)。單消費(fèi)者Receiver不實(shí)現(xiàn)Clone每個(gè)通道只有一個(gè)接收端。這保證了所有消息以確定性的順序被唯一一個(gè)消費(fèi)者取出避免了多消費(fèi)者競(jìng)爭(zhēng)分配消息的復(fù)雜度。這個(gè)多對(duì)一的不對(duì)稱(chēng)設(shè)計(jì)使 mpsc 天然適合任務(wù)分發(fā) 單點(diǎn)匯總的經(jīng)典模式多個(gè)工作線程把計(jì)算結(jié)果發(fā)往同一個(gè)收集端。四、send 與 recv 的 Result通道關(guān)閉即錯(cuò)誤send()和recv()的返回值都是Result這是一個(gè)容易被初學(xué)者忽略、但極其重要的細(xì)節(jié)如果send()返回Err意味著對(duì)端的Receiver已被 drop通道已經(jīng)關(guān)閉消息無(wú)法送達(dá)如果recv()返回Err意味著所有Sender包括所有克隆體都已被 drop通道已關(guān)閉不會(huì)再有任何消息到來(lái)。通道的關(guān)閉不是顯式操作而是由端點(diǎn)生命周期自動(dòng)驅(qū)動(dòng)的當(dāng)某一側(cè)的端點(diǎn)全部被 drop 時(shí)通道即宣告關(guān)閉。正因?yàn)榉祷刂凳荝esult課程示例中一律使用.unwrap()簡(jiǎn)化處理而生產(chǎn)代碼中應(yīng)當(dāng)使用expect(...)提供上下文或通過(guò)match/?顯式處理通道提前關(guān)閉這一正常業(yè)務(wù)分支例如消費(fèi)者退出后生產(chǎn)者應(yīng)當(dāng)停止投遞。這一關(guān)閉語(yǔ)義在課程倉(cāng)庫(kù)的兄弟章節(jié)中有更完整的闡述在 無(wú)界通道章節(jié) 中明確send()在通道關(guān)閉時(shí)會(huì)以錯(cuò)誤中止這也是它返回Result的原因而通道在Receiver被 drop 時(shí)關(guān)閉在 有界通道章節(jié) 中補(bǔ)充與無(wú)界通道相同通道關(guān)閉時(shí)調(diào)用send()同樣會(huì)以錯(cuò)誤中止。五、通道的兩種形態(tài)無(wú)界與有界課程將通道劃分為兩種形態(tài)二者使用同一對(duì)Sender/Receiver端點(diǎn)差異在于緩沖與阻塞行為。先掌握mpsc::channel()無(wú)界、異步再看mpsc::sync_channel(n)有界、同步梯度非常清晰。5.1 無(wú)界通道m(xù)psc::channel()本節(jié)示例所用的mpsc::channel()創(chuàng)建的是無(wú)界且異步的通道通道會(huì)按需分配足夠的內(nèi)存來(lái)暫存所有待處理消息send()永遠(yuǎn)不會(huì)阻塞調(diào)用線程發(fā)送方可以持續(xù)投遞不必關(guān)心消費(fèi)者當(dāng)前的處理速度。無(wú)界通道章節(jié) 給出了多線程版本的完整示例子線程通過(guò)move閉包捕獲tx循環(huán)發(fā)送 10 條format!(Message {i})主線程sleep(100ms)后再通過(guò)for msg in rx消費(fèi)。Receiver實(shí)現(xiàn)了Iteratorfor循環(huán)會(huì)一直迭代到通道關(guān)閉即所有發(fā)送端被 drop為止——這是消費(fèi)通道消息最慣用的寫(xiě)法。5.2 有界通道m(xù)psc::sync_channel(n)若調(diào)用mpsc::sync_channel(3)則得到有界同步通道此時(shí)send()的語(yǔ)義發(fā)生關(guān)鍵變化send()會(huì)阻塞當(dāng)前線程直到通道內(nèi)有空間容納新消息如果沒(méi)有任何消費(fèi)者讀取發(fā)送線程可能無(wú)限期阻塞容量為 0 的有界通道被稱(chēng)為rendezvous channel會(huì)合通道每次send()都會(huì)阻塞直到另一個(gè)線程調(diào)用recv()實(shí)現(xiàn)握手式同步傳遞。有界通道章節(jié) 的示例正是用sync_channel(3)演示了這一行為子線程發(fā)送第 4 條消息時(shí)被阻塞直到主線程從for msg in rx中消費(fèi)出空位才繼續(xù)。選擇建議無(wú)界通道實(shí)現(xiàn)簡(jiǎn)單、永不阻塞發(fā)送方但消息積壓可能耗盡內(nèi)存有界通道通過(guò)背壓backpressure天然限制積壓代價(jià)是發(fā)送方可能阻塞——需要結(jié)合具體場(chǎng)景權(quán)衡。六、源碼佐證mpsc 在課程練習(xí)中的真實(shí)應(yīng)用Sender/Receiver并非停留在理論層面課程倉(cāng)庫(kù)的多個(gè)練習(xí)都用它構(gòu)建了真實(shí)的并發(fā)程序可以直接作為參照實(shí)現(xiàn)閱讀。6.1 哲學(xué)家就餐用SyncSender匯總思想輸出在 哲學(xué)家就餐練習(xí) 的參考答案中每個(gè)哲學(xué)家線程并不直接println!自己的思想而是把想法發(fā)給通道use std::sync::{Arc, Mutex, mpsc}; use std::thread; struct Philosopher { name: String, left_chopstick: ArcMutexChopstick, right_chopstick: ArcMutexChopstick, thoughts: mpsc::SyncSenderString, }主線程創(chuàng)建mpsc::sync_channel(10)得到(tx, rx)5 個(gè)哲學(xué)家線程各自tx.clone()獲得自己的發(fā)送端多生產(chǎn)者的實(shí)戰(zhàn)體現(xiàn)tx本身在循環(huán)外被保留最后在主線程drop(tx)Philosopher::think中通過(guò)self.thoughts.send(...)投遞String主線程末尾drop(tx)后執(zhí)行for thought in rx把 5 個(gè)生產(chǎn)者產(chǎn)出的所有思想消息按序打印。這里的drop(tx)至關(guān)重要它關(guān)閉了主線程手中的發(fā)送端確保當(dāng)所有哲學(xué)家線程結(jié)束、最后一個(gè)發(fā)送端也 drop 后for thought in rx能自然結(jié)束迭代——這正是上一節(jié)通道關(guān)閉語(yǔ)義的實(shí)戰(zhàn)運(yùn)用。同時(shí)哲學(xué)家們通過(guò)ArcMutexChopstick共享筷子、通過(guò)通道傳遞消息展示了 Rust 兩種并發(fā)模型的互補(bǔ)。6.2 鏈接檢查器雙通道 ArcMutexReceiver鏈接檢查器練習(xí)的參考答案是一個(gè)更復(fù)雜的生產(chǎn)者-消費(fèi)者架構(gòu)同時(shí)使用了兩對(duì)通道let (result_sender, result_receiver) mpsc::channel::CrawlResult(); let (command_sender, command_receiver) mpsc::channel::CrawlCommand(); spawn_crawler_threads(command_receiver, result_sender, 16); control_crawl(start_url, command_sender, result_receiver)一對(duì)CrawlCommand通道控制端向 16 個(gè)爬蟲(chóng)線程下發(fā)抓取指令一對(duì)多分發(fā)一對(duì)CrawlResult通道16 個(gè)爬蟲(chóng)線程把結(jié)果回傳給控制端多對(duì)一匯總。這里有兩個(gè)值得注意的細(xì)節(jié)16 個(gè)爬蟲(chóng)線程需要共享同一個(gè)ReceiverCrawlCommand但Receiver不可Clone于是源碼用ArcMutexReceiverCrawlCommand包裹接收端來(lái)實(shí)現(xiàn)共享見(jiàn)spawn_crawler_threads中l(wèi)et command_receiver Arc::new(Mutex::new(command_receiver));這是單消費(fèi)者約束下多線程共享讀取的慣用折中方案所有爬蟲(chóng)線程各持有一個(gè)result_sender的克隆多個(gè)生產(chǎn)者并發(fā)向單一消費(fèi)者回傳結(jié)果正是 mpsc 命名含義的完整實(shí)踐。七、從同步通道到異步通道Sender/Receiver思想的延伸掌握標(biāo)準(zhǔn)庫(kù) mpsc 后課程在異步控制流章節(jié)中進(jìn)一步展示了tokio::sync::mpsc的用法接口與標(biāo)準(zhǔn)庫(kù)高度相似use tokio::sync::mpsc; async fn ping_handler(mut input: mpsc::Receiver()) { let mut count: usize 0; while let Some(_) input.recv().await { count 1; println!(Received {count} pings so far.); } } #[tokio::main] async fn main() { let (sender, receiver) mpsc::channel(32); let ping_handler_task tokio::spawn(ping_handler(receiver)); for i in 0..10 { sender.send(()).await.expect(Failed to send ping.); } drop(sender); ping_handler_task.await.expect(Something went wrong in ping handler task.); }關(guān)鍵差異在于tokio的通道是有界容量此處為 32send().await與recv().await都是異步的遇到緩沖區(qū)滿/空時(shí)掛起而不是阻塞線程并且可以與其他future組合出復(fù)雜控制流。正如課程所述總體接口與早間課程中看到的同步通道相似——把本節(jié)Sender/Receiver的思想遷移到 async 世界學(xué)習(xí)曲線會(huì)平緩很多。課程還提示讀者嘗試把容量改為3觀察執(zhí)行變化或刪掉drop(sender)看會(huì)發(fā)生什么此時(shí)Receiver永遠(yuǎn)等不到通道關(guān)閉ping_handler不會(huì)結(jié)束。八、小結(jié)與課程配套練習(xí)本文完整覆蓋了課程「Senders and Receivers」一節(jié)的全部核心內(nèi)容并延伸到了兄弟章節(jié)與倉(cāng)庫(kù)練習(xí)核心要點(diǎn)說(shuō)明兩個(gè)端點(diǎn)SenderT發(fā)送、ReceiverT接收通道本身不可見(jiàn)mpsc 語(yǔ)義Multi-Producer, Single-ConsumerSender/SyncSender可CloneReceiver不可Result返回值send()/recv()返回Err即表示對(duì)端已 drop、通道已關(guān)閉無(wú)界通道m(xù)psc::channel()send()不阻塞見(jiàn) unbounded.md有界通道m(xù)psc::sync_channel(n)send()可能阻塞容量 0 即 rendezvous 通道見(jiàn) bounded.md實(shí)戰(zhàn)范例哲學(xué)家就餐dining-philosophers.rs、鏈接檢查器link-checker.rs異步延伸tokio 異步通道建議的進(jìn)階路徑先在哲學(xué)家就餐練習(xí)中把通道接入Philosopher結(jié)構(gòu)體并跑通cargo run注意需要本地 Cargo 環(huán)境參見(jiàn)本地運(yùn)行指南再挑戰(zhàn)鏈接檢查器的雙通道架構(gòu)。多思考一個(gè)問(wèn)題為什么 Rust 選擇讓send/recv返回Result而不是 panic答案正是本文反復(fù)強(qiáng)調(diào)的——通道關(guān)閉是程序正常流程的一部分消費(fèi)者先退出、生產(chǎn)者停止投遞應(yīng)當(dāng)作為可控的Err分支處理而不是崩潰。【免費(fèi)下載鏈接】comprehensive-rustThis is the Rust course used by the Android team at Google. It provides you the material to quickly teach Rust.項(xiàng)目地址: https://gitcode.com/GitHub_Trending/co/comprehensive-rust創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考