C++ 虚析构函数：多态基类的安全销毁
08 多态基类为什么通常需要虚析构函数
当使用 delete 销毁一个对象时，编译器需要明确两点：这个对象的完整类型是什么，以及它的析构函数在哪里。如果在代码中写下 delete ptr，而 ptr 的静态类型是 Base*、动态类型却是 Derived* 时，假如 Base 的析构函数不是虚函数，编译器就只能依赖静态类型来决定调用哪一个析构函数。于是它会调用 Base::~Base()，然后释放 sizeof(Base) 大小的内存。这会导致一个严重的后果：Derived 对象中那些 Base 并不知晓的新增成员，其析构函数根本不会被执行；而且释放的内存大小也可能与实际分配的不匹配。C++ 标准明确将这种情况归类为未定义行为。本章将详细梳理这背后的逻辑：删除操作到底需要哪些信息，虚析构函数又是如何提供这些信息的，以及在设计多态基类时，该如何在虚析构、受保护非虚析构和纯虚析构之间做出合理的选择。
一个危险但常见的模式
凡是在多态场景下编写过工厂函数或对象容器的开发者，大概率都写出过类似下面这种结构的代码：
#include <iostream>#include <string>class Base {
std::string id_;
public:
Base(const std::string& id) : id_(id) {
std::cout << "Base ctor: " << id_ << '\n';
}
~Base() { std::cout << "Base dtor: " << id_ << '\n'; }
virtual std::string name() const { return "Base"; }
};
class Derived : public Base {
std::string extra_;
public:
Derived(const std::string& id, const std::string& extra)
: Base(id), extra_(extra) {
std::cout << "Derived ctor: " << extra_ << '\n';
}
~Derived() { std::cout << "Derived dtor: " << extra_ << '\n'; }
std::string name() const override { return "Derived"; }
};
// 危险：通过基类指针删除派生对象// int main() {// Base* p = new Derived("obj1", "payload");// delete p; // 未定义行为：Base::~Base() 不是虚函数// }
上面 main 函数中的代码被注释掉了，因为一旦执行，程序就会陷入未定义行为。我们来剖析一下过程：new Derived(...) 在堆上分配了一个完整的派生对象，包含了 Base 子对象和新增的 Derived::extra_ 成员，然后返回的指针被隐式转换为 Base* 类型。在 C++ 中，“未定义行为”意味着标准不再对程序的运行结果提供任何保证。它不一定表现为程序崩溃，甚至有时表面上看起来“一切正常”。如果编译器只执行了 Base::~Base()，跳过了 Derived::~Derived()，那么 extra_ 成员持有的资源（如动态内存、文件句柄等）就会被悄无声息地泄漏。更为致命的是，底层内存分配器接收到的待释放大小可能是 sizeof(Base)，这会导致内存块管理出现混乱，对于自定义分配器或调试环境而言，往往是灾难性的。
问题的根源在于，delete 操作依赖指针的静态类型来推断析构函数和对象尺寸。当 p 的静态类型是 Base* 时，编译器生成的指令相当于：调用 p->~Base()，随后将 p 所指的 sizeof(Base) 大小的内存交还给系统。在这个过程中，编译器对 Derived 的存在一无所知。要想打破这种静态绑定，唯一的途径就是引入虚析构函数：它能让析构操作如同普通虚函数一样进行动态分派，在运行时准确找到真正需要被调用的那个析构函数，从而沿着派生链逐级完成清理。
虚析构函数如何恢复完整的销毁路径
将 Base 的析构函数声明为虚函数非常简单，只需加上 virtual 关键字即可：
class Base {
std::string id_;
public:
Base(const std::string& id) : id_(id) {
std::cout << "Base ctor: " << id_ << '\n';
}
virtual ~Base() { std::cout << "Base dtor: " << id_ << '\n'; }
virtual std::string name() const { return "Base"; }
};
class Derived : public Base {
std::string extra_;
public:
Derived(const std::string& id, const std::string& extra)
: Base(id), extra_(extra) {
std::cout << "Derived ctor: " << extra_ << '\n';
}
~Derived() override { std::cout << "Derived dtor: " << extra_ << '\n'; }
std::string name() const override { return "Derived"; }
};
在这里，~Derived() override 中的 override 并非语法层面的强制要求，但它是个很好的习惯。它能让编译器帮你校验基类是否真的声明了虚析构函数，若是漏写了 virtual，编译时就会报错，这显然比在运行时排查资源泄漏要安全得多。此时再次执行删除操作，输出将会是：
Base ctor: obj1
Derived ctor: payload
Derived dtor: payload
Base dtor: obj1
可以看到，析构顺序是先执行 ~Derived()，再执行 ~Base()，这与构造时的顺序正好相反。如前所述，派生对象和基类子对象共享同一块内存区域，拆除时必须从最外层的派生状态开始，最后才能拆除承重的基类基底。虚析构函数的核心作用就是保证“入口正确”：当执行 delete 时，调用的起点不再是 ~Base()，而是运行时确定的 ~Derived()。一旦找对了入口，编译器就会按照逆构造的顺序，自动展开整条析构链，无需虚机制去逐级干预。
从底层实现的角度来看，这有助于我们更好地区分标准语义和编译器的 ABI 实现。在常见的编译器（如 GCC 或 MSVC）中，类中第一个虚函数的出现会促使编译器生成一个虚函数表（vtable），并在对象内部安插一个虚表指针（vptr）。虚析构函数会在虚表中占据一个槽位，在派生类的虚表中，该槽位则指向派生类自己的析构函数。当编译器遇到 delete p 时，它不再直接调用一个写死的地址，而是通过对象内部的 vptr 查找虚表，提取出实际的析构函数地址再进行调用。这多出来的一次间接寻址就是运行时多态的代价，但在绝大多数情况下，这种微小的性能开销是可以忽略不计的。
需要注意的是，虚表、虚表指针等概念并非 C++ 标准的内容，而是编译器的实现手段。标准只约束了行为：“当通过基类指针删除派生类对象时，如果基类有虚析构函数，就必须先调用派生类的析构函数，然后逐级向上调用基类的析构函数”。了解底层机制能帮助我们建立直觉，但切勿将其混同为语言规范本身。
基类一旦声明了虚析构函数，这种虚特性便会自动向后代传递。整个继承树中的所有析构函数（包括编译器自动生成的）都会成为虚函数。这样，无论在哪一层执行 delete，都能确保从最底层的派生类开始正确启动析构流程。
在多级继承中，这种机制也是递归有效的。假设有 Base -> Middle -> Leaf 的继承链，当通过 Base* 删除一个 Leaf 对象时，调用顺序必然是 ~Leaf() -> ~Middle() -> ~Base()。每一级都在清理各自的成员，最后由基类收尾。值得澄清的是，并不是这其中的每一步都依赖虚表跳转。实际上，只有起点的调用需要虚函数机制来定位，一旦进入了 ~Leaf()，后续的向上的析构调用都是由编译器自动静态展开的，不再需要运行时的动态查找。因此，虚析构函数并不会因为层级深而带来额外的虚调用开销，它同样只在虚表中占据一个槽位。
一个类什么时候需要虚析构函数
判断一个类是否需要虚析构函数的标准，正如 Scott Meyers 在《Effective C++》中所建议的：如果一个类被设计为多态基类（即准备让别人通过基类的指针或引用来操作派生类对象），那么它通常就需要声明虚析构函数。这个原则的核心不在于“类里有没有虚函数”，而在于“是否存在通过基类接口销毁派生类对象的可能”。假设你写了一个没有虚函数的基类，但某个工厂函数却返回了指向派生类的 Base* 指针，此时这个基类依然需要虚析构函数来防止泄漏。
反过来，并非所有带有虚函数的类都必须配有虚析构函数。如果你的设计明确禁止通过基类指针删除对象（比如对象都分配在栈上，或总是由具体的派生类去管理生命周期），那么缺少虚析构并不会造成实质性问题。然而，在日常维护中，“设计意图”往往容易被遗忘，下一个接手的程序员很可能顺手就写下了 delete。因此，业界的通用法则是：只要类中包含了虚函数，就顺手把析构函数也声明为虚的。这是一种防御性编程的体现，而非死板的语法规定。
需要特别警惕的是：智能指针 std::unique_ptr<Base> 并不能替你解决虚析构缺失的问题。
#include <memory>// Base 的析构函数不是虚函数（设计缺陷）
std::unique_ptr<Base> p = std::make_unique<Derived>("obj", "data");
// p 离开作用域时，unique_ptr 调用 delete，触发未定义行为
unique_ptr 默认的删除器本质上依然是在执行 delete ptr，如果基类没有虚析构，它同样会陷入未定义行为。虽然你可以通过自定义删除器来规避，但这只是补救措施，不能替代正确的设计。相比之下，shared_ptr 的表现有所不同，它在构造时会记住传入指针的实际静态类型，即使后来隐式转换为了 shared_ptr<Base>，析构时依然会调用当初记录类型的析构函数。即便如此，依赖 shared_ptr 的这种特性去掩盖设计缺陷也是不可取的，因为它会让代码的意图变得含糊不清。
另一种策略：受保护的非虚析构函数
如果一个基类仅仅是作为多态调用的接口，并且在设计上明确拒绝通过基类指针来销毁对象，那么有一种比虚析构函数更精准的表达方式：将析构函数声明为 protected 且非虚。
class NonDeletableBase {
public:
virtual void process() = 0;
protected:
~NonDeletableBase() = default; // 非虚，受保护
};
class ConcreteProcessor : public NonDeletableBase {
public:
void process() override { /* ... */ }
~ConcreteProcessor() = default; // 公开，外部可通过派生类指针直接删除
};
受保护的析构函数向外界传达了一个清晰的语义：不允许直接对 NonDeletableBase* 调用 delete，编译器会直接拦截这种非法操作。而派生类作为内部继承者，依然可以访问基类的 protected 成员，所以派生对象的正常销毁不受影响。当派生类对象被删除时，析构链依然能顺畅地走到 ~NonDeletableBase()。这种模式非常适合用来定义“纯接口类”（如策略模式、观察者模式中的接口）。在这些场景下，生命周期的管理应当由派生类自身负责，基类仅仅是提供一套方法契约。
虚析构函数和受保护的非虚析构函数代表了截然不同的设计哲学，不应混为一谈。声明虚析构，意味着“允许通过基类指针安全地管理和销毁对象”；声明受保护非虚析构，意味着“我只是个接口，请自己管好生命周期”。最糟糕的情况是基类既有虚函数，其析构函数又是公开非虚的，这无疑是在为未来的内存泄漏埋下隐患。因此，如果你的多态基类不希望被外部直接 delete，请务必将其析构函数加上 protected 保护，让编译器来替你守好边界。
纯虚析构函数的定义边界
有时你可能希望一个类既是抽象基类（不能被实例化），又具备虚析构函数的能力。通常的做法是将析构函数声明为纯虚函数：
class AbstractBase {
public:
virtual ~AbstractBase() = 0; // 纯虚析构函数virtual void doWork() = 0;
};
= 0 使 AbstractBase 成为抽象类，直接创建它的实例会在编译时报错。但析构函数比较特殊：无论它是否纯虚，派生类在析构时都一定会调用基类的析构函数。如果基类的纯虚析构函数只有声明没有实现，链接器在处理派生类的隐式调用时就会报“找不到符号”的错误。因此，纯虚析构函数必须在类外提供一个定义，哪怕函数体是空的：
AbstractBase::~AbstractBase() = default; // 必须在类外提供定义
C++ 语法不允许在类内既写 = 0 又写上函数体，所以只能在类外补充。这个定义本身不需要做任何实际清理工作（= default 就足够了），它的唯一使命是在析构链到达终点时提供一个合法的执行目标。这里的“纯虚”并不是指“没有实现”，而是单纯用来限制类的实例化。普通纯虚函数通常不提供实现，导致很多人误以为纯虚函数必定没有函数体，但在析构函数这里，语言为了兼顾抽象类的定义需求和析构链的完整性，巧妙地将这两者结合在了一起。
设计检查清单
我们可以将上述讨论总结为几个实用的问题，帮助在设计类结构时做出明智的决定：
第一，这个类会被继承吗？如果答案是否（例如它被 final 修饰，或是没有虚函数的底层实现类），那么保持公开的非虚析构函数即可。
第二，如果会被继承，这个类的对象会被人通过基类指针删除吗？只要存在“可能”（例如暴露了基类指针的工厂函数，或用于容器管理），就应该毫不犹豫地声明虚析构函数。在一个长期维护的项目里，你无法预判所有的调用场景。考虑到虚析构的极低开销和缺失带来的高风险，添加虚析构几乎总是最具性价比的选择。
第三，如果不需要通过基类删除，但需要提供多态接口呢？这时候应该使用受保护的非虚析构函数。通过编译期的权限拦截来表达设计意图，比依赖注释或口头约定要可靠得多。
第四，是否需要让基类本身禁止实例化？如果需要，且同时需要虚析构能力，那就使用纯虚析构函数，并记得在类外提供定义。即使基类中的其他方法都有默认实现，纯虚析构函数也能完美胜任阻止实例化的任务。
第五，在涉及不完整类型的前置声明时，如果使用了 unique_ptr<Base>，必须确保析构函数的定义在 unique_ptr 执行删除时是可见的。虽然这与虚析构不完全是一回事，但在结合继承和 PIMPL 模式时需要格外小心。
这些决策应该在类设计的初期就明确下来，就像对象在构造时必须进入合法状态一样。类型一旦确立，其继承策略和生命周期边界就应该清晰无误地刻在代码的基因里。
虚析构函数巧妙地将继承、多态和资源管理这三条面向对象的脉络交织在一起。它用微不足道的底层开销，换取了整个继承树在销毁时的绝对安全。理解了内部机制后，下一章我们将把视角转向模块之间的协作，探讨如何利用抽象接口、组合和依赖注入，在系统层面构建出更为灵活、稳固的边界架构。
阅读导航
