玻尔百科面向对象编程提供了强大的抽象能力，但其灵活性也伴随着代价。虚方法调用允许代码在运行时适应不同的对象类型，但它引入了性能开销，这种开销会阻碍编译器最有效的优化之一：内联。本文探讨了去虚拟化——一系列旨在通过在执行前解析虚方法调用来拆除这一性能障碍的编译器技术。通过理解去虚拟化，我们可以深入了解静态程序分析、运行时动态和语言设计之间复杂的相互作用。本文将首先探索其核心的“原理与机制”，对比编译器对绝对确定性的追求与“押注概率”的实用策略。随后，本文将拓宽视角至“应用与跨学科联系”，揭示这一项优化如何对内存管理、系统架构乃至网络安全产生深远影响。让我们从探究使去虚拟化成为可能的机制开始。
在我们试图理解计算机如何执行我们优雅的面向对象代码时，我们常常想象一个无缝的指令流。然而，在这表面之下，隐藏着一个充满指针、表和查找的复杂机械世界。其中最基本的机制之一就是虚方法调用。它就像一种魔法，允许一个 Shape 变量在运行时正确调用 Circle 或 Square 的 draw() 方法。但这种魔法是有代价的。一次虚调用涉及一次间接查找：首先，获取对象的“虚函数表”（或称 vtable），然后在该表中找到正确的函数指针，最后才跳转到代码。这种间接性不仅仅是多花几纳秒的时间；它是一堵强大的墙，阻碍了编译器最强大的优化之一：内联。如果编译器不知道将要调用哪个 draw()，它就无法简单地将 draw() 的代码粘贴到调用点。
去虚拟化（Devirtualization）正是拆除这堵墙的艺术与科学。它是编译器用来在虚调用发生之前确定其确切目标的一系列技术，从而用快如闪电的直接跳转替换灵活但缓慢的间接调用。理解去虚拟化，就是理解语言设计、静态分析和运行时动态之间深刻的相互作用。这是一个关于两种宏大策略的故事：对绝对确定性的追求，以及押注概率的智慧。
想象你是一个编译器，你被赋予了一项超能力：你可以一次性看到整个程序——每一行代码、每一个库、每一个类。这就是封闭世界假设（closed-world assumption）。有了这种全局视野，你就可以构建一幅完整的类世界地图，即类层次结构（Class Hierarchy）。这张地图是第一种也是最直接的去虚拟化形式——类层次结构分析（CHA）——的关键。
假设我们有一个调用 vehicle.move()。变量 vehicle 被声明为 Vehicle 类型。通过 CHA，编译器可以查看类层次结构并提问：在这个整个程序中，Vehicle 的所有具体子类有哪些？也许它们是 Car、Boat 和 Plane。然后编译器会检查它们各自的 move() 方法。如果运气好，它们每一个最终都使用了完全相同的实现（也许 Car 和 Plane 重写了它，但 Boat 继承了与 Car 相同的实现），那么编译器就能 100% 确定目标。虚调用被替换为直接调用。这堵墙倒塌了。
当程序员给编译器一点帮助时，这就变得异常简单。如果一个类被声明为 final，意思就是“谁都不能继承我”。如果 vehicle 变量的类型是一个 final 类，比如说 ElectricScooter，那么就完全没有歧义了。该对象必然是 ElectricScooter，这个调用就可以被去虚拟化。同样的逻辑也适用于方法本身被声明为 final 的情况；即使存在子类，它们也无法提供新的实现，所以所有子类都会使用同一个实现。
这揭示了语言设计者和编译器开发者之间一种美妙的合作。如果我们改变语言的默认规则会怎样？在许多语言中，类默认是“开放”的，意味着它们可以被自由地继承。这迫使开发者必须主动使用 final 来锁定某些东西。如果我们反过来呢？如果类默认是 final，而你必须显式地将它们标记为 open 呢？
让我们设想一个假设场景。假设在一个典型的代码库中，只有 15% 的类被显式标记为 final。又假设当编译器知道接收者的确切类并且该类是 final 时，一个虚调用可以被去虚拟化，这种情况大约发生在 60% 的此类调用中。那么总的去虚拟化率将是 ，即 9%。现在，我们切换到一种 final-by-default（默认 final）的语言。在一个典型的代码库中，也许只有 25% 的类曾经被真正继承过，开发者可能会有点过于谨慎，额外将 5% 的类标记为 open 以防万一。这意味着 30% 的类是 open 的，而高达 70% 的类现在默认是 final 的。去虚拟化率飙升至 ，即 42%。仅仅通过改变一个默认设置，我们就使得代码的可优化性提高了近五倍。像 Swift 和 Kotlin 这样的现代语言正是因此采纳了这种 final-by-default 的哲学。此外，还存在一种折衷方案，即密封类（sealed classes）等特性，它告诉编译器：“这个类可以被继承，但只能被这里明确列出的特定类继承。” 这为类层次结构的一部分恢复了封闭世界的保证，给了编译器它所渴望的确定性。
我们越是研究这些技术，就越可能想知道是否存在一个更简单、更基本的原则在起作用。事实证明确实如此。从本质上讲，一次虚调用只是一系列问题。一个 x.m() 调用会被编译器降级为类似这样的东西：
x的运行时类型是B类吗？如果是，调用B_m(x)。 否则，x的运行时类型是C类吗？如果是，调用C_m(x)。 否则...
现在，考虑一段对同一个对象进行两次调用的代码：x.m() 后面跟着 x.n()。编译器会天真地为这两次调用生成两个这样的问题级联。但等一下。typeof(x) 表达式——即查找 x 的运行时类型——是一个纯计算（pure computation）。它每次都会给出相同的答案（假设对象的类型不变），并且没有副作用。我们这是在问完全相同的问题两次！
这就是经典的编译器优化——公共子表达式消除（CSE）——登场的地方。CSE 是良好整理工作的一般原则：如果可以，永远不要重复计算同一个东西。编译器可以将代码转换为：
t = typeof(x)t是B类吗？如果是，调用B_m(x)。t是C类吗？如果是，调用C_m(x)。 ...t是B类吗？如果是，调用B_n(x)。t是C类吗？如果是，调用C_n(x)。 ...
通过提升 typeof(x) 检查，编译器可以意识到，在“如果 t 是 B”的分支内，两个虚调用现在都被确认为是在一个 B 对象上进行的。两个调用一举被去虚拟化了！从这个角度看，去虚拟化并不是一个特殊、神奇的技巧；它只是计算整洁性这一普适原则的一个具体应用。
这个思想还可以用更复杂的方式扩展。编译器可以执行路径敏感分析（path-sensitive analysis），像侦探收集线索一样。如果代码中写着 if (x instanceof B)，编译器就知道在那个 if 块内部，x 的类型被细化为 B。它可以将这个信息向前传递。如果不同的代码路径汇集到一个合并点，编译器会合并所有路径的信息——合并点处可能的类型集合是每个传入路径类型集合的并集。如果这个并集仍然能解析到单一的方法目标，那么该调用就可以被去虚拟化。
对静态确定性的追求是强大的，但它建立在一个脆弱的基础之上：封闭世界假设。当世界不是封闭的时会发生什么？许多现代应用程序依赖于插件、动态库或其他形式的后期绑定。
想象一下我们的编译器，在分析了整个应用程序后，证明某个特定的调用只会接收 A 类的对象。它自信地用一个对 A.m() 的直接调用替换了虚调用。但随后，在运行时，用户加载了一个插件。这个插件包含一个新的类 B，它也有一个 m() 方法。程序接着创建了一个 B 的实例，并将其传递给带有去虚拟化调用点的代码。程序没有调用 B.m()，而是错误地调用了 A.m()。这不仅仅是一个性能错误；它是对程序正确性的灾难性破坏。
反射（Reflection）是另一个给静态分析带来麻烦的强大语言特性。像 Class.forName(someString).newInstance() 这样一行代码，可能会创建任何一个类名由 someString 提供的类的实例。如果该字符串来自用户输入或配置文件，编译器根本无法知道将创建哪个类。
一个天真的编译器可能会完全放弃，如果在任何地方使用了反射，就全面禁用去虚拟化。但现代编译器更加务实。它们将未解析的反射视为一个保守屏障。分析会做最坏的打算——即任何兼容的类都可能被创建——但它将这种不确定性仅局限于从反射调用流出的数据。关于不相关的、局部创建的对象的信息仍然是精确的。此外，编译器可以识别安全的反射子集。如果代码写着 Class.forName("B")，使用了一个字符串字面量，编译器就可以静态地解析它，并重新获得确定性。
动态世界带来的挑战催生了第二种截然不同的哲学，并由即时（JIT）编译器所倡导。JIT 编译器与程序一同运行，观察其执行。它不需要绝对的、静态的证明；它可以根据运行时实际发生的情况来做决策。这就是押注概率的策略。
JIT 编译器采用基于性能分析的优化（PGO）。它监控一个“热点”虚调用点——即一个被频繁执行的调用点。它可能会观察到，99% 的情况下，到达 shape.draw() 的对象是一个 Circle。虽然它无法证明它将永远是一个 Circle，但它可以下一个非常有利可图的赌注。这引出了守护式去虚拟化（guarded devirtualization）。JIT 会重写代码为：
if (shape is a Circle) { call Circle.draw() directly; } else { perform the original slow virtual call; }
这是一个绝妙的权衡。类型检查（即守护，guard）会有一点小成本，但当守护成功时，直接调用带来的收益是巨大的。如果猜测正确的概率足够高，那么这项优化就是有利可图的。我们甚至可以量化这一点。设守护的成本为 ，直接调用节省的成本为 （其中 是虚调用成本， 是直接调用成本），对象是预测类型的概率为 。如果预期的节省超过了守护的成本，那么优化就是划算的。一点代数运算就能得出一个优美而简单的条件：当 时，这项优化就是值得的。对于典型的成本，这个阈值可能低至10%，这意味着即使是一个不算太“热”的类型也值得押注。
如果一个调用点不是由一种类型主导，而是由两种或三种呢？例如，一个图形用户界面（GUI）的事件处理器可能主要看到 MouseClick 和 KeyPress 事件。JIT 可以将守护检查扩展成一个链条，这种优化被称为多态内联缓存（PIC）。它首先检查最频繁的类型，然后是第二频繁的，以此类推，最后才回退到完整的虚调用。这种自适应策略允许 JIT 根据程序的实际运行时行为完美地定制代码。
归根结底，去虚拟化是一个入口。它最大的成就是它促成了内联——将方法体直接复制到调用处，从而完全消除调用开销。这反过来又解锁了一系列其他优化。
但是天下没有免费的午餐。每次内联一个方法，编译后代码的体积都会增长。如果一个多态调用点通过为每种可能的类型克隆代码来进行去虚拟化，代码可能会显著膨胀。这是经典的时空权衡。编译器使用复杂的启发式算法来决定何时值得用代码大小和指令缓存压力的代价来换取内联带来的性能提升。
从静态分析的刚性逻辑到 JIT 的概率性押注，去虚拟化是整个编译器优化领域的缩影。它是静态与动态、确定性与概率、语言的优雅语义与底层机器的残酷现实之间的一场优美舞蹈。
在窥探了去虚拟化的内部工作原理之后，你可能会留下这样的印象：它是一个聪明但有些小众的技巧——一种从函数调用中削减几纳秒的方法。但这样看待它就只见树木，不见森林了。去虚拟化不仅仅是一项优化；它是一种使能优化（enabling optimization）。它是一把万能钥匙，一旦转动，就能打开一扇通往更深层次程序理解和转换的宏伟大厅的一系列门。正是在这种级联效应中，在这种洞见的连锁反应中，才蕴含着它真正的力量与美。
让我们踏上一段旅程，看看这一项编译器技术如何在软件领域掀起涟漪，影响着从原始性能和内存使用到操作系统架构乃至我们数字世界的安全等方方面面。
想象一下，编译器是一位正在检查程序源代码证据的侦探。虚调用就像一个拒绝开口的证人，模糊地指向一群可能的嫌疑人。编译器受证据规则的约束，必须做最坏的打算：这个神秘的函数调用可能做任何事。它可能改变任何变量，写入内存的任何部分，或者走向一条完全未知的路径。
去虚拟化是证人决定开口的时刻。通过证明对象的真实类型，编译器确定了唯一的嫌疑人。突然间，案情豁然开朗。曾经神秘的函数体现在被赤裸裸地摆出来接受检查，而魔法也从此开始。
考虑这样一种情况：程序检查一个对象的类型。如果类型是 ，它就执行一个虚调用。但如果编译器从更宏观的视角看，能够证明传入这整个代码段的对象总是 类的实例呢？这种更高级别的上下文信息，或许来自于对程序主入口点的分析，将类型检查变成了确定无疑的事。一个聪明的编译器，有了这些知识，就会意识到“if”条件永远为真。“else”分支现在成了死代码——一条永远不会被执行的幽灵路径。它可以被剪除，从而简化程序。一旦那条路径消失了，“if”分支内的虚调用现在只有一个可能的目标。咔哒一声。去虚拟化发生了。编译器现在可以内联目标方法的主体了。
而这种连锁反应还在继续。也许内联的代码中包含另一个条件 if (D)，其中 是一个在编译时被设为零的常量。在此之前，这个检查在一个不透明的函数内部。现在，它成了周围代码的一部分，编译器看到这个条件永远为假。这个 if 块内的代码，本来可能会执行一个昂贵的副作用，现在也被证明是死的，并被消除了。最初只是程序中远隔千里的一个简单类型事实，通过去虚拟化、内联和常量传播的连锁反应，移除了整块不可达的代码及其副作用。
这种连锁反应不仅使代码更小，还使其更安全、更快。想象一个处理小型、固定大小数组的函数。在访问元素之前，它尽职尽责地执行边界检查：索引 i 是否小于数组的长度？这个检查在循环中重复数百万次，成本会累积起来。长度是通过一个虚调用 b.len() 获取的。没有去虚拟化，编译器不知道 b.len() 会返回什么。但通过全程序分析，它可能会发现对象 b 总是特定类 Small 的实例，而 Small 类的 len() 方法只是简单地返回常量 4。
去虚拟化用直接调用替换了虚调用，而过程间分析将常量 4 传播回调用者。原本迭代到未知长度的循环，现在已知是从 i=0 到 3。有了这个坚如磐石的保证，编译器可以审视数组访问函数内部的边界检查，并以数学证明般的确定性意识到，条件 i 4 将永远为真。这个检查是多余的。它可以被消除，从而从程序最热的部分移除了一个条件分支。
去虚拟化的影响可能在程序如何使用内存方面最为显著。在许多现代语言中，对象创建在堆（heap）上——一个巨大、灵活但相对较慢的内存区域。在堆上分配和释放内存需要大量的簿记工作。一个快得多的替代方案是栈（stack），它是当前执行函数的临时工作空间。
问题在于，一个对象只有在编译器能证明它在函数返回后永远不会被使用时，才能被放置在栈上。我们说这个对象不能“逃逸”（escape）。在一个新创建的对象上进行虚方法调用是一条典型的逃逸路径。编译器无法看透虚调用的内部，因此必须假设该函数可能会将对象的引用存储在某个会比当前函数生命周期更长的地方。为了安全起见，它将对象分配在堆上。
去虚拟化砰地一声关上了这个逃逸舱口。通过揭示被调用方法的主体，编译器可以精确地分析它。它能看到该方法只使用了对象的字段，并没有偷偷地把它的引用藏起来。有了这个证明，对象就不再有“潜逃”风险了。编译器可以安全地将它分配在栈上，这比堆分配快几个数量级。对于一个在循环内创建数百万个短生命周期对象的程序来说，这一个改变就可能决定了应用是迟缓还是响应迅速。
但我们可以更进一步。一旦我们知道一个对象只存在于栈上，我们为什么还需要一个“对象”呢？为什么要把它的字段组合在一块连续的内存中？如果编译器能看到对象及其字段的所有用途，它可以执行一个更激进的转换：聚合体标量替换（SRA）。对象本身被“非物质化”了。它消失了。它的字段，比如说 f 和 g，被“提升”为独立的标量变量。这些变量通常可以直接存储在 CPU 的寄存器中——这是所有内存中最快的。每一次对 o.f 的读写都变成了对寄存器的直接操作。内存分配，无论是堆上还是栈上，都完全被消除了 [@problem_aroblem_id:3669660]。去虚拟化往往是实现这一强大优化所需的逃逸分析的第一步，也是最关键的一步。
这个原则延伸到各种内存管理策略。在使用引用计数（RC）的系统中，销毁一个对象需要递减它所持有的每个字段的引用计数。对于一个有 个字段的对象，这意味着需要对 RC 运行时进行 次独立的函数调用。但如果去虚拟化允许编译器内联对象的析构函数，它现在就知道对象的精确内存布局。它可以看到 个引用计数的指针连续排列。这带来了一项巨大的优化：不再是 次单独的 release 调用，而是可以进行一次优化的 batch_release 调用，传递字段的起始指针和数量 。这减少了函数调用开销并改善了代码局部性，所有这一切都因为我们知道了对象的具体类型。
去虚拟化的影响超出了优化给定代码的范畴；它塑造了大型软件系统的架构。这里的关键概念是封闭世界假设。
全程序去虚拟化只有在编译器能看到所有将要运行的代码时才是真正安全的。如果一个新的类可以在之后被动态加载，它可能会引入一个接口的新实现，从而使编译器先前关于虚调用只有一个目标的假设失效。
这产生了一种基本的设计张力，在操作系统和嵌入式应用中尤其明显。
考虑一个嵌入式系统，比如你车里或医疗设备中的软件。这些系统通常被静态链接（statically linked）成一个单一的、单体可执行文件（monolithic executable）。出于可靠性和安全性的原因，动态加载是被禁止的。这种环境在设计上就是一个“封闭世界”。对编译器来说，这是一个绝佳的机会。它可以带着绝对的确定性进行全程序分析，知道类层次结构是固定的。它可以在整个系统中积极地去虚拟化调用，从而产生更小、更快、更可预测的代码——这些都是资源受限和实时环境中至关重要的属性。
现在考虑一个现代的操作系统内核。操作系统需要是可扩展的，允许第三方驱动程序为新硬件在运行时加载。这是一个“开放世界”。如果内核的核心例程对驱动程序接口进行虚调用，编译器默认情况下无法对它们进行去虚拟化。它必须维持一个稳定的应用程序二进制接口（ABI），以便这些未来的、未知的驱动程序能够正确地接入。在这里，对灵活性的需求似乎排除了去虚拟化带来的性能优势。
这种张力导致了有趣的架构权衡。一种策略是强制实行一个“密封世界”：发布一个内核，其中所有必要的驱动程序都已编译并链接在一起，并禁止加载任何其他驱动程序。这最大化了性能但牺牲了灵活性。一种更务实的方法是守护式或推测性去虚拟化。编译器分析在编译时已知的驱动程序。在一个热点路径上，它插入一个检查：“这个驱动对象是我预期的那个吗？”。如果是，它就走一条高度优化的、直接调用的快速路径。如果不是，它就回退到标准的、较慢的虚派遣。这提供了两全其美的方案：为常见情况提供优化性能，同时为未知情况保证正确性和灵活性。
近年来，去虚拟化出现了一个新的、关键的应用：网络安全。从机器层面看，虚调用是一个间接分支。处理器跳转到存储在内存中的一个地址。这种间接性是一个弱点。如果攻击者能够破坏对象的数据（特别是其虚函数表指针），他们就可能将一个虚调用重定向到一段恶意代码，从而劫持程序的控制流。
去虚拟化是防御此类攻击的有力武器。当一个虚调用被替换为直接调用时，间接分支就被消除了。目标地址现在被硬编码到指令本身中。攻击者没有可以破坏的内存位置；控制流是固定的、安全的。
在安全关键的沙箱环境中，动态代码加载正是为了防止攻击而被禁止的，在这种环境下，这种转换不仅仅是性能调整——它是一种安全加固措施。通过执行全程序分析，编译器可以识别并消除尽可能多的间接调用。每一个被消除的虚调用都为攻击者关上了一扇潜在的大门。
那么，那些真正具有多态性而无法完全去虚拟化的调用呢？在这里，从分析中获得的知识同样是一种安全福音。编译器不再生成一个可能跳到任何地方的模糊的间接调用，而是可以生成一个带有精细控制流完整性（CFI）检查的派遣机制。对于一个接收者可能是 或 类型的调用点，编译器会生成代码，明确检查目标地址是否为 A::f 或 B::f 的地址。任何试图跳转到第三个位置的尝试都会被阻止。这将攻击面从“内存中的任何地方”急剧缩小到一个小的、明确定义过的有效目标集合。
从这个角度看，去虚拟化是计算机科学统一性的一个美丽范例。一项源于对性能的追求、植根于编程语言理论逻辑的技术，已经成为现代网络安全武器库中的一个重要工具。它向我们展示了，要深入理解一个程序以使其运行得更快，所需的理解往往与使其更安全所需的理解是完全相同的。