java - java 8 中的编译代码与 java 11 中的编译代码

标签 java java-8 compilation jvm java-11

我们目前有在 Java 8 中编译的代码,但我们正在 Java 11 VM 上运行它。
现在我们也在尝试将我们的代码移动到 Java 11 编译时。想知道 Java 8 中的编译代码与 Java 11 中的编译代码在性能方面是否有任何好处,因为两个编译器都会生成不同的类文件(字节码)?一个在效率方面与另一个有何不同?

最佳答案

javacnot an optimizing compiler ,所以一般来说,不要指望它从一个版本到另一个版本产生“更快”的字节码。优化是 JVM 的工作。
同时,Java Compiler 确实支持新的语言特性,并且可能支持新的 JVM 特性。其中一些确实具有性能影响。 JDK 9 - JDK 11 中最著名的例子如下。

  • JEP 280: Indify String Concatenation (JDK 9)。
    这个 JEP 改变了字符串连接表达式的编译方式。在 JDK 9 之前,字符串 +表达式被翻译成
    new StringBuilder().append()...append().toString();
    
    尽管 JIT 识别出这样的链并尝试在运行时优化它们,但这种优化是脆弱的,并不总是按预期工作。使用 invokedynamic 编译字符串连接使 JVM 可以更自由地生成更好的代码。您可以在 notes 中找到详细说明和基准测试。到这个 JEP。
  • JEP 181: Nest-Based Access Control (JDK 11)
    这个 JEP 解决了访问嵌套类的私有(private)成员的问题。在 JDK 11 之前,Java Compiler 为它们生成了合成桥接方法 ( example )。
    乍一看,这与性能无关。然而,在 marginal cases由于内联深度限制,额外的合成方法可能会破坏内联。
    基于嵌套的访问控制允许嵌套类在没有合成桥的情况下访问彼此的私有(private)成员,从而降低意外性能下降的风险。

  • 更新
    以前我包括 JDK-8175883: Bytecode Generation for Enhanced for Loop在这个列表中,但正如@Holger 在评论中注意到的那样,这种“优化”实际上并没有奏效。
    结论
    Java Compiler 中的更改主要与新语言/JVM 功能有关。字节码级优化不是目标。但是,其中一些更改也可能(间接)影响性能。无论如何,重新编译代码可能带来的性能优势通常很小,您甚至在实际应用程序中都不会注意到它们。

    关于java - java 8 中的编译代码与 java 11 中的编译代码,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/64232267/

    相关文章:

    java - 使用java在linux中列出子目录/文件

    java - 获取 double 组的最大 k 个元素

    java - 创建泛型数组的两种方法

    java - 在封闭范围内定义的局部变量 log 必须是最终的或有效最终的

    Java 8 Function类addThen默认方法

    c++ - 在 C++ 的编译期间成员函数是否可用?

    C++ - 如何使使用 MinGW 独立编译的程序?

    java - schtasks : ERROR: Incorrect Start Date

    ios - ReasonML 可以用来制作原生 iOS 应用程序吗?

    java - Jackson 将 Twitter 中的日期反序列化为 `ZonedDateTime`