寫 Rust 這幾年被問(wèn)得最多的一句話就是“所有權(quán)到底是個(gè)啥”。我一直覺(jué)得這個(gè)中文譯名有點(diǎn)誤導(dǎo)聽(tīng)起來(lái)像某種法律概念實(shí)際上它描述的是一件特別樸素的事一塊內(nèi)存由誰(shuí)負(fù)責(zé)釋放、什么時(shí)候釋放、釋放之前誰(shuí)有資格讀寫。C 里這件事靠人腦記賬Java、Go 里這件事交給運(yùn)行時(shí)在后臺(tái)掃Rust 選了第三條路——把賬本寫進(jìn)類型系統(tǒng)讓編譯器在編譯期替你記。代價(jià)是你得學(xué)會(huì)跟編譯器講道理收益是運(yùn)行時(shí)沒(méi)有停頓、沒(méi)有懸垂指針、沒(méi)有雙重釋放單線程代碼里的迭代器失效問(wèn)題基本絕跡。這篇筆記把所有權(quán)、借用檢查、生命周期標(biāo)注、智能指針這幾塊串起來(lái)講重點(diǎn)放在“它怎么影響內(nèi)存管理”這個(gè)角度而不是復(fù)述語(yǔ)法手冊(cè)。適合已經(jīng)能寫點(diǎn) Rust 但總被借用檢查器攔下來(lái)的人也適合從 C 或 Go 轉(zhuǎn)過(guò)來(lái)、想搞清楚心智模型差異的人。下面所有報(bào)錯(cuò)和改法都是我實(shí)際踩過(guò)的代碼可以直接抄去跑。1. 三種內(nèi)存管理路線Rust 為什么挑了最難的這條1.1 手動(dòng)管理與垃圾回收各自的賬單先把三條路擺在桌面上對(duì)比不然后面很多設(shè)計(jì)取舍會(huì)顯得莫名其妙。手動(dòng)管理C、C 的裸指針路線把釋放時(shí)機(jī)完全交給開(kāi)發(fā)者性能上限最高內(nèi)存布局最可控代價(jià)是任何一次疏忽都會(huì)變成線上事故而且這類事故往往在壓力大的時(shí)候才暴露。垃圾回收J(rèn)ava、Go、C# 的默認(rèn)路線把釋放交給運(yùn)行時(shí)開(kāi)發(fā)者寫得舒服代價(jià)是內(nèi)存占用曲線偏高延遲不可預(yù)測(cè)遇到大堆的時(shí)候一次回收能帶來(lái)幾十毫秒的抖動(dòng)。Rust 的所有權(quán)系統(tǒng)是第三條路編譯器在編譯期為每個(gè)值推導(dǎo)出唯一的負(fù)責(zé)方負(fù)責(zé)方離開(kāi)作用域就自動(dòng)釋放檢查全部發(fā)生在編譯期運(yùn)行時(shí)不需要任何額外指令。路線釋放時(shí)機(jī)運(yùn)行時(shí)開(kāi)銷典型風(fēng)險(xiǎn)延遲可預(yù)測(cè)性手動(dòng)管理開(kāi)發(fā)者調(diào)用 free/delete接近零懸垂指針、雙重釋放、泄漏高垃圾回收運(yùn)行時(shí)掃描判定5% 到 30% 不等看堆大小停頓抖動(dòng)、內(nèi)存峰值高低所有權(quán)系統(tǒng)作用域結(jié)束自動(dòng) drop編譯期檢查運(yùn)行時(shí)為零學(xué)習(xí)曲線、改寫數(shù)據(jù)結(jié)構(gòu)高這張表里最關(guān)鍵的一列是“運(yùn)行時(shí)開(kāi)銷”。Rust 的所有權(quán)檢查在編譯完成后就消失了生成的機(jī)器碼里沒(méi)有任何一條指令是用來(lái)“檢查所有權(quán)”的這叫零成本抽象。你付出的是編譯期的思考成本和偶爾的改寫成本換來(lái)的是運(yùn)行時(shí)的確定性。1.2 所有權(quán)本質(zhì)上是一套編譯期推導(dǎo)出來(lái)的引用計(jì)數(shù)我習(xí)慣用引用計(jì)數(shù)來(lái)類比所有權(quán)這個(gè)類比能解釋掉八成的疑惑。真正的引用計(jì)數(shù)比如RcT是在運(yùn)行時(shí)維護(hù)一個(gè)整數(shù)每次克隆加一每次銷毀減一減到零就釋放。所有權(quán)系統(tǒng)做的事情幾乎一樣區(qū)別在于編譯器在編譯期就能推導(dǎo)出每個(gè)值的引用計(jì)數(shù)永遠(yuǎn)是 0 或 1既然結(jié)果只有兩種那就不需要在運(yùn)行時(shí)存這個(gè)整數(shù)了直接把它編碼進(jìn)類型檢查規(guī)則里。所以String被賦值給另一個(gè)變量之后原變量立刻失效——因?yàn)樵诰幾g器的賬本上這個(gè)值的所有者已經(jīng)換人了舊主人再訪問(wèn)就是越權(quán)。這個(gè)類比還能解釋另一個(gè)現(xiàn)象為什么RcT在 Rust 里被歸到“智能指針”而不是“所有權(quán)”里。因?yàn)橐坏┠阏娴男枰鄠€(gè)所有者編譯期就沒(méi)法推導(dǎo)出唯一負(fù)責(zé)方了只能退回到運(yùn)行時(shí)記賬這就是Rc和Arc存在的原因。理解了這個(gè)層次關(guān)系你就不會(huì)覺(jué)得RcRefCellT是一堆奇怪符號(hào)的堆砌而會(huì)明白它是“編譯期賬本不夠用時(shí)的降級(jí)方案”。1.3 編譯期到底擋住了哪幾類事故具體一點(diǎn)所有權(quán)加借用檢查主要攔四類問(wèn)題。第一類是釋放后使用C 里指針指著的內(nèi)存已經(jīng)被free掉讀出來(lái)是臟數(shù)據(jù)Rust 里編譯器直接告訴你這個(gè)值已經(jīng) move 走了。第二類是雙重釋放兩個(gè)指針指向同一塊堆內(nèi)存析構(gòu)函數(shù)跑兩遍堆管理器直接崩Rust 里因?yàn)橹挥幸粋€(gè)所有者drop只會(huì)執(zhí)行一次。第三類是迭代器失效這是 C 里最陰的一類 bug往vector里push_back之后原來(lái)的迭代器可能指向已釋放的舊緩沖區(qū)Rust 里你在遍歷v的同時(shí)調(diào)v.push()會(huì)直接編譯失敗。第四類是數(shù)據(jù)競(jìng)爭(zhēng)多個(gè)線程同時(shí)讀寫同一塊內(nèi)存且沒(méi)有同步Rust 靠Send和Sync兩個(gè)標(biāo)記 trait 在編譯期就把不安全的共享?yè)醯?。我印象最深的是第三類。早年?C 的時(shí)候在一個(gè)循環(huán)里刪元素導(dǎo)致迭代器失效程序在小數(shù)據(jù)量下跑得好好的上線之后數(shù)據(jù)量上來(lái)才開(kāi)始隨機(jī)崩潰查了兩天才定位到。換成 Rust 之后這種寫法連編譯都過(guò)不去等于把調(diào)試成本從線上挪到了敲代碼的那幾分鐘。2. 三條鐵律落地move、Copy、Clone 在內(nèi)存里到底做了什么2.1 三條規(guī)則逐條對(duì)照內(nèi)存行為所有權(quán)的規(guī)則只有三條但每一條都對(duì)應(yīng)著實(shí)實(shí)在在的內(nèi)存動(dòng)作。第一條每個(gè)值有且只有一個(gè)所有者。第二條同一時(shí)刻只能有一個(gè)所有者。第三條所有者離開(kāi)作用域值被丟棄。這三條合起來(lái)的效果是任何一塊堆內(nèi)存的釋放點(diǎn)都是唯一且確定的編譯器在生成代碼的時(shí)候就知道該在哪里插入釋放調(diào)用不需要運(yùn)行時(shí)判斷。拿String舉例。let s1 String::from(hello);這一行會(huì)在棧上放一個(gè)三元組指針、容量、長(zhǎng)度在堆上放五個(gè)字節(jié)的數(shù)據(jù)。接著let s2 s1;這一行做的事情是把棧上那 24 個(gè)字節(jié)復(fù)制一份給s2堆上的數(shù)據(jù)一個(gè)字節(jié)都不動(dòng)然后編譯器在符號(hào)表里把s1標(biāo)記為失效。如果你這時(shí)候?qū)憄rintln!({}, s1)編譯器報(bào) E0382意思是使用了已經(jīng) move 走的值。注意這里沒(méi)有發(fā)生任何堆內(nèi)存分配或復(fù)制move 對(duì)String這類類型來(lái)說(shuō)是常數(shù)時(shí)間操作。2.2 move 不是“搬家”是所有權(quán)憑證的轉(zhuǎn)移很多人以為 move 會(huì)把堆上的數(shù)據(jù)搬到新地址這是個(gè)誤解。move 搬的只是棧上那個(gè)描述符堆數(shù)據(jù)原地不動(dòng)。這也解釋了為什么對(duì)大對(duì)象做 move 是廉價(jià)的VecT裝一百萬(wàn)個(gè)元素move 一次也只復(fù)制 24 個(gè)字節(jié)的頭部。真正昂貴的是clone那才是老老實(shí)實(shí)把堆數(shù)據(jù)復(fù)制一份。我用一段代碼把這個(gè)差別量化一下你可以直接跑fn main() { let v1: Vecu64 (0..1_000_000).collect(); let start std::time::Instant::now(); let v2 v1; // move只復(fù)制頭部 println!(move 耗時(shí): {:?}, start.elapsed()); let start std::time::Instant::now(); let v3 v2.clone(); // clone復(fù)制全部堆數(shù)據(jù) println!(clone 耗時(shí): {:?}, start.elapsed()); println!({} {}, v3.len(), std::mem::size_of::Vecu64()); }實(shí)測(cè)下來(lái) move 通常是納秒級(jí)clone 一百萬(wàn)個(gè)u64大概在幾百微秒到一毫秒之間取決于內(nèi)存帶寬。這個(gè)差距在高頻路徑上是致命的所以我養(yǎng)成一個(gè)習(xí)慣函數(shù)簽名里能傳引用就傳引用確實(shí)需要轉(zhuǎn)移所有權(quán)才用 move絕不為了圖省事到處寫.clone()。2.3 Copy 與 Clone 的邊界怎么劃Copy和Clone經(jīng)常被混為一談其實(shí)差別很大。Copy是一個(gè)標(biāo)記 trait表示這個(gè)類型的值可以按位復(fù)制賦值之后原變量依然可用。能實(shí)現(xiàn)Copy的類型有兩個(gè)硬性條件所有字段都是Copy并且這個(gè)類型本身沒(méi)有實(shí)現(xiàn)Drop。整數(shù)、浮點(diǎn)數(shù)、布爾、字符、裸指針、以及由它們組成的固定大小數(shù)組和元組都是Copy的。String、VecT、BoxT都不是因?yàn)樗鼈児芾碇褍?nèi)存按位復(fù)制會(huì)導(dǎo)致兩個(gè)所有者指向同一塊堆這正是所有權(quán)系統(tǒng)要避免的。Clone則是一個(gè)普通 trait需要你顯式調(diào)用.clone()它允許你自定義復(fù)制邏輯比如深拷貝堆數(shù)據(jù)。任何類型都可以實(shí)現(xiàn)Clone包括實(shí)現(xiàn)了Drop的類型。這里有個(gè)常見(jiàn)的性能坑給一個(gè)大結(jié)構(gòu)體derive(Clone)之后在循環(huán)里順手寫.clone()傳參編譯器不會(huì)提醒你代碼跑起來(lái)才發(fā)現(xiàn)慢得離譜。我的做法是只有在確實(shí)需要獨(dú)立副本的地方才 deriveClone而且在大結(jié)構(gòu)體上會(huì)刻意不 derive逼著自己去想清楚到底該傳引用還是轉(zhuǎn)移所有權(quán)。順便說(shuō)一個(gè)實(shí)測(cè)有用的小技巧用std::mem::size_of快速看一眼類型的棧上開(kāi)銷很多“為什么這個(gè)結(jié)構(gòu)體這么大”的疑惑一測(cè)就清楚了fn main() { println!(String {}, std::mem::size_of::String()); // 24 println!(str {}, std::mem::size_of::str()); // 16 println!(Boxu64 {}, std::mem::size_of::Boxu64()); // 8 println!(OptionBoxu64 {}, std::mem::size_of::OptionBoxu64()); // 8 println!(Rcu64 {}, std::mem::size_of::Rcu64()); // 8 }OptionBoxT只占 8 字節(jié)這件事值得單獨(dú)說(shuō)一下。編譯器發(fā)現(xiàn)Box的指針不可能是零于是用空指針這個(gè)非法值來(lái)表示None這叫空指針優(yōu)化。這個(gè)優(yōu)化在鏈表、樹(shù)這類遞歸結(jié)構(gòu)里非常關(guān)鍵不然每個(gè)節(jié)點(diǎn)都要多帶一個(gè)字節(jié)的判別位再加對(duì)齊填充內(nèi)存占用會(huì)明顯上升。2.4 函數(shù)簽名就是一份所有權(quán)契約我一直建議新手把函數(shù)簽名當(dāng)成一份合同來(lái)讀。參數(shù)寫T表示調(diào)用方把這個(gè)值的所有權(quán)交出去了函數(shù)返回之后調(diào)用方不能再碰它寫T表示只借來(lái)讀函數(shù)內(nèi)部改不了寫mut T表示借來(lái)改借用期間調(diào)用方不能用寫self和mut self是同樣的道理只是作用在方法接收者上。一份好的簽名應(yīng)該讓調(diào)用方一眼看出“我還能不能用這個(gè)變量”。fn consume(s: String) - usize { s.len() } // 拿走所有權(quán) fn inspect(s: str) - usize { s.len() } // 只借用讀 fn append(s: mut String, tail: str) { s.push_str(tail); } // 借用改 fn create() - String { String::from(new) } // 交出所有權(quán)這四行基本覆蓋了九成場(chǎng)景。我踩過(guò)的一個(gè)坑是函數(shù)參數(shù)寫成String但其實(shí)只讀一下長(zhǎng)度結(jié)果調(diào)用方每次都得 clone 一份才能傳進(jìn)去。改成str之后String和字符串字面量都能直接傳調(diào)用方省掉了所有 clone。這個(gè)改動(dòng)看起來(lái)小在一個(gè)熱路徑上能省掉可觀的分配次數(shù)。3. 借用檢查器到底在檢查什么3.1 共享不可變、獨(dú)占可變借用規(guī)則只有一句話任意時(shí)刻你要么擁有多個(gè)不可變引用要么擁有一個(gè)可變引用兩者不能同時(shí)存在。另外所有引用必須始終有效。這條規(guī)則的動(dòng)機(jī)有兩個(gè)層次。淺層是為了防止數(shù)據(jù)競(jìng)爭(zhēng)多個(gè)線程同時(shí)讀是安全的只要有寫就必須獨(dú)占。深層是為了防止同一份數(shù)據(jù)在讀取過(guò)程中被別處改掉導(dǎo)致讀到的內(nèi)容前后不一致。舉一個(gè)最典型的例子遍歷的同時(shí)修改集合fn main() { let mut v vec![1, 2, 3]; for x in v { if *x 2 { v.push(4); // 報(bào)錯(cuò) E0502 } } }編譯器會(huì)告訴你v已經(jīng)被不可變借用不能再作為可變借用。這個(gè)限制在 C 里是允許的代價(jià)是push可能觸發(fā)重新分配原來(lái)的迭代器變成懸垂指針接著就是未定義行為。Rust 直接把這條路堵死。正確的寫法是先收集要改的內(nèi)容循環(huán)結(jié)束后再統(tǒng)一改fn main() { let mut v vec![1, 2, 3]; let need_push v.iter().any(|x| x 2); if need_push { v.push(4); } }這種“先讀后寫”的拆分模式我用了無(wú)數(shù)次幾乎所有的借用沖突都能用這個(gè)思路化解。它看起來(lái)多寫了一行實(shí)際上是把原本隱藏的時(shí)序依賴顯式化了代碼反而更清楚。3.2 NLL 讓借用的結(jié)束點(diǎn)變聰明了早期的 Rust 用詞法作用域判斷借用何時(shí)結(jié)束只要變量還在作用域里借用就算沒(méi)結(jié)束于是很多寫法通不過(guò)。從 2018 edition 開(kāi)始默認(rèn)啟用非詞法生命周期NLL借用的有效期縮短到“最后一次使用”為止。這個(gè)改進(jìn)影響巨大很多以前必須用花括號(hào)強(qiáng)行劃作用域的代碼現(xiàn)在可以直接寫。fn main() { let mut data vec![1, 2, 3]; let first data[0]; println!({}, first); // first 的最后一次使用 data.push(4); // 現(xiàn)在合法了借用已經(jīng)結(jié)束 println!({:?}, data); }這段代碼在老版本會(huì)報(bào)錯(cuò)因?yàn)閐ata的可變借用和first的不可變借用被認(rèn)為在同一個(gè)作用域里共存。NLL 之后編譯器看出first在println之后就沒(méi)用了借用提前結(jié)束后面的push就不沖突了。理解這一點(diǎn)很重要它意味著你不需要為了繞開(kāi)借用檢查而寫一堆莫名其妙的花括號(hào)只要讓借用自然地在最后一次使用處結(jié)束就行。3.3 生命周期標(biāo)注不延長(zhǎng)壽命只是描述關(guān)系生命周期這個(gè)詞嚇退過(guò)不少人其實(shí)它的作用被嚴(yán)重夸大了。生命周期標(biāo)注不會(huì)讓任何值的存活時(shí)間變長(zhǎng)或變短它只是告訴編譯器“這幾個(gè)引用之間的存活關(guān)系是這樣的”方便編譯器做檢查。真正決定值活多久的永遠(yuǎn)是它所在的作用域。最經(jīng)典的例子是返回兩個(gè)字符串切片里較長(zhǎng)的那個(gè)fn longesta(x: a str, y: a str) - a str { if x.len() y.len() { x } else { y } }不寫標(biāo)注的話編譯器報(bào) E0106因?yàn)樗鼰o(wú)法確定返回的引用到底跟著x還是y活。a的意思是返回值的存活時(shí)間不會(huì)超過(guò)x和y中較短的那個(gè)。這是一個(gè)上界約束不是延長(zhǎng)。調(diào)用方拿到返回值之后只要保證在x和y都還活著的時(shí)候用它就行。生命周期省略規(guī)則有三條記住這三條能省掉大部分手寫標(biāo)注。第一每個(gè)引用參數(shù)各自獲得一個(gè)獨(dú)立的生命周期參數(shù)。第二如果只有一個(gè)輸入引用參數(shù)那么輸出的生命周期全部等于它。第三如果有self或mut self那么輸出的生命周期全部等于self的。第三條是方法簽名的常用規(guī)則所以大多數(shù)方法不需要手寫生命周期標(biāo)注。3.4 結(jié)構(gòu)體持有引用必須寫生命周期這是新手最容易卡住的地方。結(jié)構(gòu)體里如果放了引用就必須給結(jié)構(gòu)體加生命周期參數(shù)因?yàn)榫幾g器需要確保這個(gè)引用比結(jié)構(gòu)體本身活得久。否則結(jié)構(gòu)體還存在的時(shí)候它指向的數(shù)據(jù)可能已經(jīng)被釋放了。struct Tokena { text: a str, line: usize, } impla Tokena { fn len(self) - usize { self.text.len() } }Tokena讀作“這個(gè) Token 的有效期不能超過(guò)a”。這意味著任何持有Token的地方那個(gè)被引用的字符串也得活著編譯器會(huì)一路向上檢查。這個(gè)傳播有時(shí)候會(huì)很煩一個(gè)底層結(jié)構(gòu)加了生命周期上面三層都得跟著加。我的處理策略是分場(chǎng)景的。如果這段數(shù)據(jù)是短命的、臨時(shí)的、解析完就用完的那就老老實(shí)實(shí)加生命周期零拷貝最快。如果這段數(shù)據(jù)要被存起來(lái)、跨函數(shù)傳遞、或者放進(jìn)集合里長(zhǎng)期持有那就直接存String用一次分配換掉整條鏈上的生命周期標(biāo)注。這個(gè)取舍在下一節(jié)的實(shí)戰(zhàn)案例里會(huì)詳細(xì)展開(kāi)。4. 智能指針編譯期賬本不夠用的時(shí)候4.1 Box、Rc、Arc、RefCell 各自解決什么問(wèn)題所有權(quán)的默認(rèn)模型是單一所有者加獨(dú)占可變這個(gè)模型覆蓋了大部分場(chǎng)景但確實(shí)有幾類需求它表達(dá)不了需要在堆上分配且大小在編譯期未知的遞歸類型、需要多個(gè)所有者共享同一份數(shù)據(jù)、需要在只有不可變引用的前提下修改內(nèi)容。這三種需求分別對(duì)應(yīng)Box、Rc/Arc、Cell/RefCell。類型所有權(quán)模型線程安全運(yùn)行時(shí)開(kāi)銷典型場(chǎng)景BoxT獨(dú)占堆分配取決于 T一次分配遞歸結(jié)構(gòu)、trait 對(duì)象RcT共享非原子計(jì)數(shù)否每次克隆加減一單線程共享只讀數(shù)據(jù)ArcT共享原子計(jì)數(shù)是T: SendSync原子操作比 Rc 慢多線程共享CellT內(nèi)部可變按值替換否幾乎為零小 Copy 類型的可變狀態(tài)RefCellT內(nèi)部可變運(yùn)行時(shí)借用檢查否借用標(biāo)志位增減需要在 self 里改內(nèi)容選型的順序我一般是這樣的先問(wèn)是不是遞歸類型或需要 trait 對(duì)象是就上Box再問(wèn)是不是真的需要多個(gè)所有者如果只是讀取共享用Arc包只讀數(shù)據(jù)就夠了別急著上RefCell最后才問(wèn)是不是需要在不可變引用下修改需要才用RefCell。很多人一上來(lái)就寫RcRefCellT其實(shí)八成場(chǎng)景用RcT或者干脆傳引用就能解決白白引入了運(yùn)行時(shí)開(kāi)銷和 panic 風(fēng)險(xiǎn)。4.2 Rc 加 RefCell 的代價(jià)具體在哪RcT的每次clone都要對(duì)引用計(jì)數(shù)做一次加一每次drop做一次減一減到零才釋放。這些操作在單線程里是普通的整數(shù)加減開(kāi)銷很小但不為零。RefCellT則維護(hù)一個(gè)借用計(jì)數(shù)器borrow()時(shí)檢查當(dāng)前有沒(méi)有可變借用有就 panicborrow_mut()時(shí)檢查計(jì)數(shù)器是不是零不是零也 panic。這兩個(gè)檢查都是運(yùn)行時(shí)分支編譯器沒(méi)法優(yōu)化掉。更需要注意的是循環(huán)引用導(dǎo)致的內(nèi)存泄漏。兩個(gè)Rc互相指向引用計(jì)數(shù)永遠(yuǎn)不會(huì)歸零內(nèi)存就漏了。標(biāo)準(zhǔn)解法是把其中一個(gè)方向改成Weakuse std::cell::RefCell; use std::rc::{Rc, Weak}; struct Node { value: i32, next: OptionRcRefCellNode, prev: OptionWeakRefCellNode, // 用 Weak 打破環(huán) } fn main() { let a Rc::new(RefCell::new(Node { value: 1, next: None, prev: None })); let b Rc::new(RefCell::new(Node { value: 2, next: None, prev: Some(Rc::downgrade(a)) })); a.borrow_mut().next Some(Rc::clone(b)); println!(a 的強(qiáng)引用數(shù): {}, Rc::strong_count(a)); println!(a 的弱引用數(shù): {}, Rc::weak_count(a)); }Weak不增加強(qiáng)引用計(jì)數(shù)升級(jí)成Rc的時(shí)候要調(diào)upgrade()返回Option因?yàn)槟繕?biāo)可能已經(jīng)被釋放了。這個(gè)模式在雙向鏈表、樹(shù)結(jié)構(gòu)里都會(huì)用到我建議只要結(jié)構(gòu)里出現(xiàn)“指回去”的邊就默認(rèn)用Weak不要等到內(nèi)存漲上去才回頭改。4.3 有時(shí)候該退一步換數(shù)據(jù)結(jié)構(gòu)而不是堆智能指針這是我踩過(guò)的最大的一個(gè)坑。早期寫一個(gè)圖結(jié)構(gòu)的處理邏輯習(xí)慣性地用RcRefCellNode表示每個(gè)節(jié)點(diǎn)節(jié)點(diǎn)之間互相引用。代碼能跑但性能很差而且一旦涉及并發(fā)就完全沒(méi)法用因?yàn)镽c根本不是Send。后來(lái)改成用VecNode存所有節(jié)點(diǎn)節(jié)點(diǎn)之間用usize索引互相引用性能提升非常明顯代碼也短了。struct Graph { nodes: VecNode, } struct Node { edges: Vecusize, // 索引而不是引用 }索引方案的代價(jià)是你得自己保證索引有效刪節(jié)點(diǎn)的時(shí)候要處理懸空索引。但它換來(lái)的是連續(xù)的堆布局、零引用計(jì)數(shù)開(kāi)銷、天然的Send Sync而且序列化也簡(jiǎn)單得多。我現(xiàn)在的判斷標(biāo)準(zhǔn)是如果一個(gè)數(shù)據(jù)結(jié)構(gòu)里RcRefCell出現(xiàn)超過(guò)兩處就該停下來(lái)想想是不是該用索引或者 arena 了。5. 一個(gè)真實(shí)場(chǎng)景的重構(gòu)從編譯不過(guò)到跑得穩(wěn)5.1 需求解析文本并緩存字段假設(shè)要寫一個(gè)小模塊從多行文本里解析出鍵值對(duì)緩存起來(lái)供后續(xù)查詢。第一版我圖省事直接讓結(jié)構(gòu)體持有輸入的切片struct Configa { entries: Vec(a str, a str), } impla Configa { fn parse(input: a str) - Self { let mut entries Vec::new(); for line in input.lines() { if let Some((k, v)) line.split_once() { entries.push((k.trim(), v.trim())); } } Config { entries } } fn get(self, key: str) - Optiona str { self.entries.iter().find(|(k, _)| *k key).map(|(_, v)| *v) } }這段代碼能編譯get返回的引用直接指向原始輸入零拷貝速度很快。問(wèn)題出在調(diào)用方那邊一旦把input的所有權(quán)交出去或者input是函數(shù)內(nèi)部臨時(shí)構(gòu)造的String就出事了。5.2 第一版在真實(shí)調(diào)用鏈里崩了調(diào)用方大概是這樣的fn load() - Configstatic { let content std::fs::read_to_string(config.txt).unwrap(); Config::parse(content) // 報(bào)錯(cuò)返回引用了局部變量 }編譯器報(bào) E0515說(shuō)不能返回指向局部變量的引用。這不是編譯器的刁難content在函數(shù)結(jié)束時(shí)就 drop 了返回的Config里那些指針會(huì)立刻變成懸垂指針。如果這段代碼在 C 里寫編譯能過(guò)運(yùn)行時(shí)讀到的就是垃圾數(shù)據(jù)而且可能好幾個(gè)月都不出問(wèn)題直到某次內(nèi)存布局變化才突然炸。第二版我把結(jié)構(gòu)體改成持有Stringstruct Config { entries: Vec(String, String), } impl Config { fn parse(input: str) - Self { let mut entries Vec::new(); for line in input.lines() { if let Some((k, v)) line.split_once() { entries.push((k.trim().to_string(), v.trim().to_string())); } } Config { entries } } fn get(self, key: str) - Optionstr { self.entries.iter().find(|(k, _)| k key).map(|(_, v)| v.as_str()) } }這樣寫能跨函數(shù)傳遞、能存進(jìn)集合、能放進(jìn)Arc里共享代價(jià)是每個(gè)鍵值對(duì)兩次堆分配。對(duì)于配置文件這種一次性加載、長(zhǎng)期駐留的場(chǎng)景這個(gè)代價(jià)完全值得。但如果是解析大文件做流式處理每行兩次分配就有點(diǎn)浪費(fèi)了。5.3 第三版用 Cow 做折中Cow寫時(shí)克隆是這兩者之間的折中方案。它在不需要修改的時(shí)候借用原始數(shù)據(jù)需要修改的時(shí)候才分配use std::borrow::Cow; enum Entrya { Borrowed(a str), Owned(String), } fn normalize(s: str) - Cow_, str { if s.contains(\t) { Cow::Owned(s.replace(\t, )) } else { Cow::Borrowed(s) } }Cowa, str是標(biāo)準(zhǔn)庫(kù)提供的枚舉只有Borrowed和Owned兩個(gè)變體。它的好處是調(diào)用方不用關(guān)心底層到底是借用還是擁有用.as_ref()或Deref就能當(dāng)str用。壞處是它仍然帶著生命周期參數(shù)跨函數(shù)邊界的時(shí)候該傳播還得傳播而且枚舉本身占的?？臻g比單純的str大具體多大可以用size_of實(shí)測(cè)一下不同版本和優(yōu)化下會(huì)有差異。我現(xiàn)在的選擇順序是數(shù)據(jù)生命周期短、調(diào)用鏈淺用str加生命周期數(shù)據(jù)要被長(zhǎng)期持有、跨線程傳遞用String兩者之間搖擺不定的中型場(chǎng)景用Cow。這個(gè)順序不是教條但你照著走能少走彎路。6. 高頻報(bào)錯(cuò)與排查速查6.1 錯(cuò)誤碼對(duì)照表被借用檢查器攔住的時(shí)候先看錯(cuò)誤碼再看提示里的“誰(shuí)的借用還沒(méi)結(jié)束”。下面這張表是我整理的高頻錯(cuò)誤基本上覆蓋了日常八成的情況。錯(cuò)誤碼含義典型改法E0382使用了已經(jīng) move 的值改傳引用或在轉(zhuǎn)移前 cloneE0499同一作用域內(nèi)兩次可變借用拆分成兩個(gè)階段或用索引代替引用E0502可變借用與不可變借用沖突先讀后寫或縮短不可變借用的生命周期E0505借用還沒(méi)結(jié)束就要 move讓借用先結(jié)束再 moveE0515返回了局部變量的引用返回?fù)碛兴袡?quán)的類型E0597被借用的值活不到那么久調(diào)整作用域順序或改為擁有E0716臨時(shí)值在借用期間被釋放先用 let 綁定成變量再借用E0106缺少生命周期標(biāo)注按省略規(guī)則補(bǔ)上或改成擁有類型E0716 值得單獨(dú)提一句很多人寫過(guò)類似的代碼然后一臉茫然fn main() { // let s String::from(hello).as_str(); // 報(bào)錯(cuò) E0716 let tmp String::from(hello); // 先綁定成變量 let s tmp.as_str(); // 再借用 println!({}, s); }原因是String::from(hello)產(chǎn)生的臨時(shí)值在這一行結(jié)束時(shí)就被 drop 了as_str()借出來(lái)的引用立刻懸垂。先綁定到tmp之后tmp活到作用域結(jié)束借用才合法。這類問(wèn)題的排查思路很統(tǒng)一看那個(gè)被借用的值是不是臨時(shí)值是就給它一個(gè)名字。6.2 排查順序先找誰(shuí)借了誰(shuí)再看誰(shuí)要活多久我處理借用錯(cuò)誤的固定流程是這樣的。第一步看錯(cuò)誤提示里點(diǎn)名的變量確認(rèn)是“值被 move 了”還是“借用沖突”。第二步如果是借用沖突從報(bào)錯(cuò)位置往上找找最后一個(gè)使用這個(gè)引用的地方那里就是借用結(jié)束的位置。第三步如果想讓借用提前結(jié)束就把后面的寫操作挪到那之后或者把讀的結(jié)果先取出來(lái)存成獨(dú)立的值。第四步如果怎么調(diào)都不行說(shuō)明數(shù)據(jù)結(jié)構(gòu)的所有權(quán)模型設(shè)計(jì)有問(wèn)題考慮換成索引、Rc或者擁有類型。這個(gè)流程里第三步最常用。舉一個(gè)我經(jīng)常遇到的場(chǎng)景需要在HashMap里查一個(gè)值然后修改它use std::collections::HashMap; fn main() { let mut map: HashMapString, i32 HashMap::new(); map.insert(a.to_string(), 1); // let v map.get(a).unwrap(); // map.insert(b.to_string(), 2); // 報(bào)錯(cuò) E0502 // println!({}, v); let v map.get(a).copied().unwrap_or(0); // 先取值結(jié)束借用 map.insert(b.to_string(), 2); println!({}, v); }copied()把Optioni32變成Optioni32借用當(dāng)場(chǎng)結(jié)束后面的插入就自由了。這個(gè)技巧在處理哈希表、緩存的時(shí)候特別好用我基本養(yǎng)成了習(xí)慣只要借出來(lái)的值很小且 Copy先拷貝再用。6.3 幾條踩出來(lái)的實(shí)操心得第一別怕加花括號(hào)。雖然 NLL 已經(jīng)聰明很多但在某些復(fù)雜表達(dá)式里顯式劃一個(gè)作用域讓借用提前結(jié)束比絞盡腦汁調(diào)整順序省事得多。第二clone()不是洪水猛獸在冷路徑上用 clone 換代碼清晰度是完全劃算的我反對(duì)的是在熱循環(huán)里無(wú)意識(shí)地 clone。第三遇到RcRefCellT的borrow_mutpanic先找有沒(méi)有在同一段代碼里同時(shí)持有兩個(gè)借用尤其是鏈?zhǔn)秸{(diào)用里臨時(shí)值還沒(méi)釋放的情況把中間結(jié)果用let綁定出來(lái)往往就好了。第四函數(shù)簽名優(yōu)先用借用只有在確實(shí)需要保存或跨線程的時(shí)候才用擁有類型這條規(guī)則能讓你的模塊接口干凈很多。第五如果一段邏輯里到處都是unsafe或者反射式的類型轉(zhuǎn)換那多半不是所有權(quán)的問(wèn)題是數(shù)據(jù)結(jié)構(gòu)選錯(cuò)了回頭看看第 4.3 節(jié)。關(guān)于內(nèi)存管理我個(gè)人在實(shí)際操作中最深的一點(diǎn)體會(huì)是所有權(quán)系統(tǒng)真正改變的不是你寫代碼的語(yǔ)法而是你設(shè)計(jì)數(shù)據(jù)結(jié)構(gòu)的方式。寫 C 的時(shí)候我會(huì)自然地想“這塊內(nèi)存誰(shuí) free”寫 Java 的時(shí)候基本不想寫 Rust 之后我會(huì)在動(dòng)手寫第一行之前就想清楚“這個(gè)值的生命周期有多長(zhǎng)、誰(shuí)能改它、要不要共享”。這個(gè)思考前置的過(guò)程一開(kāi)始很別扭習(xí)慣之后反而省掉了大量調(diào)試時(shí)間因?yàn)楹芏鄦?wèn)題在敲代碼的時(shí)候就已經(jīng)被逼著想明白了。