① 钩子：同样一行b->f()，三种命运
同样一行b->f()，编译器有时直接跳转，有时绕两个弯，有时还会"自作聪明"地在调用前先检查一遍虚表。
多态的代价到底花在哪？答案全在这几行汇编里。
这一集我们要回答三个问题：
- 虚调用在机器码层面到底做了什么（取 vptr → 查表 → 间接跳转）？
- 这个"动态分派"到底贵在哪（两次内存读 + 间接跳转的分支预测失败）？
- 编译器有哪些"去虚化"手段，能让虚调用变回普通调用？
② 先看概念：vptr 与 vtable
- vtable（虚表）：每个"带虚函数的类"一张表，表里按声明顺序存着各虚函数的地址。
Base一张、Derived一张（覆盖的f指向Derived::f）。 - vptr（虚表指针）：每个"带虚函数的对象"开头藏一个指针，指向它所属类的 vtable。对象 → vptr → vtable → 函数地址，就是虚调用的完整路径。
内存布局（Base对象）：
偏移 0 vptr（8 字节）→ 指向 Base 的 vtable 偏移 8 int x 偏移 12 填充③ 源码 vs 汇编对照
structBase{virtualvoidf(){}virtualvoidg(){}intx;// 布局：vptr(8B) + x(4B) + 对齐填充};structDerived:Base{voidf()override{}};structDerivedFinalfinal:Base{voidf()override{}};voidcall_base(Base*b){b->f();}// ① 普通虚调用voidcall_g(Base*b){b->g();}// ② 未被重写 → 投机去虚化voidcall_final(DerivedFinal*d){d->f();}// ③ final → 完全去虚化-O2编译结果：
; ① call_base：两次间接寻址 movq (%rcx), %rax ; 对象首 8 字节 = vptr → vtable 地址 jmp *(%rax) ; 间接跳转到 vtable[0]（= f 的地址） ; ② call_g：GCC 生成了"投机去虚化"检查 leaq Base::g(%rip), %rdx ; 预取 Base::g 的地址 movq (%rcx), %rax ; vptr movq 8(%rax), %rax ; vtable[1]（= g 的槽位） cmpq %rdx, %rax ; 槽位 == Base::g ? jne .L6 ret ; 是 → 直接返回（Base::g 是空函数） .L6: jmp *%rax ; 否 → 才走间接跳转 ; ③ call_final：整个调用被优化没了 ret ; final 让编译器证明实际类型 → 内联成 ret④ 逐行拆解三种形态
① 普通虚调用：两次间接寻址
movq (%rcx), %rax ; ① 从对象取出 vptr（对象首 8 字节） jmp *(%rax) ; ② 从 vtable 取出函数地址并跳转这条路径叫动态分派（dynamic dispatch）：
- 对象内存里的 vptr 告诉你"这个对象实际是哪个类的"；
- vtable 告诉你"该类里 f 的地址在哪"；
- 间接跳转
jmp *(%rax)跳到真正的函数。
编译器不知道b指向的是Base还是Derived，所以必须"运行时查表"。这是多态能工作的地基，也是它的成本来源。
② 投机去虚化：编译器在赌
call_g里 GCC 生成了这样一段：
leaq Base::g(%rip), %rdx ; 预取"如果没被重写，就该是 Base::g" movq (%rcx), %rax ; vptr movq 8(%rax), %rax ; vtable[1]（g 的槽位） cmpq %rdx, %rax ; 槽位 == Base::g ? jne .L6 ; 不是 → 兜底走间接跳转 ret ; 是 → 直接调 Base::g（甚至内联）它的推理是：本编译单元里没有任何类重写g，那么g的槽位"十有八九"还是Base::g。于是先生成一个"快速路径"：如果槽位正好是Base::g，直接调用它（这里是空函数，直接ret）；只有被"猜中"时才走慢速间接跳转。猜对省钱，猜错多花一次比较——在"大多数调用都是基础实现"的场景下这是净赚。这是 GCC 对虚调用做的真实优化，市面上极少有人讲。
③ final：完全去虚化
DerivedFinal声明了final，编译器能证明"这个指针的实际类型只能是DerivedFinal"——于是虚调用退化成普通调用，甚至因为函数体是空而被内联成一行ret。**去虚化（devirtualization）**的威力在此。
⑤ 为什么这么设计
- vtable 是"每类一张"的函数指针表，每个带虚函数的对象开头放一个
vptr指向它。编译器不知道对象真实类型，只能：取 vptr → 查表 → 间接跳。这就是动态分派，也是多态能工作的地基。 - 代价有三个：① 多两次内存读（对象→vptr、vtable→函数地址）；② 间接跳转让 CPU 分支预测器"猜不准"，可能白干几十个周期；③ vtable 是独立内存，冷调用会缓存未命中。
- ②是白送的彩蛋：本编译单元里没有类重写
g，GCC 判断"调用 g 十有八九就是 Base::g"，于是生成带检查的投机版本——猜中走捷径，猜错才兜底。这是编译器对虚调用做的真实优化，市面上几乎没人讲过。 - ③是去虚化：
DerivedFinal加了final，编译器能证明实际类型，虚调用退化成普通调用，甚至内联成一行ret。
⑥ 深入：vptr 在构造期间怎么变
E07 预告过"构造期调用虚函数不会多态"，现在看 vptr 的具体赋值时机：
构造Derived对象时，编译器生成的代码大致是：
Base的构造函数：把 vptr 设为Base的 vtable 地址，再执行Base的构造体；- 回到
Derived的构造：把 vptr改写成Derived的 vtable 地址，再执行Derived的构造体。
所以反汇编一个派生类构造函数，你能看到vptr 被写入两次（每次指向不同的 vtable）。这就是"构造期间调虚函数解析到当前类"的机器证据。析构相反：先指向Derived的 vtable（析构派生部分），切回Base的 vtable（析构基类部分）。
⑦ 常见误区
- 误区 1：“虚函数比普通函数慢一个固定倍数”：不是。
-O2下很多虚调用被去虚化/投机去虚化，可能和普通调用一样快；真正的开销只在"无法证明实际类型"的热点路径。 - 误区 2：“每个对象都存一份虚表”：错。vtable 每类一张（全局只读数据，E04 讲过在
.rdata），对象里只有 8 字节 vptr。 - 误区 3：“
final只是给人看的”：它是给编译器看的——final让去虚化成为可能，这是有真实性能收益的。 - 误区 4：“虚析构可有可无”：通过基类指针
delete一个派生对象时，若析构不是虚的，只调用基类析构 → 派生部分泄漏。有虚函数就几乎必然需要虚析构。 - 误区 5：“多态对象布局和普通对象一样”：多了 8 字节 vptr，
sizeof变化、offsetof失效、不能当 POD 序列化。对象里第一个字段就是 vptr，你声明的第一个数据成员实际排在 vptr 之后（偏移 8 起）。
⑧ 实战启示
- 热点循环里少用虚调用：间接跳转 + 分支预测失败，在高频路径上是实打实的开销。
- 想关掉多态就用 final：不给派生机会，编译器才敢去虚化。
- 选对工具箱：编译期多态用模板/CRTP，运行期多态才用虚函数——两者不是一回事。
- 别忘了隐藏成本：一个虚函数让对象多 8 字节 vptr，且析构/拷贝虚化的复杂性随之而来。
- 把虚析构当成默认：任何作为基类使用的类，析构函数都该是
virtual的。
⑨ 扩展专题一：去虚化的另外两种手段
除了final，编译器还能通过另外两条路去虚化：
- 类型窄化（narrowing）：
Derived d; d.f();——这里d是具体类型的对象（不是指针/引用），编译器知道它只能是Derived，直接静态调用Derived::f，连 vtable 都不查。这是最彻底、最常见的去虚化。 - 整个程序分析（LTO）：开启链接期优化后，编译器能看到"整个程序里没有别的类重写它"，于是把虚调用改静态。这解释了为什么"开 LTO 后多态代码可能变快"。
一个实践对照：
voidvia_ptr(Base*b){b->f();}// 可能保留虚调用voidvia_obj(Derived d){d.f();}// 编译器直接静态调用，零虚成本类型越具体，编译器越敢优化。这也解释了为什么"接口里用引用/指针、具体实现用具体类型"是性能友好的模式。
⑩ 扩展专题二：接口继承的成本全景
用接口（纯虚基类）做抽象时，别忘了"一个抽象层级"带来的成本链：
对象体积 +8B vptr 构造 +设置 vptr 的指令（可能多次） 虚调用 +2 次内存读 + 1 次间接跳转（若没被去虚化） 虚析构 沿继承链的虚分发对比模板多态（CRTP）：
对象体积 +0（无 vptr） 虚调用 静态解析，可内联 类型约束 编译期绑定，无运行时多态选择标准：运行期多态（运行时才知道类型、异构容器、插件）用虚函数；编译期就能确定的算法族用模板/CRTP。两者的"汇编真相"截然不同：一个靠 vtable 间接跳，一个靠模板展开直接内联。
⑪ 扩展 FAQ
- Q：vtable 里的槽位顺序是什么？
A：按虚函数在类里的声明顺序（第一个虚函数在槽位 0）。继承时，基类的虚函数槽位排前面，派生类新增的排后面（E09 会看到多重继承时多个 vtable 的槽位规则）。 - Q：
-fno-devirtualize会怎样？
A：关闭去虚化，所有虚调用都走 vtable——可以拿来对比"去虚化到底省了多少"。 - Q：为什么
call变成了jmp？
A：call_base是尾调用（最后一条语句就是调用并返回），编译器把它优化成jmp（复用当前栈帧，E03 的尾调用优化）。虚调用本身也可以是call，尾调用形态只是更省。 - Q：虚拟继承和虚函数是一回事吗？
A：不是。虚函数管"运行时方法分发"（本集）；虚继承管"菱形继承下共享基类子对象"（E09）。两者都涉及 vptr/vtable，但机制不同——虚继承的表叫"虚基类表"。 - Q：怎么查一个对象有几个 vptr？
A：sizeof看多了几个指针；或-O0反汇编构造函数看 vptr 被写入几次。多重继承两个虚基类就有两个 vptr（E09 实测 32 字节）。 - Q：
-O0和-O2下虚调用的汇编差别大吗？
A：大。-O0下基本保留完整的"取 vptr → 查表 → 间接 call"，能看到教科书形态；-O2下可能被投机去虚化、去虚化甚至内联成ret。想看清机制用-O0，想看真实性能用-O2。
⑫ 扩展实验
- 看 vtable：
objdump -s -j .rdata E08_virt.o（或反汇编），在只读段里找 vtable——你会看到一列函数地址。 - 看 vptr 写入：给
Derived写构造，-O0 -S找movq ...(%rax)写 vptr 的指令，确认两次赋值（Base 的、Derived 的）。 - 关去虚化对比：
g++ -O2 -fno-devirtualize -S E08_virt.cpp与默认对比，看call_g/call_final是否变成纯间接跳转。 - 尾调用 vs 普通调用：把
call_base改成int call2(Base* b){ b->f(); return 1; }（非尾调用），看jmp是否变成call。 - 接口 vs CRTP 对照：写同功能的虚函数版和 CRTP 版，
-O2 -S对比——一个保留 vtable 间接跳，一个全内联。
⑭ 扩展专题三：虚调用与 CPU 分支预测的恩怨
为什么"间接跳转"比普通跳转贵？因为 CPU 的分支预测器擅长预测"规律性分支"（循环往回跳、if 大部分走同一侧），但不擅长预测"目标地址未知"的间接跳转。
- 普通
call Base::f：目标地址是编译期常量，CPU 可以预取指令，流水线不停。 jmp *(%rax)：目标地址要等rax算出来才知道，CPU 只能猜（通常猜"和上次一样"）。如果虚调用在循环里每次都指向同一实现（常见），预测器很快学会；但如果交替调用不同实现（多态对象数组轮流调），预测器反复猜错——每次猜错，流水线要冲刷重来，代价可达几十个周期。
所以"虚调用慢"的真正大头不是那两次内存读，而是间接跳转对分支预测的破坏。这解释了：
- 为什么"虚调用在热点循环里"才需要担心（单次调用看不出差，循环里反复触发才累计）；
- 为什么"多态对象数组轮流调虚函数"是性能毒药（预测器永远猜不对）。
实战：如果有一个"类型标签 + switch"就能解决的场景，用std::variant+visit（编译期生成跳转表）往往比虚调用更快——因为它把"运行时类型分发"变成"可预测的分支"。
⑮ 扩展专题四：std::function与虚调用的关系
E11 会细讲std::function，这里先剧透它和虚调用的血缘关系：std::function的类型擦除，本质上就是一个"隐藏的 vtable"。
voidcall_it(conststd::function<void()>&fn){fn();}std::function内部有一个"函数指针 + 控制块"结构（含类型擦除表，即"隐藏 vtable"）；- 调用
fn()时，编译器做间接调用——和虚调用的jmp *(%rax)是同一类成本（E11 会看到call *24(%rcx)的实测汇编）； - 差别在于
std::function连"类型"都擦除了，代价比虚调用更高（多一层间接 + 可能的堆分配）。
血缘总结：虚函数（运行期方法分发）、std::function（运行期可调用对象分发）、虚拟继承（运行期共享子对象定位）——三者都靠"隐藏指针 + 间接访问"，只是在不同的抽象层。理解了虚表，你就理解了它们的一半。
⑯ 扩展专题五：多态与序列化/拷贝的坑
对象带 vptr 后，很多"想当然"的操作变得危险：
memcpy整个对象：会把 vptr 一起拷走。如果源对象和目标的真实类型一致，碰巧能用；不一致（或对象有内部指针）就炸。offsetof/直接按偏移访问成员：vptr 占了开头 8 字节，所有成员偏移都 +8，且布局非标准（E06 讲过is_standard_layout）。- 浅拷贝 + 虚析构：
Base* p = new Derived; Base q = *p;——这调用Base的拷贝构造，切片（slicing），q只有Base部分，虚调用也变成Base的。多态对象不能"按值拷贝"。 - 序列化多态对象：不能直接写内存；要用虚函数（
serialize/deserialize）递归序列化每个具体类型。
核心心法：多态对象用指针/引用传递，用虚函数操作，别按值拷贝、别 memcpy、别当字节数组。这条规则的全部理由，都能在本集和 E06/E07 的汇编里找到。
⑰ 扩展 FAQ（第二轮）
- Q：虚函数表的槽位顺序会不会变？
A：会随"新增虚函数、覆盖、继承顺序"变化，是 ABI 的一部分（E23 会讲）。两个编译器编译同一继承结构，vtable 布局应一致，但别假设细节。 - Q：纯虚函数（
=0）在表里是什么？
A：槽位指向一个"纯虚调用错误处理"函数（__cxa_pure_virtual之类）。调它通常是 bug（在未完成构造的对象上调用纯虚函数）。 - Q：
final加到成员函数和加到类有什么区别？
A：final成员函数阻止进一步 override（对该槽位的去虚化有利）；final类阻止任何继承（让"任何该类型引用都是最终类型"，去虚化更彻底）。 - Q：为什么虚析构要
noexcept？
A：析构默认 noexcept。如果虚析构可能抛，且 delete 时再抛，会std::terminate。基类虚析构设计成不抛是最佳实践。 - Q：
-O2下call_base一定能去虚化吗？
A：不一定。call_base(Base*)接收任意 Base 指针（可能有外部传入的派生类对象），本编译单元看不到全部派生类，通常保留虚调用。去虚化依赖final、具体类型对象、或 LTO 的全局视野。
⑱ 扩展实验（第二轮）
- 交替多态实测：两个不同派生类的对象数组轮流调虚函数 vs 同一类对象数组，测吞吐差——验证"分支预测失败"的代价。
std::function对照：把虚调用换成std::function再测，对比两种间接调用的成本差（E11 会有汇编证据）。- 切片实验：
Base b = *p;（p 指向 Derived），b.f()输出 Base 版本——亲眼确认切片。 memcpy多态对象：复制一个含 vptr 的对象再调用虚函数，观察行为（可能正常、可能崩——UB）。- 纯虚调用：在基类构造函数里调用纯虚函数，运行看
__cxa_pure_virtual报错。
⑳ 扩展专题六：vtable 在内存里的"长什么样"
把 vtable 当数据结构看，它大概是这样的（以Base为例）：
偏移 内容 0 typeinfo 指针（指向 RTTI 类型信息，E10 会用到） 8 offset_to_top（用于多重继承定位，E09 详述） 16 Base::f 的地址 ← 虚函数槽位 0 24 Base::g 的地址 ← 虚函数槽位 1 ... （派生类新增虚函数依次排后）关键细节：
- 表头不只是函数：vtable 前几个槽位还存着 RTTI 指针和"到顶偏移"，它们服务于
dynamic_cast/typeid（E10）和多重继承（E09）。 - 对象里的 vptr 指向 vtable 的"第一个虚函数槽位"（偏移 16 处），而不是表头——所以
movq (%rax)取到的就是第一个虚函数地址。 - vtable 在只读段（
.rdata/.rodata）：它是程序启动时就定好的静态数据，不属于任何对象，对象只有 vptr 指向它。
反汇编验证：objdump -s -j .rdata找 vtable 段，你会看到一排排地址（函数指针），前面几个槽位是 RTTI 相关数据。这印证了 E04 讲的"vtable 住在只读段"。
㉑ 扩展专题七：虚调用与普通调用的完整成本对照表
| 维度 | 普通调用 | 虚调用（未去虚化） |
|---|---|---|
| 指令数 | 1 条call | 取 vptr + 查表 + 间接跳转（3~4 条） |
| 内存访问 | 0（或参数搬运） | 2 次（vptr + 槽位） |
| 分支预测 | 可预测 | 间接跳转，易猜错 |
| 可内联 | 是 | 通常不行（除非去虚化） |
| 编译器优化空间 | 大 | 小 |
这也解释了为什么"性能敏感的多态"应该：
- 尽量用具体类型对象（编译器直接静态调用）；
- 需要抽象时用
final让编译器敢去虚化； - 或者换一种多态：
std::variant+visit（跳转表）、模板/CRTP（编译期展开）、策略模式（模板参数）。
核心判断：如果你的"多态"在编译期就能确定，就不该付出运行期动态分派的成本。汇编的价值就在于让你看清楚"这个抽象到底花了多少条指令"。
㉒ 扩展实验（第三轮）
- 看 vtable 表头：
objdump -s -j .rdata E08_virt.exe，定位 vtable，辨认 RTTI 指针和虚函数地址的排布。 - RTTI 联动：对带虚函数的对象执行
typeid(*b)（E10 会细讲），反汇编看它如何通过 vtable 的 typeinfo 槽位拿类型名。 - 三种多态对照：同一功能分别用虚函数、
std::variant+visit、模板实现，-O2 -S对比"分发代码"的指令数。 - LTO 去虚化：如果编译器支持，把两个翻译单元（一个定义派生类、一个调用虚函数）用
-O2 -flto链接，观察调用是否被去虚化。
㉓ 悬念
一个对象只有一个 vptr 还算仁慈——如果你多重继承两个带虚函数的基类，对象里会出现两个 vptr，地址还得"掰弯"。
