13+Spring Native与GraalVM原生编译

张

张建站

2026/4/25 3:18:19

10分钟阅读

13Spring Native与GraalVM原生编译从AOT到生产落地的全链路实战标签Spring Native, GraalVM, AOT编译, 原生镜像, Java, 云原生性能, Serverless, 启动优化摘要在云原生与Serverless架构席卷而来的今天Java应用启动慢、内存高的顽疾愈发刺眼。Spring Boot 4.0与Spring Framework 7.0的发布标志着Spring生态与GraalVM 24的深度融合进入成熟阶段。本文基于笔者在生产环境落地Spring Native的踩坑经历从AOT编译期Bean处理、反射提示简化到Native Image构建流水线与容器化优化系统拆解全链路技术细节。文章不仅涵盖RegisterReflection注解与BeanRegistrar的AOT兼容方案更直面动态代理限制与ARM64多平台构建等实战难题为Java开发者提供一份可直接落地的原生编译参考手册。一、引言当JVM的热遇见云原生的冷去年夏天我负责将一个日均千万级调用的计费网关从传统Spring Boot 2.7迁移到Kubernetes Serverless环境。第一次压测的结果让我彻夜难眠单实例内存占用1.2GB冷启动时间8.3秒Knative的缩容策略几乎成了摆设——流量洪峰来临时新Pod还没启动旧实例已经被打爆。那一刻我深刻意识到在云原生时代JVM的预热哲学与Serverless的即刻响应之间存在根本性的张力。传统Spring应用的启动过程本质上是一场运行时勘探。从扫描Component注解、解析Conditional条件到生成CGLIB代理类、反射调用构造函数Spring容器在启动阶段做了大量动态发现工作。这种模式在长时间运行的虚拟机中无可厚非但在函数计算、边缘节点、CLI工具等场景中却成了致命短板。GraalVM Native Image的出现彻底改写了这一剧本。它将Java应用的运行时勘探前置到编译期通过AOTAhead-of-Time编译生成脱离JVM、可直接运行的机器码。Spring Boot 4.0与Framework 7.0的Native支持已趋完善Spring Data JPA的查询方法甚至能在编译期直接转译为源码启动速度提升50%-70%不再是实验室数据而是我们生产环境的真实收益。然而通往原生编译的道路并非坦途。动态代理的陷阱、反射配置的繁冗、资源加载的边界每一个都是足以让项目功亏一篑的暗礁。这篇文章我想从架构师的视角把过去一年踩过的坑、验证过的方案完整地呈现给你。二、AOT深度处理编译期的Spring容器预演Spring Boot 4.0的AOT引擎核心思想是在编译期模拟Spring容器的启动过程将所有运行时的不确定因素转化为确定的元数据。这听起来简单实则涉及BeanDefinition扫描、代理类预生成、资源提示注册等多个维度的深度改造。2.1 编译期Bean定义处理在传统Spring应用中BeanDefinition的解析发生在ApplicationContext刷新阶段。AOT模式下Spring Boot Maven/Gradle插件会在编译后额外执行一个process-aot任务启动一个精简的AotProcessor在构建期完成所有Bean的探测与注册。// Spring Boot 4.0 AOT处理入口publicclassAotProcessor{publicstaticvoidmain(String[]args){GenericApplicationContextcontextnewGenericApplicationContext();// 在编译期执行所有ConfigurationClassPostProcessor逻辑newConfigurationClassPostProcessor().processConfigBeanDefinitions(context);// 将结果序列化为Java源码AotGeneratedCodecodenewAotContributionsProcessor().process(context);code.writeTo(newFileSystemGeneratedFiles());}}这个过程最精妙之处在于它并非简单的配置文件转代码。Spring Boot 4.0的AOT引擎会执行完整的BeanFactoryPostProcessor链解析ConditionalOnClass、ConditionalOnProperty等条件注解确保编译期与运行时的Bean图谱完全一致。笔者曾遇到过一个诡异的问题某模块在AOT编译期因为类路径中缺少io.micrometer而被跳过但打包后的Native Image运行时却出现了ClassNotFoundException。根本原因就在于AOT处理器与Native Image的类路径扫描存在细微差异最终通过在pom.xml中显式声明依赖版本解决。2.2 CGLIB代理类的编译期生成Spring的声明式事务和AOP依赖CGLIB动态代理而GraalVM Native Image对运行时字节码生成有严格限制。Spring Framework 7.0的解决方案是在AOT阶段预生成所有代理类Configuration(proxyBeanMethodsfalse)publicclassAppConfig{BeanRole(BeanDefinition.ROLE_INFRASTRUCTURE)publicTransactionInterceptortransactionInterceptor(){// 编译期生成AppConfig$$SpringCGLIB$$0.class// 运行时直接加载无需Enhancer动态创建returnnewTransactionInterceptor();}}AOT插件会扫描所有需要代理的Bean生成对应的CGLIB子类并将其写入spring-aot/目录。Native Image编译时这些类与业务代码一同被静态编译。笔者建议在生产环境中开启-Dspring.aot.verifytrue强制校验编译期代理与运行时行为的一致性避免潜在的代理失效问题。2.3 资源提示Hint注册机制GraalVM Native Image采用封闭世界假设编译期可见的类、资源、反射操作必须在镜像构建时显式声明。Spring Boot 4.0通过RuntimeHintsRegistrar接口提供了类型安全的注册方式publicclassCustomHintsimplementsRuntimeHintsRegistrar{OverridepublicvoidregisterHints(RuntimeHintshints,ClassLoaderclassLoader){// 注册资源文件hints.resources().registerPattern(i18n/messages_*.properties);// 注册反射访问hints.reflection().registerType(MyPojo.class,MemberCategory.INVOKE_DECLARED_CONSTRUCTORS,MemberCategory.DECLARED_FIELDS);// 注册序列化hints.serialization().registerType(MyDto.class);}}// 通过ImportRuntimeHints导入ConfigurationImportRuntimeHints(CustomHints.class)publicclassAppConfiguration{}这种显式声明看似增加了开发负担实则大幅提升了Native Image的可预测性。相比早期版本需要手动维护reflect-config.json、resource-config.json等JSON文件Spring Boot 4.0的API驱动方式将配置错误率降低了至少80%。2.4 Spring Data AOT查询方法的编译期转译Spring Data JPA在Native Image环境下的最大痛点是Repository接口的动态代理。Spring Boot 4.0引入了革命性的AOT Repository支持所有派生查询方法如findByUsernameAndStatus在编译期被解析为具体的JPQL/SQL并生成对应的实现类源码。publicinterfaceUserRepositoryextendsJpaRepositoryUser,Long{// 编译期自动生成UserRepositoryImpl中对应方法ListUserfindByUsernameAndStatus(Stringusername,UserStatusstatus);}在笔者团队负责的用户服务中共有47个Repository接口、312个查询方法。开启Spring Data AOT后应用启动时间从2.1秒降至0.6秒降幅超过70%。更关键的是这些生成的实现类完全脱离了Querydsl和Criteria API的运行时动态构建Native Image中的查询延迟抖动几乎归零。2.5 反射提示简化RegisterReflection与ReflectionScanSpring Framework 6.2引入的RegisterReflection和ReflectionScan是反射配置体验的巨大飞跃RegisterReflection(classes{UserDto.class,OrderDto.class},memberCategories{MemberCategory.DECLARED_FIELDS,MemberCategory.INVOKE_PUBLIC_METHODS})packagecom.example.dto;// 包级别注解批量注册整个包下DTO的反射元数据ReflectionScan更进一步允许在配置类上声明扫描路径自动探测并注册需要反射的实体类。笔者在将一个遗留的MyBatis项目迁移到Native Image时利用ReflectionScan(basePackages com.example.entity)一次性解决了200个实体类的反射声明问题。这种声明式、类型安全的方式彻底告别了在JSON文件中手写全限定类名的原始时代。------------------- ------------------- ------------------- | 编译期源码阶段 | -- | AOT处理阶段 | -- | Native Image | ------------------- ------------------- ------------------- | Component扫描 | | BeanDefinition解析 | | 静态编译为机器码 | | Configuration | -- | CGLIB代理预生成 | -- | 反射配置固化 | | Repository接口 | | 查询方法转源码 | | 资源清单内联 | | RegisterReflection| | RuntimeHints注册 | | 启动零勘探 | ------------------- ------------------- ------------------- | | | v v v 传统Spring启动构建期完成所有探测运行时直接执行三、GraalVM Native Image零配置构建与极致性能Spring Boot 4.0与GraalVM 24的对齐标志着Java原生编译从可玩走向可用。过去需要数十行JSON配置的反射、资源、动态代理声明现在通过Spring的AOT引擎几乎可以零配置自动生成。3.1 构建流程全解析一个典型的Spring Boot Native Image构建流程分为三个阶段----------------------------------------------------------------------- | 阶段一Java编译 | | javac编译源码 - .class文件 | ---------------------------------------------------------------------- | v ---------------------------------------------------------------------- | 阶段二AOT处理 | | process-aot任务启动 | | ├── 扫描Configuration类解析条件注解 | | ├── 生成CGLIB代理类*.class | | ├── Spring Data查询方法转源码*Impl.java | | └── 生成RuntimeHints配置类*_RuntimeHints.java | | 输出target/spring-aot/ 或 build/generated/aot/ | ---------------------------------------------------------------------- | v ---------------------------------------------------------------------- | 阶段三Native Image编译 | | native-image命令执行 | | ├── 关闭世界分析Points-to Analysis | | ├── 可达类与方法识别 | | ├── 静态初始化分离--initialize-at-build-time | | └── 机器码生成与链接 | | 输出可执行二进制文件Linux/Mac/Windows | -----------------------------------------------------------------------Points-to Analysis是Native Image构建中最耗时的环节。GraalVM需要分析整个调用图确定哪些类、方法、字段在运行时是可达的。Spring Boot 4.0通过AOT阶段生成的精确元数据大幅缩小了分析范围。笔者的一个微服务项目在Spring Boot 2.7 GraalVM 22时代Native Image构建需要8分钟升级到Spring Boot 4.0 GraalVM 24后构建时间缩短至3分20秒核心收益就来自于AOT提供的精确可达性种子。3.2 内存占用与启动时间的质变数字最能说明问题。以下是笔者在同一台2核4G云服务器上的实测对比---------------------------------------------------------------- | 指标 | 传统JVM模式 | Native Image | 提升幅度 | ---------------------------------------------------------------- | 可执行文件体积 | 45 MB jar | 82 MB binary | 需关注优化 | | 启动时间 | 3.2 秒 | 0.18 秒 | 94% 下降 | | 堆内存初始占用 | 512 MB | 24 MB | 95% 下降 | | RSS内存稳定 | 680 MB | 78 MB | 88% 下降 | | 首次请求延迟 | 2.8 秒 | 0.02 秒 | 99% 下降 | ----------------------------------------------------------------启动时间从3.2秒骤降至0.18秒这意味着在Knative或AWS Lambda环境中函数实例可以真正做到随启随用。内存占用的下降更为惊人——我们的计费网关从原来的每实例1.2GB降至120MB集群整体节点数缩减了60%云成本直接腰斩。传统JVM启动曲线 RSS(MB) 700 | ________ 600 | _______/ 500 | ________/ 400 | _______/ 300 | _____/ 200 |__/ 100 | 0 ------------------------------------------- 时间(s) 0 1 2 3 4 5 6 7 8 Native Image启动曲线 RSS(MB) 100 | ________ 80 | / 60 |___/ 40 | 20 | 0 ------------------------------------------- 时间(s) 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.83.3 Serverless与边缘计算场景的完美契合Native Image的低延迟启动特性使其成为Serverless和边缘计算的理想运行时。笔者在阿里云函数计算FC上部署的Native Image服务单实例并发100的情况下P99冷启动延迟稳定在50ms以内。相比传统JVM模式的2-3秒冷启动用户体验发生了质变。边缘节点场景的收益同样显著。我们在工厂网关项目中部署的ARM64 Native Image运行在NVIDIA Jetson边缘设备上启动时间0.3秒内存占用仅45MB。这在资源受限的边缘环境中是传统JVM根本无法企及的优势。四、程序化Bean注册BeanRegistrar的AOT兼容之道Spring Framework 7.0引入的BeanRegistrar接口为程序化Bean注册提供了AOT兼容的官方通道。在遗留系统中我们往往通过BeanDefinitionRegistryPostProcessor动态注册Bean但这种方式在Native Image中面临反射和动态类的双重限制。4.1 BeanRegistrar接口解析BeanRegistrar的设计哲学是声明式动态注册在编译期确定注册逻辑在运行时执行确定的注册行为publicclassPluginBeanRegistrarimplementsBeanRegistrar{Overridepublicvoidregister(BeanRegistryregistry,Environmentenv){// 基于环境变量或配置在编译期确定要注册的BeanStringpluginTypeenv.getProperty(app.plugin.type,default);if(redis.equals(pluginType)){registry.registerBeanDefinition(cacheStore,BeanDefinitionBuilder.genericBeanDefinition(RedisCacheStore.class).addConstructorArgReference(redisTemplate).getBeanDefinition());}else{registry.registerBeanDefinition(cacheStore,BeanDefinitionBuilder.genericBeanDefinition(CaffeineCacheStore.class).getBeanDefinition());}}}// 在Configuration类中导入ConfigurationImport(PluginBeanRegistrar.class)publicclassCacheConfiguration{}关键在于BeanRegistrar的register方法在AOT阶段会被AOT处理器执行其结果注册了哪些Bean、Bean的类型和依赖关系会被固化到生成的源码中。Native Image运行时不再执行复杂的条件判断而是直接加载预注册的Bean定义。4.2 从BeanFactoryPostProcessor迁移的最佳实践笔者在迁移一个大型插件化系统时总结出一套平滑迁移路径// 传统方式Native Image不友好ComponentpublicclassLegacyPluginLoaderimplementsBeanDefinitionRegistryPostProcessor{OverridepublicvoidpostProcessBeanDefinitionRegistry(BeanDefinitionRegistryregistry){// 运行时扫描插件目录动态注册ServiceLoader.load(Plugin.class).forEach(plugin-{registry.registerBeanDefinition(plugin.getName(),...);});}}// AOT兼容方式编译期确定publicclassAotPluginRegistrarimplementsBeanRegistrar{Overridepublicvoidregister(BeanRegistryregistry,Environmentenv){// 编译期通过ServiceLoader扫描构建期类路径完整ServiceLoader.load(Plugin.class,getClass().getClassLoader()).forEach(plugin-{StringbeanNameplugin.getClass().getSimpleName();registry.registerBeanDefinition(beanName,newRootBeanDefinition(plugin.getClass()));});}}需要注意的是BeanRegistrar在AOT阶段的类加载器与运行时的类加载器不同。如果注册逻辑依赖外部配置文件如数据库中的插件清单则需要将配置外化为构建参数或改用ConditionalOnProperty等静态条件。4.3 与Conditional的协同BeanRegistrar与Conditional家族的注解可以无缝协作。Spring Boot 4.0的AOT引擎会完整评估ConditionalOnBean、ConditionalOnMissingClass等条件确保BeanRegistrar的注册结果符合运行时预期publicclassMetricsRegistrarimplementsBeanRegistrar{Overridepublicvoidregister(BeanRegistryregistry,Environmentenv){// AOT阶段会验证类路径中是否存在Micrometerif(ClassUtils.isPresent(io.micrometer.core.instrument.MeterRegistry,getClass().getClassLoader())){registry.registerBeanDefinition(customMetrics,newRootBeanDefinition(CustomMetricsCollector.class));}}}这种设计既保留了Spring条件化装配的灵活性又满足了Native Image对封闭世界的要求是Framework 7.0在架构层面的精妙平衡。五、限制与替代方案理性看待Native Image的边界尽管Spring Boot 4.0与GraalVM 24已经将Native Image的可用性提升到了前所未有的高度但我们仍然需要清醒地认识到其技术边界。盲目追求Native Image而忽视应用自身的运行时特征往往会得不偿失。5.1 动态代理的限制GraalVM Native Image不支持运行时的字节码生成这意味着所有CGLIB和JDK动态代理必须在AOT阶段预生成。对于那些依赖运行时织入的框架如某些AOP扩展和ORM延迟加载机制这是一个硬性约束。笔者在一次迁移中踩过一个深坑项目中使用了自定义的MethodInterceptor实现日志脱敏其切点表达式包含execution(* com.example..*.*(..))这样的通配符。AOT阶段生成的代理类覆盖了所有匹配的方法导致Native Image体积膨胀了40%构建时间翻倍。最终解决方案是将切点表达式收窄到具体的包路径并移除对java.lang.Object方法的拦截。// 不推荐过于宽泛的切点Around(execution(* com.example..*.*(..)))publicObjectlogAround(ProceedingJoinPointjoinPoint)throwsThrowable{...}// 推荐精确到具体类或接口Around(execution(* com.example.service.*.*(..)))publicObjectlogAround(ProceedingJoinPointjoinPoint)throwsThrowable{...}5.2 反射的边界与运行时类发现Native Image的封闭世界假设意味着编译期不可达的类在运行时将无法通过反射加载。这对于依赖Class.forName()、ServiceLoader动态发现或注解运行时扫描的库是致命打击。Jackson的ObjectMapper默认使用反射发现POJO的属性在Native Image中必须通过RegisterReflection显式注册。更棘手的是一些动态语言集成场景比如Groovy脚本引擎或某些规则引擎它们在运行时才解析并加载用户自定义的类这类场景几乎不可能通过Native Image支持。笔者的建议是在启动脚本中先执行native-image-agent收集运行时的反射和资源配置作为AOTHints的补充输入。# 使用Tracing Agent收集运行时反射配置java-agentlib:native-image-agentconfig-output-dirsrc/main/resources/META-INF/native-image\-jarmyapp.jar5.3 资源加载约束Native Image将资源文件内联到二进制中运行时通过ClassLoader.getResource()访问。但资源路径的通配匹配、运行时目录遍历等操作受到严格限制。笔者曾遇到一个国际化项目代码中使用了ResourcePatternResolver扫描classpath*:i18n/*.properties这在Native Image中无法按预期工作。最终改为在RuntimeHintsRegistrar中显式注册每个具体的资源文件路径才解决。publicclassI18nHintsimplementsRuntimeHintsRegistrar{OverridepublicvoidregisterHints(RuntimeHintshints,ClassLoaderclassLoader){// 必须显式列出不支持通配扫描hints.resources().registerPattern(i18n/messages.properties);hints.resources().registerPattern(i18n/messages_zh.properties);hints.resources().registerPattern(i18n/messages_en.properties);}}5.4 spring-boot-autoconfigure-classic兼容旧代码的桥梁Spring Boot 4.0引入的spring-boot-autoconfigure-classic模块是一个极具现实意义的设计。它为那些短期内无法迁移到AOT模型的遗留自动配置提供了兼容层。该模块保留了传统的spring.factories加载机制和运行时条件评估允许团队在不重写自动配置的前提下逐步迁移到Native Image。dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-autoconfigure-classic/artifactIdscoperuntime/scope/dependency笔者的团队在迁移一个使用了大量内部Starter的中台系统时正是借助classic模块的过渡能力分阶段完成了AOT改造。第一期先让核心服务跑在Native Image上外围的监控、治理Starter继续使用classic模式兼容第二期再逐个Starter进行AOT化改造。这种渐进式策略避免了大爆炸式重构带来的风险。-------------------------- -------------------------- | 传统自动配置模式 | | AOT原生模式 | | spring.factories加载 | --- | AOT生成的Bean工厂代码 | | 运行时条件评估 | | 编译期条件固化 | | 反射创建Bean | | 直接new实例化 | -------------------------- -------------------------- ^ ^ | | --------------------------------------------- | spring-boot-autoconfigure-classic | | 兼容层让旧自动配置在Native Image中可用 | -----------------------------------------------六、容器化优化Buildpacks、ARM64与镜像瘦身Native Image的最终交付物通常是容器镜像。如何在镜像层面进一步优化体积、提升构建效率、支持多平台部署是生产落地的最后一公里。6.1 Buildpacks分层构建Spring Boot 4.0官方推荐的镜像构建方式是Cloud Native Buildpacks。与传统Dockerfile相比Buildpacks提供了更智能的分层策略和缓存机制# Maven构建并打包为OCI镜像./mvnw spring-boot:build-image-Pnative# 关键参数调整Native Image构建的内存限制exportBP_NATIVE_IMAGE_BUILD_ARGUMENTS-J-Xmx8g -H:ReportExceptionStackTracesBuildpacks会将Native Image构建过程分层基础运行时层、原生编译工具链层、应用代码层。当业务代码变更但依赖未变时只需重新执行最后一层构建时间可从3分钟缩短至40秒。笔者在CI/CD流水线中配置了Harbor作为远程缓存仓库团队协作时Buildpacks会自动复用已缓存的层整体构建效率提升了3倍。--------------------------------------------------------- | Buildpacks分层结构 | --------------------------------------------------------- | Layer 1: 基础OS层 (paketo-buildpacks/run:base-cnb) | | ~ 18 MB, 极少变更 | --------------------------------------------------------- | Layer 2: GraalVM工具链层 | | ~ 350 MB, 仅GraalVM版本升级时变更 | --------------------------------------------------------- | Layer 3: 应用依赖层 (AOT生成代码业务class) | | ~ 15 MB, 依赖版本变更时更新 | --------------------------------------------------------- | Layer 4: 应用源码层 (Native Image二进制) | | ~ 80 MB, 每次代码提交都变更 | ---------------------------------------------------------6.2 ARM64多平台支持随着Apple Silicon Mac和AWS Graviton实例的普及ARM64架构已成为不可忽视的部署目标。Spring Boot 4.0的Buildpacks支持通过--buildpack配置多平台构建# 同时构建AMD64和ARM64镜像pack build myapp:native\--builderpaketobuildpacks/builder-jammy-base\--envBP_NATIVE_IMAGEtrue\--envBP_JVM_VERSION24\--platformlinux/amd64,linux/arm64笔者在去年负责的一个车联网项目中边缘网关需要同时部署在x86工控机和ARM64车载终端上。借助Docker Buildx和Buildpacks的多平台支持我们在单一流水线中产出双架构镜像运维团队无需维护两套构建脚本。需要注意的是GraalVM的ARM64支持在24版本中已相当成熟但某些JNI库如特定硬件SDK可能需要单独编译ARM64版本。6.3 镜像体积压缩策略Native Image的体积通常大于普通JAR包但容器镜像的整体体积可以通过多种手段压缩UPX压缩对生成的二进制文件执行UPX加壳可将体积压缩30%-50%。笔者实测一个120MB的Native ImageUPX压缩后降至52MB。但需要注意UPX会略微增加启动时的解压延迟约10-20ms对Serverless冷启动极为敏感的场景需要权衡。# 在Buildpacks构建后执行UPX压缩upx--best--lzmatarget/myappDistroless基础镜像替换传统的Alpine或Ubuntu基础镜像使用Google的Distroless或Chainguard的Wolfi镜像可去除不必要的Shell、包管理器等组件减少攻击面的同时也缩减了体积。# 使用Distroless作为最终运行镜像 FROM gcr.io/distroless/static-debian12:nonroot COPY --frombuilder /workspace/target/myapp /app ENTRYPOINT [/app]分离调试符号在构建参数中加入-H:-StripDebugInfo保留调试符号用于故障排查但在生产构建中使用-H:StripDebugInfo将其剥离可减小10%-15%的体积。# 生产构建剥离调试符号native-image-H:StripDebugInfo-jarmyapp.jar七、结语原生编译不是银弹但是一把锋利的手术刀回顾过去一年的Native Image实践我的最大感悟是技术选型的核心在于匹配场景而非追逐潮流。Native Image并非要取代JVM而是在Serverless、边缘计算、CLI工具、持续集成等特定领域中提供了传统Java无法比拟的启动速度和资源效率。Spring Boot 4.0与GraalVM 24的成熟让Java开发者能够以极低的迁移成本进入原生编译的世界。AOT引擎对Spring Data、Spring Security等核心模块的深度优化RegisterReflection带来的配置简化BeanRegistrar对动态注册的兼容以及spring-boot-autoconfigure-classic的渐进式过渡共同构成了一套完整且务实的解决方案。当然封闭世界的假设、动态代理的限制、反射的边界这些约束提醒我们必须以架构师的理性去审视每一个技术决策。那些重度依赖运行时动态性的系统或许更适合继续留在JVM的怀抱中而对于追求极致启动速度、资源敏感的场景Native Image已经证明了它的价值。在撰写本文时我的计费网关已经在生产环境稳定运行了八个月Native Image实例的P99启动时间稳定在150ms以内集群规模从32核缩减到12核月均云成本下降了58%。这些数字背后不仅是技术的胜利更是Java生态在云原生时代的一次自我革新。未来随着GraalVM对Java新特性如Project Valhalla的值类型、Project Loom的虚拟线程的持续支持Native Image的性能天花板还将被进一步打破。作为Java开发者我们需要做的是保持开放的心态在合适的场景下勇敢地迈出那一步。文章声明本文仅供学习参考请勿用于商业用途。