请不要再说 Java 中 final 方法比非 final 性能更好了

无继承

有 static 修饰

static final

0?wx_fmt=png

static 非 final

0?wx_fmt=png

结果

这里使用了 OpenJDK 的 JMH 基准测试工具来测试的,结果如下:

0?wx_fmt=png

0?wx_fmt=png

总结:你说final的性能比非final有没有提升呢?可以说有,但几乎可以忽略不计。如果单纯地追求性能,而将所有的方法修改为 final 的话,我认为这样子是不可取的。而且这性能的差别,远远也没有网上有些人说的提升 50% 这么恐怖(有可能他们使用的是10年前的JVM来测试的吧^_^,比如 《35+ 个 Java 代码性能优化总结》这篇文章。雷总:不服?咱们来跑个分!)

分析

字节码级别的差别

StringKit.java

它们在字节码上的差别:

0?wx_fmt=png

0?wx_fmt=png

可以看到除了方法名和方法修饰符不同之外,其他的没有什么区别了。

在调用者上面的字节码差别

0?wx_fmt=png

0?wx_fmt=png

可以看到,它们在调用者上面的字节码也没有什么区别,只是方法名不一样之外。

对于 JVM 来说,它是只认字节码的,既然字节码除了方法名和修饰符一样,其他都一样,那就可以大概推测它们的性能几乎可以忽略不计了。因为调用 static final 和 static 非 final 的JVM指令是一样。

无 static 修饰

方法体是一样的,只是将它们删除了 static 的修饰。

结果

0?wx_fmt=png

0?wx_fmt=png

0?wx_fmt=png

分析

字节码级别的差别

0?wx_fmt=png

0?wx_fmt=png

可以看到,字节码上除了名字和 final 修饰符差别外,其余的是一样的。

在调用者上面的字节码差别

0?wx_fmt=png

0?wx_fmt=png

可以看到,它们除了名字不同之外,其他的JVM指令都是一样的。

总结

对于是否有 final 修饰的方法,对性能的影响可以忽略不计。因为它们生成的字节码除了 flags 标志位是否有 final 修饰不同之外,其他所有的JVM指令,都是一样的(对于方法本身,以及调用者本身的字节码都一样)。对于JVM来说,它执行的就是字节码,如果字节码都一样的话,那对于JVM来说,它就是同一样东西的了。

有继承

无 final 修饰

0?wx_fmt=png

有 final 修饰

0?wx_fmt=png

测试代码

写一个类来继承上面的抽象类,以此来测试在继承中 final 有否对多态中的影响

0?wx_fmt=png

然后在基准测试中:

0?wx_fmt=png

测试结果

非 final 结果

0?wx_fmt=png

有 final 结果

0?wx_fmt=png

总对比

0?wx_fmt=png

它们字节码的区别

0?wx_fmt=png

0?wx_fmt=png

可以看到,除了它们的方法签名和方法名字不同之外其他的都是一样的,包括JVM调用指令也完全是一样的。

总结

可以看到它们几乎是一样的。

总结

基于上面的基准测试结论,我认为滥用或刻意为了所谓的提升性能,而去为每一个方法尽可能添加 final 的关键字是不可取的。使用 final ,更多的应该是根据Java对 final 的语义来定义,而不是只想着为了提升性能(而且这影响可以忽略不计)而刻意用 final.

使用 final 的情况:

final 变量: 表示只读(只初始化一次,但可多次读取)

关于这个 final 的性能问题,我也Google了下,发现 stackoverflow 上,也有类似的问题:stackoverflow(https://stackoverflow.com/questions/4279420/does-use-of-final-keyword-in-java-improve-the-performance)

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值