如何解决Java 8中的已编译代码与Java 11中的已编译代码
我们目前已经用Java 8编译了代码,但是我们正在Java 11 VM上运行它们。 现在,我们也尝试将代码移至Java 11编译时。想知道Java 8中的编译代码与Java 11中的编译代码在性能方面是否有好处,因为两个编译器都会产生不同的类文件(字节码)?在效率方面,一个与另一个有何不同?
解决方法
deserialize<MyClass<T>>(json,MyClass);
是not an optimizing compiler,因此一般来说,不要期望它会在发行版本之间产生“更快”的字节码。优化是JVM的工作。
与此同时,Java编译器 支持新的语言功能,而可能支持新的JVM功能。其中一些确实对性能有影响。以下是JDK 9-JDK 11中最著名的示例。
-
JEP 280: Indify String Concatenation(JDK 9)。
此JEP更改了字符串连接表达式的编译方式。在JDK 9之前,将字符串
javac
表达式转换为+
尽管JIT会识别此类链并尝试在运行时对其进行优化,但这种优化是脆弱的,并不总是能按预期工作。使用
new StringBuilder().append()...append().toString();
编译字符串连接使JVM具有更多自由来生成更好的代码。您可以在本JEP的notes中找到详细的解释和基准。 -
JEP 181: Nest-Based Access Control(JDK 11)
此JEP解决了访问嵌套类的私有成员的问题。在JDK 11之前,Java编译器为它们生成了合成桥方法(example)。
乍一看,这与性能无关。但是,在marginal cases中,由于内联深度限制,其他合成方法可能会破坏内联。
基于嵌套的访问控制使Nestmate类无需合成桥即可访问彼此的私有成员,从而降低了意外性能降低的风险。
更新
之前,我在此列表中加入了JDK-8175883: Bytecode Generation for Enhanced for Loop,但是正如@Holger在评论中注意到的那样,这种“优化”实际上没有用。
结论
Java编译器中的更改主要与新的语言/ JVM功能有关。字节码级别的优化不是目标。但是,其中一些更改也可能(间接)影响性能。无论如何,重新编译代码可能带来的性能收益通常很小,以至于您甚至在实际的应用程序中都不会注意到它们。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。