通常不会。对于虚拟方法，HotSpot会跟踪该方法是否实际上已被覆盖，并能够执行优化，例如在假设方法未被覆盖的情况下进行内联-直到它加载了覆盖该方法的类为止。它可以撤消（或部分撤消）那些优化。

（当然，这是假设你使用的是HotSpot-但这是迄今为止最常见的JVM，所以…）

我认为你应该final基于清晰的设计和可读性而不是出于性能原因而使用。如果出于性能原因要进行任何更改，则应在使最清晰的代码变形之前执行适当的测量-这样，你可以确定所实现的任何额外性能是否值得较差的可读性/设计。（根据我的经验，这几乎是不值得的； YMMV。）

编辑：正如最后提到的领域，值得一提的是，就清晰的设计而言，它们通常还是个好主意。它们还改变了跨线程可见性的保证行为：构造函数完成后，保证任何最终字段都将立即在其他线程中可见。这可能是final我经验中最常见的用法，尽管作为乔什·布洛赫（Josh Bloch）的“继承设计或禁止继承设计”经验法则的支持者，我可能应该final更频繁地在类上使用它。