Java 17项目中使用Java 8编译的依赖库是否影响性能

先给直接结论：Java 8编译的字节码跑在Java 17 JVM上不会带来明显的稳态性能损耗，但是将内部依赖基于Java 17重新编译，确实能拿到部分可量化的实际收益，要不要做完全取决于你们的投入产出比考量。

为什么低版本编译的依赖不会造成明显性能损失 #

• JVM的核心性能优化集中在运行时，和编译时的javac版本关联极小。Java 17加载class文件后，热点代码会交给C2/JIT编译器动态编译为本地机器码，逃逸分析、锁消除、循环展开、向量化这些核心优化不会因为class文件版本是Java 8就跳过，只要字节码符合规范，所有运行时优化对高低版本编译的代码一视同仁。
• Java 17核心类库、GC、运行时的性能红利，和依赖的编译版本完全无关。比如紧凑字符串带来的内存占用下降、G1/ZGC的延迟优化、并发容器/基础类的性能改进，只要你用Java 17 JVM启动项目，不管依赖是Java 8还是17编译的，都能直接享受到这些升级收益。
• 版本兼容带来的开销可以忽略。仅在类加载、首次调用方法时会有极少量模块访问检查、旧API适配的逻辑，开销是纳秒级的，业务稳态运行时完全感知不到，常规压测都测不出差异。

基于Java 17重新编译依赖的实际收益 #

重编不是玄学，确实能拿到几个明确的好处：

• 能拿到高版本javac的编译期字节码优化。最典型的是Java 9之后替换了字符串拼接的字节码生成逻辑，不再是无脑new StringBuilder拼接，而是用invokedynamic在运行时匹配最优的拼接策略，大量字符串处理、序列化场景下能拿到明确的性能提升；另外lambda表达式生成、异常表优化这些改进，也只有重新编译才能生效。
• 可以使用Java 9-17新增的高性能API与语言特性。比如Record类比手写POJO占用内存更低、新的Stream实现、并发工具类、模式匹配等特性，不重新编译根本无法在代码中使用，这些特性本身是附带性能和内存收益的。
• 提前暴露兼容性问题。Java 17强模块封装默认禁止访问大部分sun.misc下的内部API，很多Java 8时代的工具类会在运行时抛IllegalAccessError，重编阶段就能提前发现这些问题，不用等到线上出故障。
• 降低后续维护成本。所有依赖对齐Java 17编译版本后，后续升级更高版本JDK时，不会因为遗留的低版本字节码触发奇怪的兼容问题，技术债早还成本更低。

不需要强制重编所有依赖的场景 #

如果你们的业务属于以下情况，完全可以直接用Java 8编译的依赖跑在Java 17上，没必要专门投入人力重编：

• 业务系统并发量不高，对性能没有极致要求，重编带来的几个点的性能提升，远不如优化慢SQL、加业务缓存带来的收益明显。
• 依赖是已经稳定迭代多年、没有调用废弃内部API、也没有高频热点逻辑的基础工具包，重编的投入远大于能拿到的收益。

我们团队迁移时做过对照压测：同一套业务代码，全量用Java 8编译的依赖跑Java 17，和全量重编到Java 17的版本对比，稳态QPS差异在2%以内，堆内存占用差异不到3%，完全在业务正常波动范围内。只有序列化、字符串处理占比极高的基础工具包，重编到17后拿到了5%-8%的性能提升。

内容的提问来源于stack exchange，提问作者Katy