我知道虚函数在调用方法时有解引用的开销。但我认为随着现代架构速度的提高，这几乎可以忽略不计。
更新：
从Jon Skeet的下面的回答概括：
这是一个权衡取舍，即明确地让某人意识到他们正在继承功能[这本身具有潜在风险[(请检查Jon的回答)] [和潜在的小性能收益]与更少的灵活性、更多的代码更改和更 steeeper 学习曲线的交换。
其他答案的原因：
虚函数不能内联，因为内联必须在运行时发生。当您期望函数受益于内联时，这会对性能产生影响。
可能还存在其他原因，我很想知道并总结它们。
除了性能因素外，控制哪些方法是虚方法还有很好的理由。在Java中，虽然我实际上没有将大多数方法设为final，但我可能应该这样做......除非一个方法被设计成可重写，否则在我看来它可能不应该是虚方法。
为继承设计程序可能比较棘手-特别是这意味着您需要更详细地记录谁会调用方法以及它可能调用的内容。想象一下如果您有两个虚方法，并且其中一个调用另一个-那么就必须对它进行说明文档，否则某人可能会使用一个实现来覆盖“被调用”的方法，而这个实现将调用“调用”方法，从而无意中创建一个栈溢出（或如果有尾递归优化，则为无限循环）。此时，您的实现将变得不够灵活，并且不能在后期将其反转。
请注意，C＃与Java在各种方面都是类似的语言，但选择默认使方法不可重写。有些其他人不喜欢这种方法，但我肯定欢迎它-而且我实际上更希望默认情况下类也是不可继承的。
基本上，这归结为Josh Bloch的建议：要么为继承设计，要么禁止它。
C++ 的主要原则之一是：只为所用付费（“零开销原则”）。如果您不需要动态分发机制，就不应为其开销买单。
作为基类的作者，您应该决定哪些方法可以被覆盖。如果您同时编写这两个类，可以进行必要的重构。但是它的工作方式是这样的，因为必须有一种方法让基类的作者控制其使用。
但我认为现代架构的速度已经几乎可以忽略不计了。
这种假设是错误的，我想这也是做出这个决定的主要原因。
以内联函数为例。C++的sort函数在某些情况下比C的类似qsort函数执行得快得多，因为它可以内联其比较器参数，而C不能（因为使用函数指针）。在极端情况下，这可能意味着高达700％的性能差异（Scott Meyers，《Effective STL》）。
对于虚函数来说，情况也是如此。我们之前也有过类似的讨论；例如“是否有理由使用C++而不是C、Perl、Python等？”
qsort 的调用被内联，则 DFA 可能会证明函数指针的值，在这种情况下，调用可能被内联，尽管我从未深入研究过 gcc 在执行此操作时的成功率。 - Steve Jessopqsort 的调用很少被内联。另一方面，sort 是一个模板，因此对于给定的比较器，即使没有内联，其类型也在sort内部已知。我怀疑对于已知动态类型的虚函数调用的内联也是如此。 - Konrad Rudolphqsort有时会因为在不同的TU中而被禁止内联，而sort则始终在TU中可用。有点意思的是，可以采取链接时优化的实现，并查看它们在内联qsort和内联比较器方面是否比内联sort及其比较器更好或更差（当将函数指针传递给sort而不是用户定义类型的函数对象时，以保持比较公平）。 - Steve Jessopstruct和class。
从设计角度来看，每个公共函数都在您的类型与类型用户之间建立契约，而每个虚函数（无论是公共的还是非公共的）则在扩展您的类型的类之间建立不同的契约。签署的这些契约越多，您所做的更改空间就越小。事实上，有相当多的人，包括一些知名作家，认为公共接口不应包含虚函数，因为您对客户的承诺可能与您要求扩展的承诺不同。也就是说，公共接口显示您为客户做了什么，而虚接口显示其他人如何帮助您完成它。
虚函数的另一个影响是它们总是被分派到最终覆盖者（除非您明确限定调用），这意味着任何用于维护您的不变式（例如私有变量的状态）的函数都不应该是虚函数：如果一个类扩展它，它将不得不作出显式的限定调用以回到父类，否则会在您这一层上破坏不变式。
这就像@Jon Skeet提到的无限循环/堆栈溢出的例子，只是以不同的方式：您必须在每个函数中记录它是否访问任何私有属性，以便扩展程序确保正确地调用该函数。这反过来意味着您正在破坏封装，并且您具有泄漏的抽象层：您的内部详细信息现在成为接口（文档+对扩展的要求）的一部分，您不能随心所欲地修改它们。
接下来是表现问题… 在大多数情况下，性能影响被夸大了，可以说只有在性能至关重要的少数情况下，您才会放弃使用虚函数并将其声明为非虚函数。但是，在已构建的产品上可能并不简单，因为两个接口（公共接口+扩展接口）已经绑定。
我来晚了，所以我会补充一件事情，我没有看到其他答案中提到的内容，并且快速概括一下...
在共享内存中的可用性：虚函数调度的典型实现在每个对象中都有一个指向特定类虚函数调度表的指针。这些指针中的地址是特定于创建它们的进程的，这意味着访问共享内存中的对象的多进程系统无法使用另一个进程的对象进行调度！考虑到共享内存在高性能多进程系统中的重要性，这是一个不可接受的限制。
封装：类设计者控制客户端代码访问的成员，确保类语义和不变量得以维护。例如，如果你从std::string派生（我可能会因为敢于提出这个问题而得到一些评论；-P），那么你可以使用所有正常的插入/删除/追加操作，并确信 - 只要你不做任何对于std::string总是未定义行为的事情，比如将错误的位置值传递给函数 - std::string数据将是安全的。检查或维护您的代码的人不必检查您是否改变了这些操作的含义。对于一个类来说，封装确保了在不破坏客户端代码的情况下随后修改实现的自由。同样的声明的另一个角度是：客户端代码可以任意使用类，而不必关心实现细节。如果派生类中的任何函数都可以更改，那么整个封装机制就会被破坏。
std::string::operator[]()和at()更改为将负值（在类型强制转换后）视为从字符串末尾向后偏移的偏移量。但是，也许某些其他函数正在使用at()作为一种断言，即索引是有效的 - 知道它会抛出异常 - 然后尝试插入或删除...该代码可能从按照标准规定抛出变为具有未定义的（但可能致命的）行为。virtual，您正在记录它是预期的定制点，并且是客户端代码使用的API的一部分。
内联 - 代码侧和CPU使用：虚函数调度使编译器难以确定何时内联函数调用，因此可能会提供更糟糕的代码，从空间/膨胀和CPU使用方面来看。
调用期间的间接性：即使正在进行线外调用，虚拟调度也存在小的性能成本，当在性能关键系统中重复调用微不足道的简单函数时，这个成本可能是显著的。（您必须读取指向虚函数调度表的每个对象指针，然后读取虚函数调度表条目本身 - 这意味着VDT页面也在消耗缓存。）
内存使用：
看起来这个问题可能有一些答案：Virtual functions should not be used excessively - Why ?。在我看来，最引人注目的一点是它增加了继承中可以做什么的复杂性。
obj.foo() 的代码看起来有点像 if (obj.getClass() == Class.forName("BaseClass")) { /* 来自 BaseClass.foo() 的内联代码 */ } else { obj.foo(); };。当然，getClass 的调用被内联，只需从对象中获取指针，而 forName 的调用结果是一个类对象的指针，并且该值也被内联到代码中。 - Steve JessopFoo或99.9％的Bar，而（一些）JIT在运行时开始后继续进行优化，这就是它们优化程序的运行的原因。 在我的经验中，基于剖面的C ++编译器仅优化程序的某些标准开发运行。 - Steve Jessopswitch(foo)？该死，哪个CPU有for？大多数都使用比较和分支指令。 - MSalters