1. 一次編譯失敗引出的問題所有權(quán)究竟在約束什么很多人第一次接觸 Rust 所有權(quán)系統(tǒng)都是被一段看起來(lái)毫無(wú)問題的代碼打臉的。我當(dāng)年的場(chǎng)景是這樣的寫了個(gè)函數(shù)把String傳進(jìn)去處理處理完還想在外面繼續(xù)用它編譯器直接甩出一行value borrowed here after move我當(dāng)時(shí)的第一反應(yīng)是這語(yǔ)言怎么連個(gè)字符串都不讓人好好用。后來(lái)才明白那條報(bào)錯(cuò)不是刁難而是所有權(quán)系統(tǒng)在替我提前擋住一次潛在的內(nèi)存錯(cuò)誤——同樣的邏輯放到手動(dòng)管理內(nèi)存的環(huán)境里可能就是一次 double free 或者懸垂指針跑一百次掛一次排查三天找不到原因。這篇筆記想聊清楚三件事Rust 所有權(quán)系統(tǒng)在內(nèi)存層面到底做了什么、它憑什么能在沒有運(yùn)行時(shí)垃圾回收的前提下保證內(nèi)存安全、以及落到實(shí)際編碼里怎么把這套規(guī)則用順手而不是被它牽著走。適合已經(jīng)能寫幾行 Rust、被借用檢查器反復(fù)教育過但還沒建立起完整心智模型的讀者也適合從其他語(yǔ)言轉(zhuǎn)過來(lái)、想搞清楚零成本抽象在內(nèi)存管理上具體指什么的人。下面的內(nèi)容會(huì)涉及一些棧和堆的底層細(xì)節(jié)但不需要你懂匯編能看懂變量在內(nèi)存里大概長(zhǎng)什么樣就夠了。1.1 String 在內(nèi)存里的真實(shí)樣子要理解 move先得看清楚一個(gè)String到底占多少地方。在 64 位平臺(tái)上String由三個(gè)字段組成一個(gè)指向堆內(nèi)存的指針ptr8 字節(jié)、一個(gè)表示當(dāng)前長(zhǎng)度的len8 字節(jié)、一個(gè)表示已分配容量的capacity8 字節(jié)。這三個(gè)字段本身存放在棧上合計(jì) 24 字節(jié)真正裝字符的那塊緩沖區(qū)在堆上由分配器管理。這個(gè)結(jié)構(gòu)決定了后面所有行為的基調(diào)棧上的那 24 字節(jié)是描述符堆上的緩沖區(qū)才是實(shí)體。當(dāng)你寫下let s2 s1;的時(shí)候Rust 做的事情是把這 24 字節(jié)按位復(fù)制給s2然后立刻把s1標(biāo)記為不可用。注意堆上那塊緩沖區(qū)一次都沒有被復(fù)制也沒有被重新分配。這就是所謂 move 的真相——它不是搬家而是過戶。fn main() { let s1 String::from(hello); let s2 s1; // 24 字節(jié)的描述符被復(fù)制s1 失效 println!({}, s2); // 正常 // println!({}, s1); // 去掉注釋就報(bào)錯(cuò)borrow of moved value }為什么非要讓s1失效因?yàn)槿绻试S兩個(gè)描述符同時(shí)指向同一塊堆內(nèi)存那么當(dāng)它們各自離開作用域時(shí)都會(huì)嘗試釋放這塊內(nèi)存第二次釋放就是操作已釋放的內(nèi)存——這就是經(jīng)典的 double free。C 里拷貝構(gòu)造和析構(gòu)的配合稍微寫錯(cuò)一點(diǎn)就會(huì)踩這個(gè)坑Rust 選擇在編譯期直接把這條路堵死同一塊堆內(nèi)存同一時(shí)刻只能有一個(gè)所有者。1.2 三條規(guī)則翻譯成工程語(yǔ)言教科書上通常會(huì)給三條規(guī)則每個(gè)值有且只有一個(gè)所有者同一時(shí)刻只能有一個(gè)所有者所有者離開作用域時(shí)值被丟棄。這三句話背起來(lái)很容易但真正有用的是把它們翻譯成寫代碼時(shí)的判斷依據(jù)。第一條規(guī)則的工程含義是誰(shuí)創(chuàng)建誰(shuí)負(fù)責(zé)收尾。你在函數(shù)里String::from出來(lái)的東西如果沒被移交給別人函數(shù)結(jié)束時(shí)它就被釋放。這讓你不需要在每一條提前返回的分支上補(bǔ)釋放語(yǔ)句也不需要在出錯(cuò)路徑上小心翼翼地對(duì)齊資源清理邏輯。第二條規(guī)則管的是并發(fā)和別名安全。只有一個(gè)所有者意味著沒有別人能偷偷把這塊內(nèi)存釋放掉或者改寫掉。這是 Rust 在編譯期就能給出內(nèi)存安全保證的根基——不是靠運(yùn)行時(shí)檢查而是靠根本不存在第二個(gè)能改它的人。第三條規(guī)則定義了釋放時(shí)機(jī)作用域結(jié)束確定析構(gòu)。這一點(diǎn)后面還會(huì)展開因?yàn)樗屠厥兆畋举|(zhì)的區(qū)別就在這里——GC 的回收時(shí)機(jī)是不確定的你可能申請(qǐng)了一塊內(nèi)存程序跑了十分鐘才回收它而 Rust 的釋放時(shí)機(jī)在編譯期就已經(jīng)寫在作用域邊界上了。1.3 為什么不用 GC 也能保證安全很多人會(huì)問既然有所有權(quán)那是不是等于把內(nèi)存管理的活兒從運(yùn)行時(shí)搬到了編譯期這個(gè)理解方向?qū)Φ粔驕?zhǔn)確。更貼切的說法是Rust 把內(nèi)存什么時(shí)候可以安全釋放這個(gè)問題轉(zhuǎn)化成了這段代碼能不能通過類型檢查這個(gè)問題。編譯器不需要知道程序運(yùn)行時(shí)到底走哪條分支它只需要在每一條可能的路徑上都驗(yàn)證沒有任何一個(gè)值的生命周期超過它的所有者沒有任何一個(gè)引用在使用時(shí)指向已經(jīng)失效的內(nèi)存。驗(yàn)證通過就生成代碼驗(yàn)證不過就報(bào)錯(cuò)。運(yùn)行時(shí)沒有任何額外的簿記開銷——不掃描對(duì)象圖不維護(hù)引用計(jì)數(shù)除非你顯式用了Rc不暫停程序。代價(jià)自然也有編譯期要做的推理更重編譯速度慢于同等規(guī)模的 C 代碼更重要的是程序員需要把數(shù)據(jù)的所有權(quán)歸屬想清楚才能寫出能編譯的代碼。這不是語(yǔ)法問題是設(shè)計(jì)問題。我見過不少人卡在這一步本質(zhì)上是習(xí)慣了到處都能拿到引用的寫法一時(shí)轉(zhuǎn)不過彎。2. 棧、堆與 Copy 的邊界所有權(quán)只對(duì)有主之物較真剛上手時(shí)最容易產(chǎn)生的困惑是為什么let a 1; let b a;之后a還能用而String就不行如果所有權(quán)是鐵律為什么整數(shù)有特權(quán)答案藏在數(shù)據(jù)放在哪兒這個(gè)更底層的問題里——所有權(quán)系統(tǒng)并不是對(duì)所有類型一視同仁它對(duì)擁有堆資源的類型格外嚴(yán)格。2.1 棧上數(shù)據(jù)的復(fù)制是廉價(jià)的i32占 4 個(gè)字節(jié)全部在棧上復(fù)制這 4 個(gè)字節(jié)的成本和復(fù)制一個(gè)指針差不多而且復(fù)制完之后兩個(gè)變量各自獨(dú)立誰(shuí)也不會(huì)影響誰(shuí)。對(duì)于這類類型move 和 copy 在機(jī)器碼層面沒有區(qū)別既然沒有區(qū)別就沒有必要禁止原變量繼續(xù)使用。這就是Copytrait 的作用它告訴編譯器這個(gè)類型按位復(fù)制之后新舊兩份都是完整有效的不需要轉(zhuǎn)移所有權(quán)。基本數(shù)值類型、bool、char、以及由Copy類型組成的元組和數(shù)組都實(shí)現(xiàn)了Copy。let a 42; let b a; println!({} {}, a, b); // 都能用因?yàn)?i32: Copy let t1 (1, 2, 3); let t2 t1; println!({:?}, t1); // 元組里全是 Copy 類型所以 t1 仍然有效這里有個(gè)容易忽略的細(xì)節(jié)Copy不是自動(dòng)推導(dǎo)的。如果你自己定義了一個(gè)結(jié)構(gòu)體哪怕它所有字段都是i32默認(rèn)也不實(shí)現(xiàn)Copy需要顯式#[derive(Copy, Clone)]。這個(gè)設(shè)計(jì)很克制——因?yàn)橐坏?shí)現(xiàn)了Copy就意味著這個(gè)類型可以被隱式復(fù)制如果這個(gè)類型將來(lái)加了析構(gòu)邏輯比如實(shí)現(xiàn)了Drop就會(huì)產(chǎn)生語(yǔ)義沖突編譯器會(huì)直接禁止。注意實(shí)現(xiàn)了Drop的類型不能同時(shí)實(shí)現(xiàn)Copy。這不是限制是保護(hù)。你不可能既想讓編譯器悄悄復(fù)制一份又想在銷毀時(shí)執(zhí)行自定義邏輯。2.2 Copy 與 Clone 不是同義詞這兩個(gè) trait 經(jīng)常被混為一談但它們的語(yǔ)義差得很遠(yuǎn)。Copy是隱式的、按位的、廉價(jià)的編譯器會(huì)在賦值、傳參、返回時(shí)自動(dòng)插入復(fù)制。Clone是顯式的你必須手寫.clone()而且它可能非常昂貴——VecString的clone會(huì)把里面每一個(gè)String的堆緩沖區(qū)都重新分配一遍。let v1 vec![String::from(a), String::from(b)]; let v2 v1.clone(); // 顯式深拷貝堆上重新分配了三塊內(nèi)存 println!({}, v1.len()); // v1 依然有效我在代碼審查里見過不少.clone()被當(dāng)成消除借用檢查報(bào)錯(cuò)的萬(wàn)能藥來(lái)用。短期確實(shí)能讓代碼編譯過去但如果在熱路徑上對(duì)一個(gè)幾千元素的Vec無(wú)腦 clone性能會(huì)掉得很難看。判斷標(biāo)準(zhǔn)很簡(jiǎn)單如果這個(gè) clone 之后原變量就不再使用了那大概率應(yīng)該改成 move如果兩個(gè)變量確實(shí)要各自獨(dú)立演化那 clone 才有正當(dāng)性。2.3 函數(shù)簽名就是所有權(quán)契約函數(shù)參數(shù)是最能體現(xiàn)所有權(quán)設(shè)計(jì)意圖的地方?？聪旅孢@三種寫法它們對(duì)調(diào)用者的約束完全不同fn take_ownership(s: String) { /* s 在函數(shù)結(jié)束時(shí)被釋放 */ } fn borrow(s: str) - usize { s.len() } fn give_back(s: String) - String { s }第一種調(diào)用者傳進(jìn)去之后就不能再用了所有權(quán)徹底移交。第二種只讀借用調(diào)用者傳s或者直接傳字符串字面量都行函數(shù)內(nèi)部改不了內(nèi)容。第三種最啰嗦接收所有權(quán)再還回來(lái)實(shí)際上等價(jià)于我要修改它但我懶得寫借用——除非確實(shí)需要消耗掉再重建否則應(yīng)該寫成fn modify(s: mut String)。選哪種不是風(fēng)格問題是接口契約問題。參數(shù)寫成String就意味著調(diào)用方要么放棄這個(gè)值要么自己先 clone 一份。參數(shù)寫成str調(diào)用方傳什么都行——String會(huì)自動(dòng)解引用成str字符串字面量static str也能直接用。這就是為什么庫(kù)函數(shù)里常見impl AsRefstr或者str這樣的簽名接收方越寬容調(diào)用方越省事。3. 借用檢查器怎么推理從詞法作用域到 NLL所有權(quán)解決了誰(shuí)負(fù)責(zé)釋放但光有所有權(quán)寫不了實(shí)際代碼——你總得讓別人臨時(shí)看一眼數(shù)據(jù)。借用borrowing就是為此存在的而借用檢查器則是整個(gè)體系里最容易被誤解的部分。很多人以為它是作用域級(jí)別的檢查這個(gè)印象在 Rust 2015 時(shí)代勉強(qiáng)成立從 2018 edition 引入 NLL 之后就已經(jīng)不準(zhǔn)確了。3.1 借用規(guī)則的本質(zhì)是讀寫沖突檢測(cè)兩條借用規(guī)則同一時(shí)刻要么有任意多個(gè)不可變借用要么有唯一一個(gè)可變借用。翻譯成大白話就是要么大家一起看要么一個(gè)人改不能邊看邊改。為什么這條規(guī)則能防住內(nèi)存錯(cuò)誤想想 C 里那個(gè)經(jīng)典陷阱拿到vector的迭代器然后往里面push_back容器擴(kuò)容導(dǎo)致底層緩沖區(qū)重新分配原來(lái)那個(gè)迭代器指向的內(nèi)存已經(jīng)被釋放后續(xù)解引用就是未定義行為。這類 bug 在 C 里極其隱蔽因?yàn)樗辉谌萘縿偤貌粔颉⒂|發(fā)擴(kuò)容時(shí)才出現(xiàn)測(cè)試環(huán)境數(shù)據(jù)量小的時(shí)候根本復(fù)現(xiàn)不了。Rust 在編譯期就把這種可能性排除了let mut v vec![1, 2, 3]; let first v[0]; // 不可變借用 v.push(4); // 需要可變借用沖突 println!({}, first);編譯器會(huì)告訴你不可變借用還活著的時(shí)候不能對(duì)v做可變借用。如果你把println!刪掉讓first在push之前就不再使用那么這段代碼反而能編譯通過——這正是 NLL 帶來(lái)的變化。3.2 NLL 改變了什么NLL 全稱是 Non-Lexical Lifetimes核心變化是借用的生命周期在它最后一次被使用的地方結(jié)束而不是在它所在的作用域結(jié)束時(shí)結(jié)束。這個(gè)變化看起來(lái)只是編譯器變聰明了實(shí)際對(duì)寫代碼的體驗(yàn)影響巨大。let mut data vec![1, 2, 3]; let r data[0]; println!({}, r); // r 最后一次使用 data.push(4); // 在舊規(guī)則下這里會(huì)報(bào)錯(cuò)NLL 下完全合法在舊規(guī)則里r的借用一直持續(xù)到整個(gè)函數(shù)塊結(jié)束push必然沖突。NLL 下編譯器看的是數(shù)據(jù)流r在println!之后就再也沒被用過借用提前結(jié)束后面的可變操作自然就沒問題了。這個(gè)特性對(duì)初學(xué)者的意義在于很多以前必須靠額外花括號(hào)或者克隆才能繞過去的寫法現(xiàn)在直接寫就行。不過也別指望編譯器無(wú)所不能——一旦借用跨越了控制流分支、或者被存進(jìn)了結(jié)構(gòu)體、或者被閉包捕獲分析難度就會(huì)上升報(bào)錯(cuò)依然會(huì)出現(xiàn)。遇到這種情況先想清楚這個(gè)引用最長(zhǎng)要活到哪一行問題通常就清楚了。3.3 三個(gè)高頻報(bào)錯(cuò)的拆解路徑我整理了一下自己踩過和幫別人看過最多的三類借用報(bào)錯(cuò)它們的排查思路并不相同。第一類是cannot borrow as mutable because it is also borrowed as immutable。上文那個(gè)vec的例子就是典型。處理方法是把讀操作和寫操作在時(shí)間上錯(cuò)開——先取值再改容器。如果是循環(huán)里同時(shí)讀寫考慮收集一份索引或者用split_at_mut拆分借用。第二類是returns a value referencing data owned by the current function。這個(gè)報(bào)錯(cuò)的意思是函數(shù)試圖返回一個(gè)指向函數(shù)內(nèi)部局部變量的引用函數(shù)一返回那個(gè)局部變量就被銷毀了返回的引用立刻變成懸垂引用。解法有兩條要么返回所有權(quán)String而不是str要么這個(gè)引用的來(lái)源必須是參數(shù)傳進(jìn)來(lái)的——參數(shù)的生命周期比函數(shù)體長(zhǎng)。第三類是cannot move out of ... which is behind a shared reference。想從Struct里把一個(gè)字段移出來(lái)不允許。因?yàn)橐谱咧笤Y(jié)構(gòu)體就殘缺了而別人還持有它的引用。解法是用clone復(fù)制一份或者用std::mem::take/Option::take把字段替換成默認(rèn)值。提示讀報(bào)錯(cuò)信息時(shí)重點(diǎn)看編譯器給出的help部分它經(jīng)常直接告訴你consider borrowing here或者consider cloning。但要注意編譯器給的建議是能編譯的建議不一定是最優(yōu)解。.clone()能讓報(bào)錯(cuò)消失但性能賬還得自己算。4. 與傳統(tǒng)內(nèi)存管理的正面比較聊所有權(quán)系統(tǒng)的價(jià)值放到對(duì)比里最清楚。常見的三種內(nèi)存管理路線手動(dòng)管理、追蹤式垃圾回收、所有權(quán)加 RAII。它們各自的取舍差別很大沒有哪一種在所有場(chǎng)景下都占優(yōu)但如果只做單方面宣傳就容易失真。管理方式釋放時(shí)機(jī)運(yùn)行時(shí)開銷典型風(fēng)險(xiǎn)手動(dòng) malloc/free由程序員顯式調(diào)用幾乎為零懸垂指針、重復(fù)釋放、內(nèi)存泄漏、忘記對(duì)齊追蹤式 GC對(duì)象不可達(dá)后由回收器決定掃描開銷、可能的暫停內(nèi)存放大、停頓抖動(dòng)、回收時(shí)機(jī)不可控所有權(quán) RAII所有者離開作用域編譯期確定無(wú)額外運(yùn)行時(shí)簿記學(xué)習(xí)曲線、循環(huán)引用需手動(dòng)打破、編譯期負(fù)擔(dān)4.1 手動(dòng)管理與追蹤式回收的代價(jià)手動(dòng)管理的優(yōu)點(diǎn)是極致可控。什么時(shí)候釋放、在哪里釋放、要不要池化全由你決定沒有黑箱。缺點(diǎn)是把正確性完全押在人的注意力上——一段有三四十個(gè)提前返回分支的函數(shù)只要有一條分支忘了釋放就是內(nèi)存泄漏如果兩條分支釋放了同一塊內(nèi)存就是未定義行為而且這種 bug 往往在壓力測(cè)試下才暴露。追蹤式回收把正確性從人手里接管過來(lái)代價(jià)是運(yùn)行時(shí)的不確定性。回收器需要在某個(gè)時(shí)刻掃描存活對(duì)象這個(gè)過程可能造成暫停即使做了增量回收和并發(fā)標(biāo)記內(nèi)存占用的峰值通常還是高于手動(dòng)管理因?yàn)閷?duì)象在被證明不可達(dá)之前都不能被回收。對(duì)于延遲敏感的場(chǎng)景回收帶來(lái)的抖動(dòng)是需要認(rèn)真評(píng)估的因素。Rust 走的第三條路如果編譯器能在編譯期證明這塊內(nèi)存在某個(gè)點(diǎn)之后不可能再被使用那就直接在那個(gè)點(diǎn)插入釋放指令。作用域結(jié)束就是這樣一個(gè)點(diǎn)因?yàn)樗袡?quán)規(guī)則保證了沒有任何引用能活過作用域邊界。這樣既沒有回收器的運(yùn)行時(shí)開銷也不需要程序員手動(dòng)寫釋放語(yǔ)句。4.2 Drop 的確定性與析構(gòu)順序Droptrait 是這個(gè)模型落地的關(guān)鍵。實(shí)現(xiàn)Drop的類型在所有者離開作用域時(shí)自動(dòng)調(diào)用drop方法。這個(gè)調(diào)用的時(shí)機(jī)是確定的、可預(yù)測(cè)的和 GC 那種遲早會(huì)回收完全不同。struct Guard(static str); impl Drop for Guard { fn drop(mut self) { println!(releasing {}, self.0); } } fn main() { let _a Guard(a); let _b Guard(b); // 輸出順序releasing b、releasing a }局部變量的析構(gòu)順序是聲明的逆序也就是后進(jìn)先出。這個(gè)規(guī)則和棧的自然結(jié)構(gòu)一致也很符合直覺后創(chuàng)建的對(duì)象可能依賴先創(chuàng)建的對(duì)象所以要先銷毀。而結(jié)構(gòu)體內(nèi)部的字段析構(gòu)順序是聲明順序從前往后——這一點(diǎn)和局部變量相反我第一次遇到時(shí)也愣了一下后來(lái)想通了字段按聲明順序析構(gòu)可以保證先聲明的字段先失效后聲明的字段如果持有對(duì)前面字段的引用雖然安全 Rust 里很難構(gòu)造也不會(huì)出現(xiàn)引用懸垂。這個(gè)確定性在資源管理上價(jià)值巨大。文件句柄、網(wǎng)絡(luò)連接、鎖守衛(wèi)、臨時(shí)目錄這些資源都可以包在實(shí)現(xiàn)了Drop的類型里靠作用域自動(dòng)釋放。哪怕函數(shù)中途panic棧展開過程依然會(huì)調(diào)用析構(gòu)函數(shù)除非編譯選項(xiàng)關(guān)閉了展開。這套 RAII 模式在 C 里已經(jīng)驗(yàn)證了幾十年Rust 把它和所有權(quán)綁定得更緊——因?yàn)樗袡?quán)唯一所以析構(gòu)只會(huì)執(zhí)行一次天然不會(huì)重復(fù)釋放。4.3 循環(huán)引用所有權(quán)模型的盲區(qū)所有權(quán)不是銀彈它有一個(gè)明確的盲區(qū)環(huán)形結(jié)構(gòu)。如果 A 持有 BB 又持有 A那么兩者的引用計(jì)數(shù)永遠(yuǎn)不歸零誰(shuí)也沒法釋放誰(shuí)。在單所有權(quán)模型下這個(gè)問題更直接——你根本無(wú)法同時(shí)讓兩個(gè)對(duì)象互相擁有對(duì)方因?yàn)樗袡?quán)唯一。標(biāo)準(zhǔn)庫(kù)給出的方案是Rc加Weak。RcT是引用計(jì)數(shù)指針允許多個(gè)所有者共享同一份數(shù)據(jù)WeakT是弱引用它指向數(shù)據(jù)但不增加計(jì)數(shù)訪問時(shí)需要先upgrade檢查數(shù)據(jù)是否還活著。打破循環(huán)的做法就是強(qiáng)引用指一個(gè)方向弱引用指反方向。use std::rc::{Rc, Weak}; use std::cell::RefCell; struct Node { next: OptionRcRefCellNode, prev: OptionWeakRefCellNode, // 反向用 Weak不增加計(jì)數(shù) }需要強(qiáng)調(diào)的是Rc已經(jīng)偏離了零成本的范疇——每次克隆和丟棄都要修改計(jì)數(shù)而且計(jì)數(shù)器本身是普通的整數(shù)多線程環(huán)境下不安全所以多線程場(chǎng)景得換Arc代價(jià)是原子操作。我個(gè)人的經(jīng)驗(yàn)是能用樹形結(jié)構(gòu)表達(dá)的關(guān)系盡量別做成圖一旦引入RcRefCellT代碼的可讀性和性能都會(huì)下降而且運(yùn)行時(shí)的借用檢查RefCell在運(yùn)行期檢查借用規(guī)則違規(guī)直接 panic把編譯期保障也削弱了一部分。5. 把所有權(quán)用出性能幾個(gè)能落地的寫法理解了規(guī)則接下來(lái)是實(shí)操層面。所有權(quán)系統(tǒng)不只是安全保證它同時(shí)也是一份性能設(shè)計(jì)指南——很多寫法之所以能過編譯恰恰說明它在內(nèi)存上是高效的。5.1 傳參用引用還是 move判斷標(biāo)準(zhǔn)我總結(jié)成一句話看這個(gè)值在調(diào)用之后還有沒有用。如果沒用直接 move零成本如果還要用就借用避免復(fù)制。fn process(data: Vecu8) - usize { data.len() } let buf vec![0u8; 1024]; let n process(buf); // buf 被 move 走了之后的代碼不能再用它這個(gè)寫法乍看別扭但在管道式的代碼里非常自然數(shù)據(jù)從上游流向下游每一站都消費(fèi)掉上一站的產(chǎn)物全程沒有一次多余的復(fù)制。如果確實(shí)要保留傳[u8]就行fn process(data: [u8]) - usize { data.len() } let n process(buf); println!({}, buf.len()); // 還能用這里有個(gè)細(xì)節(jié)值得說Vecu8和[u8]在函數(shù)參數(shù)位置上后者更通用。因?yàn)閂ecT可以自動(dòng)解引用成[T]但反過來(lái)不行數(shù)組和切片就沒法傳。寫庫(kù)的時(shí)候養(yǎng)成參數(shù)盡量用切片、用str的習(xí)慣調(diào)用方的體驗(yàn)會(huì)好很多。5.2 讓編譯器替你決定Cow 與 AsRef有些場(chǎng)景你不確定到底需不需要復(fù)制——輸入可能本來(lái)就是想要的格式只需要原樣返回也可能是別的格式得轉(zhuǎn)換一下。這時(shí)候CowClone on Write就派上用場(chǎng)了。use std::borrow::Cow; fn normalize(input: str) - Cowstr { if input.contains( ) { Cow::Owned(input.replace( , _)) // 需要改分配新內(nèi)存 } else { Cow::Borrowed(input) // 不用改零成本 } }返回類型Cowstr表示可能借用也可能擁有。調(diào)用方可以把它當(dāng)str用實(shí)現(xiàn)了Deref只有確實(shí)需要所有權(quán)時(shí)才調(diào)用into_owned()。這個(gè)模式在解析、文本處理、配置讀取里非常實(shí)用——大部分情況下輸入是干凈的走借用分支一次堆分配都不需要。AsRef則是另一個(gè)方向的寬容。函數(shù)簽名寫成fn openP: AsRefPath(path: P)調(diào)用方傳str、String、PathBuf、Path都行不需要手動(dòng)轉(zhuǎn)換。這類泛型簽名會(huì)讓編譯產(chǎn)物略微膨脹單態(tài)化但換來(lái)的調(diào)用便利性通常值得。5.3 結(jié)構(gòu)體設(shè)計(jì)的取舍最后聊聊結(jié)構(gòu)體。新手常犯的一個(gè)錯(cuò)是不管三七二十一字段全用引用然后被生命周期標(biāo)注折磨得死去活來(lái)。// 不推薦一開始就上生命周期 struct Configa { name: a str, path: a str, }這個(gè)結(jié)構(gòu)體只要被存儲(chǔ)、被返回、被放進(jìn)集合生命周期標(biāo)注就會(huì)像藤蔓一樣蔓延到所有用到它的地方。我的建議是先讓結(jié)構(gòu)體擁有數(shù)據(jù)用String、Vec等性能分析真的指出這里是瓶頸再考慮改成借用。一個(gè)Config結(jié)構(gòu)體多幾次分配對(duì)大多數(shù)程序來(lái)說完全可以接受而開發(fā)效率的損失是實(shí)打?qū)嵉?。另一種情況是字段很多但大部分時(shí)候只讀。這時(shí)候可以用ArcInner把一堆字段包起來(lái)克隆結(jié)構(gòu)體時(shí)只增加一次引用計(jì)數(shù)而不是深拷貝所有字段。這在配置共享、上下文傳遞的場(chǎng)景里非常常見代價(jià)是訪問字段時(shí)多一層間接尋址以及Arc的原子操作開銷。還有個(gè)小技巧值得提BoxT的大小固定是一個(gè)指針8 字節(jié)把大結(jié)構(gòu)體裝箱之后移動(dòng)它的成本從復(fù)制整個(gè)結(jié)構(gòu)體降到復(fù)制一個(gè)指針。如果一個(gè)結(jié)構(gòu)體有幾百字節(jié)又要在Vec里頻繁移動(dòng)裝箱能顯著減少memcpy的量。這也是所有權(quán)模型的一個(gè)副產(chǎn)品——因?yàn)?move 的語(yǔ)義是轉(zhuǎn)移而非復(fù)制編譯器在某些情況下可以直接在原地構(gòu)造避免中間臨時(shí)對(duì)象的產(chǎn)生。6. 幾個(gè)我真正踩過的坑和對(duì)應(yīng)的改法理論講完說點(diǎn)實(shí)戰(zhàn)里反復(fù)出現(xiàn)的問題。這些坑在文檔里往往一句話帶過但真遇上時(shí)能卡你半天。第一個(gè)坑是閉包捕獲。閉包默認(rèn)按需捕獲——只讀就按引用捕獲要改就按可變引用捕獲要 move 就按值捕獲。如果你把一個(gè)閉包傳給新線程編譯器會(huì)要求move于是整個(gè)環(huán)境都被搬進(jìn)閉包外面的變量立刻失效。let data vec![1, 2, 3]; let handle std::thread::spawn(move || { println!({:?}, data); }); handle.join().unwrap(); // println!({:?}, data); // 報(bào)錯(cuò)data 已經(jīng)被 move 進(jìn)閉包如果確實(shí)需要主線程和子線程共享數(shù)據(jù)別用move硬搬改用Arc包一層再克隆進(jìn)閉包?？寺rc只增加計(jì)數(shù)兩個(gè)線程都能訪問同一份數(shù)據(jù)。第二個(gè)坑是迭代器里的借用沖突。想在遍歷的同時(shí)修改容器這條在安全 Rust 里就是走不通的。正確做法是先把要改的索引收集起來(lái)遍歷結(jié)束后統(tǒng)一處理或者用retain、drain這類專門為邊遍歷邊修改設(shè)計(jì)的 API。let mut v vec![1, 2, 3, 4]; v.retain(|x| x % 2 0); // 內(nèi)部已經(jīng)處理好借用關(guān)系第三個(gè)坑是返回引用的函數(shù)。寫fn get_name(self) - str是沒問題的因?yàn)榉祷氐囊媒壎ㄔ趕elf的生命周期上。但如果函數(shù)里創(chuàng)建了一個(gè)新的String想返回它的切片編譯器一定攔你——那個(gè)String在函數(shù)返回時(shí)就沒了。這時(shí)候只能返回String把所有權(quán)交給調(diào)用方。注意static str只適用于編譯期就確定的字面量或者Box::leak出來(lái)永不釋放的內(nèi)存。別為了讓報(bào)錯(cuò)消失隨手加static那是把內(nèi)存泄漏寫進(jìn)類型簽名里。第四個(gè)坑和RefCell有關(guān)。它在運(yùn)行時(shí)執(zhí)行借用檢查違規(guī)不是編譯錯(cuò)誤而是panic。我遇到過一次在同一個(gè)作用域里先borrow_mut()拿到可變借用然后調(diào)用的函數(shù)內(nèi)部又嘗試borrow()程序直接崩了報(bào)錯(cuò)信息指向的是RefCell內(nèi)部跟業(yè)務(wù)邏輯毫無(wú)關(guān)系排查花了不少時(shí)間。后來(lái)養(yǎng)成的習(xí)慣是RefCell的借用盡量短拿到值就盡快drop掉守衛(wèi)別讓它在整個(gè)函數(shù)體里掛著。最后一個(gè)經(jīng)驗(yàn)是關(guān)于閱讀編譯器報(bào)錯(cuò)的心態(tài)。Rust 的報(bào)錯(cuò)信息質(zhì)量在所有語(yǔ)言里都算靠前的它會(huì)畫出借用開始和沖突的兩處位置會(huì)給出修改建議。我現(xiàn)在的習(xí)慣是先不看具體代碼只看它指出的兩個(gè)位置問自己這兩行之間這個(gè)數(shù)據(jù)的讀寫關(guān)系到底是什么。想清楚了改法自然就有了。反過來(lái)如果只是照著建議加clone加mut同類問題會(huì)在別的地方反復(fù)出現(xiàn)。7. 什么時(shí)候該繞開所有權(quán)邊界情況的判斷最后聊一個(gè)容易被忽略的話題所有權(quán)系統(tǒng)不是萬(wàn)能的有些場(chǎng)景下硬套反而更糟。最典型的是圖形界面和場(chǎng)景圖這類天然存在環(huán)形引用的結(jié)構(gòu)父子節(jié)點(diǎn)互相引用是常態(tài)。這類代碼如果用純安全 Rust 寫會(huì)被RcRefCell和各種運(yùn)行時(shí)借用檢查攪得很亂。這時(shí)候可以考慮用索引代替引用——所有節(jié)點(diǎn)存在一個(gè)Vec里節(jié)點(diǎn)之間用usize下標(biāo)互相指向。這樣做繞開了借用檢查器但代價(jià)是失去了一部分編譯期保障下標(biāo)的有效性得自己保證。業(yè)界不少成熟的做法就是這么干的收益是可讀性和性能都回來(lái)了。另一類是性能極度敏感的底層代碼比如自己實(shí)現(xiàn)的內(nèi)存分配器、無(wú)鎖數(shù)據(jù)結(jié)構(gòu)。這類代碼里需要大量的裸指針操作和unsafe所有權(quán)檢查在這里幫不上什么忙反而會(huì)礙事。合理的做法是把unsafe收斂在一個(gè)小模塊里對(duì)外仍然暴露安全接口用文檔和測(cè)試來(lái)保證內(nèi)部的不變量。還有一種情況是生命周期標(biāo)注復(fù)雜到影響可維護(hù)性。我見過一個(gè)結(jié)構(gòu)體帶四個(gè)生命周期參數(shù)每次新增方法都要重新推導(dǎo)一遍。這種時(shí)候把數(shù)據(jù)改成擁有的形式或者用Arc共享往往是更務(wù)實(shí)的選擇。編譯期檢查的價(jià)值在于減少 bug如果為了通過檢查而把代碼寫得沒人看得懂那就本末倒置了。我個(gè)人在實(shí)際項(xiàng)目里的體會(huì)是所有權(quán)系統(tǒng)最大的價(jià)值不在于讓你寫出絕對(duì)安全的代碼而在于它強(qiáng)迫你在寫代碼的時(shí)候就想清楚數(shù)據(jù)的歸屬和生命周期。這個(gè)思考過程本身就會(huì)篩掉大量設(shè)計(jì)上的含糊之處。被編譯器攔住的那幾十次換來(lái)的往往是對(duì)模塊邊界更清晰的認(rèn)識(shí)——這個(gè)收益比少寫幾行釋放語(yǔ)句要大得多。