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