1. 多態(tài)不是語(yǔ)法糖而是一套運(yùn)行時(shí)契約1.1 靜態(tài)綁定與動(dòng)態(tài)綁定的關(guān)鍵區(qū)別很多人學(xué)C多態(tài)第一反應(yīng)是“繼承 virtual關(guān)鍵字 基類指針調(diào)派生類函數(shù)”背完語(yǔ)法就覺(jué)得自己會(huì)了。但落到實(shí)際項(xiàng)目里一遇到性能問(wèn)題、構(gòu)造析構(gòu)時(shí)序、跨模塊調(diào)用這些“會(huì)了”馬上就露餡。因?yàn)镃的多態(tài)本質(zhì)上不是語(yǔ)法層面的一種寫(xiě)法而是編譯器為我們生成的一套運(yùn)行時(shí)調(diào)度協(xié)議。理解這套協(xié)議才算真正理解動(dòng)態(tài)綁定。先看綁定的概念。所謂綁定就是確定“調(diào)用p-speak()時(shí)到底執(zhí)行哪一個(gè)函數(shù)體”。靜態(tài)綁定發(fā)生在編譯期編譯器看到表達(dá)式類型就確定地址比如普通重載函數(shù)、模板實(shí)例化這些都是編譯期就能定死的事。動(dòng)態(tài)綁定則發(fā)生在運(yùn)行期編譯器此時(shí)只知道“p是Animal*”但p指向的到底是Dog還是Cat要到程序真正運(yùn)行取出p的實(shí)際類型才知道。為了做到這點(diǎn)C選擇的方式是給類生成一張?zhí)摵瘮?shù)表再讓每個(gè)對(duì)象內(nèi)部保存一個(gè)指向該表的指針。調(diào)用虛函數(shù)時(shí)程序先通過(guò)對(duì)象拿到虛表指針再?gòu)谋碇胁榈綄?duì)應(yīng)入口地址。這條間接路徑就是“動(dòng)態(tài)”二字的來(lái)源。這里有個(gè)容易混淆的點(diǎn)virtual關(guān)鍵字本身并不會(huì)給函數(shù)增加什么魔法它只是告訴編譯器“這個(gè)函數(shù)放進(jìn)虛表調(diào)用時(shí)走動(dòng)態(tài)綁定”。如果沒(méi)有virtual即使寫(xiě)Animal* p new Dog;調(diào)用p-speak()時(shí)執(zhí)行的仍然是Animal::speak()因?yàn)榫幾g器只認(rèn)p的靜態(tài)類型。我見(jiàn)過(guò)不少代碼把基類的普通函數(shù)和虛函數(shù)混著寫(xiě)調(diào)了半天結(jié)果發(fā)現(xiàn)有的走動(dòng)態(tài)綁定、有的走靜態(tài)綁定行為時(shí)對(duì)時(shí)錯(cuò)。這就是沒(méi)搞清楚兩者邊界的典型癥狀。動(dòng)態(tài)綁定的價(jià)值是讓調(diào)用方只依賴穩(wěn)定接口不需要在調(diào)用點(diǎn)寫(xiě)if (type Dog) ... else if (type Cat) ...這類分支。它把“變化的部分”交給運(yùn)行時(shí)去分發(fā)調(diào)用方的代碼因此變得穩(wěn)定、可擴(kuò)展。1.2 虛函數(shù)表編譯器替我們埋好的路由表要理解動(dòng)態(tài)綁定繞不開(kāi)虛表vtable和虛指針vptr。我習(xí)慣把虛表理解成一張路由表函數(shù)名對(duì)應(yīng)一條表項(xiàng)表項(xiàng)里存的是真正要執(zhí)行的函數(shù)地址。當(dāng)一個(gè)基類指針調(diào)用虛函數(shù)時(shí)它做的事就是先從對(duì)象的vptr取出虛表地址再去表里查函數(shù)入口最后跳轉(zhuǎn)執(zhí)行。虛表是編譯器在編譯階段生成的每個(gè)含有虛函數(shù)的類都有自己的虛表。派生類如果覆寫(xiě)了某個(gè)虛函數(shù)這個(gè)函數(shù)在新類的虛表里就會(huì)指向派生類的實(shí)現(xiàn)沒(méi)有覆寫(xiě)的部分則繼續(xù)指向基類的實(shí)現(xiàn)。所以我們可以說(shuō)虛表是一張“按類生成、按對(duì)象持有指針”的路由表?？吹竭@里你可能想問(wèn)既然虛表由編譯器生成vptr又是每個(gè)對(duì)象都有的那這個(gè)隱藏成員到底放在對(duì)象的哪個(gè)位置不同編譯器布局略有差異但在主流平臺(tái)上vptr一般位于對(duì)象內(nèi)存布局的開(kāi)頭。這意味著一個(gè)普通的空類沒(méi)有虛函數(shù)時(shí)大小是1字節(jié)為了占位有了虛函數(shù)之后大小變成8字節(jié)64位平臺(tái)——多出來(lái)的正是vptr占用的空間。這個(gè)細(xì)節(jié)對(duì)工程有直接影響。比如兩個(gè)不同類如果它們的內(nèi)存布局都包含vptr你把一個(gè)對(duì)象用memcpy強(qiáng)行拷貝給另一個(gè)再以派生類指針去調(diào)用虛函數(shù)輕則讀到錯(cuò)亂的虛表地址重則直接崩潰。凡是涉及序列化、內(nèi)存映射、緩沖區(qū)復(fù)用的代碼都要先把“對(duì)象里有沒(méi)有vptr”這件事想清楚。另一個(gè)實(shí)用點(diǎn)是繼承鏈。多層繼承時(shí)對(duì)象里只保留一個(gè)vptr單繼承情況下指向“整個(gè)繼承鏈最終形態(tài)所對(duì)應(yīng)的虛表”。否則無(wú)法解釋為什么Animal* ap new Dog;和Dog* dp new Dog;即使變量類型不同訪問(wèn)到的虛函數(shù)也能一致。因?yàn)閮蓚€(gè)指針指向同一個(gè)對(duì)象拿到的都是同一個(gè)vptr、同一張?zhí)摫怼?.3 有虛函數(shù)的類內(nèi)存里多了一個(gè)“看不見(jiàn)的成員”前面提到vptr它是個(gè)隱藏成員不寫(xiě)在類定義里但每個(gè)對(duì)象都有。這讓不少初學(xué)C的朋友踩過(guò)一個(gè)經(jīng)典坑sizeof算出來(lái)比自己聲明的成員變量總和要多卻找不到多出來(lái)的變量在哪。我舉個(gè)例子。一個(gè)類只聲明了int id;直覺(jué)上大小是4字節(jié)但一旦它帶有虛函數(shù)64位平臺(tái)下sizeof通常是16字節(jié)4字節(jié)的int加上8字節(jié)的vptr加上對(duì)齊填充。拿這個(gè)類去初始化一個(gè)字節(jié)流緩沖區(qū)、寫(xiě)入文件、網(wǎng)絡(luò)傳輸再在原平臺(tái)反序列化如果處理得不對(duì)讀回來(lái)的對(duì)象vptr是指向非法地址的后續(xù)一調(diào)虛函數(shù)就崩。這里補(bǔ)充一句vptr的初始化是在構(gòu)造函數(shù)里完成的編譯器會(huì)在構(gòu)造函數(shù)的最開(kāi)始插入“將vptr指向本類虛表”的指令。這個(gè)時(shí)機(jī)非常關(guān)鍵也是后面要講的“構(gòu)造函數(shù)里調(diào)虛函數(shù)為什么不靈”的根本原因。所以給業(yè)務(wù)類設(shè)計(jì)是否虛函數(shù)不只是代碼風(fēng)格問(wèn)題還牽涉到內(nèi)存布局、跨語(yǔ)言交互、底層序列化等一系列問(wèn)題。凡是要做數(shù)據(jù)落地的類我建議先問(wèn)自己它真的需要多態(tài)嗎如果只是為了讓某個(gè)字段被子類替換那用一個(gè)虛函數(shù)接口的成本可能比記錄下來(lái)還要高。2. 動(dòng)態(tài)綁定的運(yùn)行時(shí)真相2.1 vptr的構(gòu)造順序?yàn)槭裁礃?gòu)造函數(shù)里調(diào)虛函數(shù)是“假多態(tài)”有經(jīng)驗(yàn)的面試官很喜歡問(wèn)一個(gè)問(wèn)題基類構(gòu)造函數(shù)里調(diào)用虛函數(shù)會(huì)調(diào)用到派生類的覆寫(xiě)版本嗎答案是不會(huì)調(diào)用的是基類版本。原因就落在vptr的初始化順序上。構(gòu)造一個(gè)派生類對(duì)象時(shí)編譯器會(huì)先構(gòu)造基類子對(duì)象再構(gòu)造派生類自己的部分。這里有個(gè)關(guān)鍵機(jī)制在基類構(gòu)造函數(shù)執(zhí)行期間vptr被設(shè)置為指向基類的虛表而不是派生類的虛表。也就是說(shuō)當(dāng)基類構(gòu)造函數(shù)體內(nèi)的代碼執(zhí)行到對(duì)虛函數(shù)的調(diào)用時(shí)對(duì)象“當(dāng)前身份”還是基類動(dòng)態(tài)綁定在這個(gè)階段看起來(lái)失效了實(shí)際上它是按照當(dāng)前構(gòu)造層級(jí)正確工作的。等到基類構(gòu)造完成進(jìn)入派生類構(gòu)造函數(shù)體之前vptr才會(huì)被更新為指向派生類的虛表。所以構(gòu)造函數(shù)的執(zhí)行順序決定了你只能在“自己那層”調(diào)用到自己那層的虛函數(shù)實(shí)現(xiàn)規(guī)律是從基類往派生類逐步“變身”。析構(gòu)順序則完全反過(guò)來(lái)析構(gòu)時(shí)vptr先保持派生類虛表進(jìn)入派生類析構(gòu)體后再隨著析構(gòu)退出逐步切回基類虛表最后銷(xiāo)毀整個(gè)對(duì)象。這樣的設(shè)計(jì)看起來(lái)有點(diǎn)反直覺(jué)但它是安全的。試想如果基類構(gòu)造函數(shù)在對(duì)象還沒(méi)完全構(gòu)造好時(shí)就調(diào)用了一個(gè)依賴派生類成員狀態(tài)的虛函數(shù)結(jié)果一定會(huì)在真隨機(jī)的時(shí)間點(diǎn)崩潰。C選擇不讓這種情況發(fā)生代價(jià)就是構(gòu)造函數(shù)里的虛函數(shù)調(diào)用不具有動(dòng)態(tài)性。工程上的教訓(xùn)是不要在構(gòu)造函數(shù)里依賴多態(tài)行為。如果派生類確實(shí)需要“構(gòu)造時(shí)執(zhí)行自定義邏輯”更穩(wěn)妥的做法是用一個(gè)非虛的公共構(gòu)造函數(shù)封裝之后單獨(dú)暴露init()之類的接口讓派生類覆寫(xiě)再由外部在構(gòu)造完成后顯式調(diào)用。這個(gè)方法雖然多一步但行為明確也方便在初始化失敗時(shí)處理異常。2.2 純虛函數(shù)、抽象類與設(shè)計(jì)約束純虛函數(shù)是C多態(tài)里最接近“接口”概念的東西。聲明方式是在虛函數(shù)末尾加 0它表示“本類不提供該函數(shù)的實(shí)現(xiàn)派生類必須實(shí)現(xiàn)”。含有純虛函數(shù)的類就是抽象類不能直接實(shí)例化。注意不能實(shí)例化不是“編譯器隨手?jǐn)r住”而是因?yàn)閷?duì)象構(gòu)造時(shí)無(wú)法確定虛函數(shù)的入口地址表項(xiàng)懸空的話對(duì)象里的vptr就沒(méi)有完整意義。我常在設(shè)計(jì)里用純虛函數(shù)來(lái)定義業(yè)務(wù)契約。例如一個(gè)支付模塊定義了submit()、query()、refund()三個(gè)純虛函數(shù)各支付渠道自己去實(shí)現(xiàn)。這樣上層業(yè)務(wù)流程只依賴這個(gè)抽象接口完全不感知具體渠道存在。新增一個(gè)渠道只需要添加一個(gè)派生類不用改動(dòng)任何調(diào)用代碼。這符合面向?qū)ο罄铩伴_(kāi)閉原則”的直觀表述對(duì)擴(kuò)展開(kāi)放對(duì)修改關(guān)閉。純虛函數(shù)還有一個(gè)容易被忽視的用法可以在基類中給純虛函數(shù)提供函數(shù)體。是的純虛函數(shù)也可以有實(shí)現(xiàn)但派生類仍然必須覆寫(xiě)它才能在對(duì)象里獲得可調(diào)用版本。派生類實(shí)現(xiàn)里如果想復(fù)用基類邏輯可以顯式調(diào)用Base::pureFunc()。這種寫(xiě)法適合做一些公共的兜底邏輯但使用頻率不高。另一個(gè)常見(jiàn)操作是定義純虛析構(gòu)函數(shù)。語(yǔ)法上析構(gòu)函數(shù)可以是純虛函數(shù)但你必須為它提供實(shí)現(xiàn)否則任何派生類析構(gòu)時(shí)鏈接器都找不到基類析構(gòu)函數(shù)體直接報(bào)錯(cuò)。原因很簡(jiǎn)單析構(gòu)永遠(yuǎn)要一層層執(zhí)行到基類定義純虛析構(gòu)而不給實(shí)現(xiàn)基類那層就“無(wú)函數(shù)可調(diào)”了。很多人知道“基類析構(gòu)函數(shù)要加virtual”卻不知道純虛析構(gòu)還必須給函數(shù)體這也是一個(gè)高頻面試陷阱。2.3 析構(gòu)函數(shù)必須是虛函數(shù)的理由當(dāng)一個(gè)類要被繼承、且你打算用基類指針管理對(duì)象時(shí)析構(gòu)函數(shù)應(yīng)當(dāng)聲明為virtual。這條規(guī)則幾乎無(wú)人質(zhì)疑但背后原因值得展開(kāi)?？紤]一段代碼Base* p new Derived();最后執(zhí)行delete p;。如果Base的析構(gòu)函數(shù)不是虛函數(shù)delete的行為由靜態(tài)類型決定——編譯器認(rèn)為p是Base*于是只調(diào)用Base的析構(gòu)函數(shù)。但p實(shí)際上指向的是Derived對(duì)象Derived部分占用的資源、它自己的析構(gòu)邏輯全部不會(huì)被執(zhí)行。這在內(nèi)存和資源上輕則泄漏重則導(dǎo)致程序在退出階段崩潰。如果Base的析構(gòu)函數(shù)是虛函數(shù)delete會(huì)經(jīng)過(guò)動(dòng)態(tài)綁定找到對(duì)象的真實(shí)類型先調(diào)用Derived析構(gòu)函數(shù)再按層級(jí)向上調(diào)用Base析構(gòu)函數(shù)完整釋放整個(gè)對(duì)象。這也是“析構(gòu)與構(gòu)造順序相反”的原因所在。這里需要強(qiáng)調(diào)一個(gè)邊界不打算作為多態(tài)基類使用的類沒(méi)必要把析構(gòu)函數(shù)寫(xiě)成virtual。因?yàn)橐坏┞暶魈撐鰳?gòu)函數(shù)類就會(huì)引入vptr對(duì)象體積變大且破壞原本可能是POD的內(nèi)存布局。換句話說(shuō)virtual析構(gòu)函數(shù)是“我要把對(duì)象當(dāng)作多態(tài)對(duì)象來(lái)管理”的聲明使用它是有代價(jià)的。工程上如果拿不準(zhǔn)“這個(gè)類以后會(huì)不會(huì)被繼承”目前我傾向的做法是默認(rèn)不加虛析構(gòu)等到確實(shí)出現(xiàn)基類指針刪除派生類對(duì)象的需求時(shí)再補(bǔ)上。盲目全加virtual除了增大內(nèi)存占用還會(huì)讓結(jié)構(gòu)體無(wú)法被某些C庫(kù)接口直接傳遞。保持克制比“肯定不會(huì)有問(wèn)題”的心態(tài)更可靠。3. 把動(dòng)態(tài)綁定真正落到工程代碼里3.1 一個(gè)最小但完整的示例理論講完看一段可以直接跑的示例代碼。這個(gè)例子很小但覆蓋了“基類指針調(diào)用派生類覆寫(xiě)函數(shù)”的全部關(guān)鍵環(huán)節(jié)。#include iostream #include memory class Animal { public: virtual void speak() const { std::cout Animal speaks. std::endl; } virtual ~Animal() default; }; class Dog : public Animal { public: void speak() const override { std::cout Dog barks. std::endl; } }; class Cat : public Animal { public: void speak() const override { std::cout Cat meows. std::endl; } }; void talk(const Animal animal) { animal.speak(); // 動(dòng)態(tài)綁定 } int main() { Dog dog; Cat cat; talk(dog); talk(cat); std::unique_ptrAnimal p std::make_uniqueDog(); p-speak(); return 0; }運(yùn)行結(jié)果是三行不同叫聲各自對(duì)應(yīng)實(shí)際對(duì)象類型。細(xì)看這段代碼有兩個(gè)我特意留下的細(xì)節(jié)。第一個(gè)是override關(guān)鍵字它讓編譯器幫助檢查派生類覆寫(xiě)是否符合基類虛函數(shù)簽名。如果我在Dog里把speak()的參數(shù)改成int x編譯器會(huì)直接報(bào)錯(cuò)而不是讓代碼帶著一個(gè)“看起來(lái)正確但實(shí)際不執(zhí)行動(dòng)態(tài)綁定”的隱藏函數(shù)。第二個(gè)是虛析構(gòu)配合std::unique_ptrAnimal使用。如果不加virtual析構(gòu)unique_ptrAnimal刪除Dog對(duì)象時(shí)同樣會(huì)面臨前面說(shuō)的只析構(gòu)基類部分的問(wèn)題。日常項(xiàng)目里我更推薦在參數(shù)傳遞上用const Animal而不是裸指針。原因有兩個(gè)一是引用天然不為空少一類“空指針判斷”的臟代碼二是const限制調(diào)用方不能修改對(duì)象內(nèi)部狀態(tài)對(duì)接口約束更清晰。傳入引用時(shí)同樣觸發(fā)動(dòng)態(tài)綁定動(dòng)態(tài)性不依賴傳參方式。3.2 override、final、默認(rèn)實(shí)參三個(gè)容易翻車(chē)的細(xì)節(jié)多態(tài)語(yǔ)法看起來(lái)磕到頭就完事但有三個(gè)細(xì)節(jié)常讓人調(diào)試到懷疑人生。第一個(gè)是隱藏與覆蓋的區(qū)別。派生類里定義一個(gè)與基類虛函數(shù)同名但參數(shù)不同的函數(shù)不會(huì)覆蓋基類版本而是隱藏基類的所有同名函數(shù)。比如基類有virtual void draw(int);派生類寫(xiě)void draw(double);通過(guò)基類指針調(diào)用p-draw(42)時(shí)靜態(tài)度量依然調(diào)用draw(int)動(dòng)態(tài)分發(fā)完全沒(méi)發(fā)生。如果要覆寫(xiě)必須保證函數(shù)簽名完全一致否則就用using Base::draw;顯式引入基類同名函數(shù)。第二個(gè)是默認(rèn)實(shí)參的靜態(tài)綁定問(wèn)題?？催@段代碼class Base { public: virtual void f(int x 1) const { std::cout x; } }; class Derived : public Base { public: void f(int x 2) const override { std::cout x; } }; Base* p new Derived(); p-f(); // 輸出2還是1答案是輸出2派生類實(shí)現(xiàn)但實(shí)參取自Base的默認(rèn)值1。因?yàn)槟J(rèn)實(shí)參在編譯期解析編譯器按p的靜態(tài)類型Base去確定x1而函數(shù)體執(zhí)行走動(dòng)態(tài)綁定調(diào)用Derived::f于是得到x1。這在代碼里很容易讓人困惑。我的建議是不要在虛函數(shù)里使用默認(rèn)實(shí)參寧可寫(xiě)一個(gè)非虛的公開(kāi)函數(shù)轉(zhuǎn)發(fā)到私有虛函數(shù)把默認(rèn)值放在非虛層。第三個(gè)是final的用法。它有兩個(gè)位置類名后跟class FinalCls final表示該類不能繼續(xù)被繼承函數(shù)后跟void f() final表示該虛函數(shù)不能再被覆寫(xiě)。final的價(jià)值不僅是限制別人也是在團(tuán)隊(duì)協(xié)作時(shí)明確表達(dá)“這個(gè)擴(kuò)展點(diǎn)就到此為止”的意圖。它還能讓編譯器在某些情況下做更激進(jìn)的優(yōu)化因?yàn)榫幾g器知道了繼承不會(huì)再加深雖然實(shí)際優(yōu)化效果有限。3.3 dynamic_cast、typeid 與運(yùn)行時(shí)類型識(shí)別程序運(yùn)行到某個(gè)環(huán)節(jié)確實(shí)需要確認(rèn)“這個(gè)對(duì)象到底是什么類型”時(shí)C提供了dynamic_cast和typeid。二者都依賴RTTI運(yùn)行時(shí)類型信息而RTTI只對(duì)帶虛函數(shù)的類生效。普通類沒(méi)有多態(tài)能力也就沒(méi)有可靠的運(yùn)行時(shí)類型信息。dynamic_cast最常見(jiàn)的用法是把基類指針/引用安全地轉(zhuǎn)為派生類指針/引用。指針轉(zhuǎn)型失敗返回nullptr引用轉(zhuǎn)型失敗拋std::bad_cast異常。它在多級(jí)繼承和交叉轉(zhuǎn)型時(shí)可以沿著繼承關(guān)系行走比static_cast在運(yùn)行時(shí)穩(wěn)定得多。static_cast不會(huì)檢查實(shí)際類型在已知類型信息時(shí)雖然快但一旦類型判斷失誤后果是未定義行為。typeid則返回一個(gè)std::type_info對(duì)象可以直接比較或讀取類型名稱。它適合做日志輸出、斷言、診斷但我不建議把它寫(xiě)進(jìn)業(yè)務(wù)判斷分支。一個(gè)系統(tǒng)里如果到處是if (typeid(*p) typeid(Dog))說(shuō)明接口抽象得不夠把“對(duì)象是什么”的判斷強(qiáng)插進(jìn)了調(diào)用方。更好的方向是給公共基類補(bǔ)充一個(gè)行為接口讓調(diào)用方只問(wèn)“你能不能做這件事”而不是問(wèn)“你是誰(shuí)”。關(guān)于dynamic_cast還有一條工程經(jīng)驗(yàn)如果某處必須用dynamic_cast向下轉(zhuǎn)型我會(huì)盡量把它封裝在基類的某個(gè)虛函數(shù)接口之后或者放在緊挨對(duì)象創(chuàng)建的局部區(qū)域限制它的擴(kuò)散范圍。這樣既拿到具體派生類的能力又不讓類型檢查污染整體架構(gòu)。4. 性能考量與模板多態(tài)的取舍4.1 一次虛函數(shù)調(diào)用的真實(shí)成本討論動(dòng)態(tài)綁定沒(méi)法回避性能問(wèn)題。我常被問(wèn)“虛函數(shù)是不是很慢”。直接回答單次調(diào)用很便宜但代價(jià)真實(shí)存在。一次普通函數(shù)調(diào)用是編譯期直接生成跳轉(zhuǎn)指令調(diào)用地址在指令里寫(xiě)死。一次虛函數(shù)調(diào)用要先加載對(duì)象的vptr再根據(jù)函數(shù)在虛表中的偏移讀取入口地址然后間接跳轉(zhuǎn)。多出來(lái)的操作一般只有幾次內(nèi)存訪問(wèn)和一個(gè)間接跳轉(zhuǎn)單看絕對(duì)時(shí)間在熱緩存場(chǎng)景下往往只有幾納秒。真正的成本有兩點(diǎn)。第一虛函數(shù)無(wú)法在編譯期被內(nèi)聯(lián)。內(nèi)聯(lián)是編譯器最有效的優(yōu)化手段之一虛函數(shù)調(diào)用阻斷了這個(gè)路徑某些高頻小函數(shù)因?yàn)闊o(wú)法內(nèi)聯(lián)性能損失會(huì)放大。第二間接跳轉(zhuǎn)會(huì)干擾現(xiàn)代CPU的分支預(yù)測(cè)。當(dāng)循環(huán)里交替處理不同派生類對(duì)象時(shí)同一位置的虛調(diào)用入口不斷變化CPU預(yù)測(cè)失敗的代價(jià)可能讓整體吞吐明顯下降。我實(shí)際調(diào)整過(guò)一個(gè)幀循環(huán)里大量高頻調(diào)用的模塊里面幾個(gè)接口是虛函數(shù)每次迭代都要觸發(fā)多次動(dòng)態(tài)分發(fā)。把這個(gè)環(huán)節(jié)改成模板化靜態(tài)多態(tài)后同一功能的吞吐量提升了大約三成。但這不代表“虛函數(shù)就該被抵制”因?yàn)槟谴纹款i出現(xiàn)在“調(diào)用次數(shù)極端密集 對(duì)象類型在循環(huán)內(nèi)頻繁切換 函數(shù)體本身很小”的組合條件下。業(yè)務(wù)代碼里大多數(shù)虛函數(shù)調(diào)用不是熱點(diǎn)優(yōu)化它們往往吃力不討好。做性能取舍時(shí)我的習(xí)慣是先profile確認(rèn)某個(gè)函數(shù)確實(shí)在熱點(diǎn)路徑上再?zèng)Q定是否調(diào)整。寧可多寫(xiě)一點(diǎn)模板代碼也不要憑空臆想“這里少一個(gè)虛調(diào)用就快了”。盲目用宏或硬編碼替掉虛函數(shù)最后通常只換來(lái)一份更脆弱、更難維護(hù)的代碼。4.2 何時(shí)選擇模板/編譯期多態(tài)何時(shí)必須用虛函數(shù)C有兩種多態(tài)途徑運(yùn)行期動(dòng)態(tài)綁定虛函數(shù)編譯期靜態(tài)多態(tài)模板、CRTP。兩者不是替代關(guān)系而是分工不同。虛函數(shù)適合“運(yùn)行時(shí)類型未知、需要延遲決定”的場(chǎng)景模板適合“編譯期就能確定類型集合、追求性能邊界”的場(chǎng)景。判斷標(biāo)準(zhǔn)可以這樣簡(jiǎn)化如果變化發(fā)生在運(yùn)行期比如插件加載、用戶自定義類型、跨模塊回調(diào)選虛函數(shù)。如果變化僅僅發(fā)生在編譯期比如一個(gè)算法需要適配多種數(shù)值類型選模板。一個(gè)經(jīng)典例子是std::sort使用模板實(shí)現(xiàn)因?yàn)樗獙?duì)各種隨機(jī)訪問(wèn)迭代器類型做編譯期優(yōu)化而GUI框架事件回調(diào)普遍使用多態(tài)因?yàn)榘粹o點(diǎn)擊時(shí)到底執(zhí)行哪一個(gè)業(yè)務(wù)動(dòng)作只有運(yùn)行時(shí)才知道。還有一個(gè)介于兩者之間的工具是std::function。它本身不要求參數(shù)類型有繼承關(guān)系只要可調(diào)用對(duì)象簽名匹配就能賦值。它內(nèi)部通過(guò)類型擦除包裝不同可調(diào)用對(duì)象對(duì)外屏蔽具體類型。這相當(dāng)于“基于值語(yǔ)義的多態(tài)”在很多場(chǎng)景里比虛函數(shù)更靈活尤其適合做回調(diào)注冊(cè)。代價(jià)是類型擦除可能產(chǎn)生堆分配性能敏感時(shí)需要測(cè)試。關(guān)于“不要亂用虛函數(shù)”我更想表達(dá)的是多態(tài)的價(jià)值在于把一種調(diào)用方契約和多種實(shí)現(xiàn)之間的綁定關(guān)系交給運(yùn)行時(shí)管理。如果某個(gè)類的派生類版本永遠(yuǎn)只有兩三個(gè)而且在編譯期就能確定當(dāng)前調(diào)用時(shí)間點(diǎn)的具體類型那虛函數(shù)的動(dòng)態(tài)性就有點(diǎn)“過(guò)度供給”。真實(shí)系統(tǒng)往往是混用的公共接口層用抽象類定義契約高頻計(jì)算內(nèi)核用模板或普通函數(shù)。兩種方式兼容得很好重點(diǎn)是意識(shí)到邊界在哪。5. 工程中常見(jiàn)的高頻坑與排查思路5.1 delete基類指針導(dǎo)致派生類析構(gòu)沒(méi)執(zhí)行這個(gè)坑的威力不在于代碼難懂而在于它觸發(fā)時(shí)往往不在現(xiàn)場(chǎng)。排查場(chǎng)景一般是程序跑了一段時(shí)間內(nèi)存持續(xù)增長(zhǎng)或者派生類持有文件句柄、網(wǎng)絡(luò)連接關(guān)閉時(shí)沒(méi)有釋放導(dǎo)致后續(xù)操作失敗。定位時(shí)發(fā)現(xiàn)某個(gè)基類析構(gòu)函數(shù)前少了virtual于是delete基類指針時(shí)只銷(xiāo)毀了基類部分。修復(fù)方式很直接給析構(gòu)函數(shù)加virtual。還有一種更穩(wěn)妥的工程習(xí)慣是全程使用智能指針管理多態(tài)對(duì)象。std::shared_ptrBase在創(chuàng)建時(shí)如果傳入的是Derived*刪除器會(huì)綁定到Derived的析構(gòu)函數(shù)即使基類析構(gòu)不是虛函數(shù)也能正確釋放派生類資源。注意這里有個(gè)陷阱如果先拿Derived*構(gòu)造shared_ptrBase刪除器是完整的如果先拿到shared_ptrDerived再隱式轉(zhuǎn)換成shared_ptrBase同樣保留正確的類型擦除刪除器。但如果是用shared_ptrBase(new Derived)也能正確只有把原始Derived*直接賦給裸指針再手動(dòng)delete才存在風(fēng)險(xiǎn)。總之用智能指針能規(guī)避掉相當(dāng)一部分此類問(wèn)題。5.2 構(gòu)造函數(shù)里調(diào)用虛函數(shù)行為不符合預(yù)期這類問(wèn)題通常出現(xiàn)得很隱蔽。比如某個(gè)監(jiān)控框架在基類構(gòu)造函數(shù)里調(diào)用了report()虛函數(shù)原本希望子類覆寫(xiě)后上報(bào)自定義信息結(jié)果跑起來(lái)發(fā)現(xiàn)上報(bào)的全是默認(rèn)值。原因正如前面分析的基類構(gòu)造階段vptr還指向基類虛表虛調(diào)用不會(huì)進(jìn)入派生類版本。修正方案有兩個(gè)方向。如果邏輯確實(shí)需要在對(duì)象構(gòu)造完成后執(zhí)行就改成在派生類構(gòu)造函數(shù)的函數(shù)體末尾顯式調(diào)用或用單獨(dú)的init()接口。如果邏輯只能在基類構(gòu)造階段執(zhí)行那就直接調(diào)用基類版本不要指望動(dòng)態(tài)綁定。還有一個(gè)小技巧在基類構(gòu)造函數(shù)里調(diào)用一個(gè)純虛函數(shù)會(huì)導(dǎo)致程序崩潰或未定義行為因?yàn)榇藭r(shí)虛表中該項(xiàng)是空的所以這種行為是明確的禁忌。排查時(shí)先確認(rèn)調(diào)用點(diǎn)是在構(gòu)造函數(shù)內(nèi)還是構(gòu)造函數(shù)后可以省掉很多無(wú)謂的猜測(cè)。5.3 庫(kù)接口中增刪虛函數(shù)引發(fā)二進(jìn)制兼容問(wèn)題這一條主要針對(duì)要發(fā)布庫(kù)的團(tuán)隊(duì)。假設(shè)你的庫(kù)給外部模塊使用大家已經(jīng)基于你的頭文件和編譯產(chǎn)物鏈接運(yùn)行。你在新版里往某個(gè)公共基類新增了一個(gè)虛函數(shù)或者調(diào)整了虛函數(shù)的順序那么虛表布局就變了。舊版客戶端模塊用的是舊虛表布局兩者一混合調(diào)用虛函數(shù)時(shí)會(huì)拿到錯(cuò)位的表項(xiàng)地址結(jié)果是難以預(yù)料的崩潰或靜默邏輯錯(cuò)誤。這就是為什么很多穩(wěn)定庫(kù)對(duì)公共類的改動(dòng)極其謹(jǐn)慎。要擴(kuò)展接口時(shí)更安全的是新增一個(gè)單獨(dú)的接口類或者用pImpl模式把實(shí)現(xiàn)細(xì)節(jié)藏起來(lái)讓對(duì)外類保持穩(wěn)定的內(nèi)存布局。至少在增刪虛函數(shù)前必須確認(rèn)上下游模塊統(tǒng)一重新編譯。這類問(wèn)題在編譯好的二進(jìn)制環(huán)境下尤其隱蔽因?yàn)樗粫?huì)在編譯期報(bào)錯(cuò)只在運(yùn)行期莫名崩塌。我在實(shí)際維護(hù)一個(gè)跨平臺(tái)模塊時(shí)就吃過(guò)一次虧新版頭文件里給抽象接口加了一個(gè)帶默認(rèn)實(shí)現(xiàn)的虛函數(shù)我在本地重新編譯后一切正常但把庫(kù)發(fā)出去后舊版調(diào)用方的運(yùn)行日志里開(kāi)始零星出現(xiàn)棧錯(cuò)亂。排查到最后根源就是那個(gè)新增的虛函數(shù)改變了虛表偏移。從那以后我對(duì)公共接口的虛函數(shù)表逢改必查影響面能不加就不加能新增獨(dú)立接口類就絕不往老類身上疊虛函數(shù)。排查多態(tài)相關(guān)問(wèn)題時(shí)還有一條經(jīng)驗(yàn)值得分享遇到詭異崩潰先看是否涉及相同內(nèi)存被多種類型解釋再看構(gòu)造函數(shù)和析構(gòu)函數(shù)的調(diào)用順序最后檢查vptr是不是在奇怪的時(shí)間點(diǎn)被改寫(xiě)。大多數(shù)虛調(diào)用崩潰都繞不開(kāi)這三個(gè)方向。把動(dòng)態(tài)綁定背后的內(nèi)存布局和對(duì)象生命周期想清楚踩坑的頻率會(huì)顯著下降。我在實(shí)際調(diào)試?yán)锏捏w會(huì)是真正讓人痛苦的不是語(yǔ)法沒(méi)記住而是把一個(gè)靜態(tài)世界里的問(wèn)題拿到運(yùn)行時(shí)視角里去分析時(shí)還缺那一層直覺(jué)。多寫(xiě)幾個(gè)帶vptr的類、沒(méi)事打印一下對(duì)象大小和類型信息這種直覺(jué)慢慢就養(yǎng)出來(lái)了。