为什么将类定义为final会改善JVM性能?

Max*_*ler 42 java optimization performance jvm final

引自http://sites.google.com/site/gson/gson-design-document:

为什么Gson中的大多数课程都被标记为最终?

虽然Gson通过提供可插拔序列化器和反序列化器提供了相当可扩展的架构,但Gson类并未专门设计为可扩展.提供非最终类将允许用户合法地扩展Gson类,然后期望该行为在所有后续修订中工作.我们选择通过将类标记为final来限制这样的用例,并等到出现良好的用例以允许扩展性.标记类final也有一个很小的好处,即为Java编译器和虚拟机提供额外的优化机会.

为什么会这样?[如果我猜测:JVM知道类是最终的,它不维护方法覆盖表?还有其他原因吗?]

性能有什么好处?

这是适用于频率实例化的类(POJO?)还是适用于持有静态方法(实用类)的类?

定义为final的方法在理论上也可以提高性能吗?

有什么影响吗?

谢谢你,马克西姆.

Tof*_*eer 38

虚拟(重写)方法通常通过某种表(vtable)实现,该表最终是函数指针.每个方法调用都有必须通过该指针的开销.当类被标记为final时,所有方法都不能被覆盖,并且不再需要使用表 - 这样更快.

一些虚拟机(如HotSpot)可以更智能地执行操作,并且知道何时覆盖方法并在适当时生成更快的代码.

以下是HotSpot的一些更具体的信息.还有一些一般信息.

  • 你的链接坏了:-( (2认同)

and*_*soj 18

IBM developerWorks上发表的一篇旧的,显然不再但仍然很重要的文章,其中指出:

常见的看法是,声明类或方法最终使编译器更容易内联方法调用,但这种看法是不正确的(或者至少,被夸大了).

最终的类和方法在编程时会带来很大的不便 - 它们限制了重用现有代码和扩展现有类功能的选择.虽然有时候一个班级是有充分理由的,例如强制执行不变性,但使用final的好处应该超过不便之处.性能增强几乎总是破坏良好的面向对象设计原则的坏理由,并且当性能增强很小或不存在时,这确实是一个糟糕的权衡.

另请参阅另一个问题的相关答案.这里还讨论了.Net等效问题.所以讨论," 最后的方法是内联的吗?" 在题为" 明天哪些优化将毫无用处 "的问题上,这一问题出现在名单上.

这里有人试图描述静态和最终类对HotSpot内联的影响.

还要注意,final类和final方法的影响是纠缠在一起的.对于确定的方法,你可能会获得一些性能优势(同样,我没有一个很好的参考)final,因为它可以提示JIT做内联它不能做其他事情(或者不那么简单).标记类时final,您会获得相同的效果,这意味着所有方法也会突然最终.请注意,Sun/Oracle人员声称HotSpot通常可以使用或不使用final关键字.拥有课程本身是否还有其他影响final

作为参考,链接到最终方法最终类的JLS .

  • 在过去的日子里,这是真的.当我们将岩石撞在一起以获得零和零和零时. (3认同)