杭州pc网站制作公司,网站制作 常州,深圳建网建网站,apmserv网站模板文章目录 GraalVM运行模式JIT模式AOT模式 GraalVM的问题和解决方案GraalVM企业级应用传统架构的问题Serverless架构函数计算Serverless应用场景Serverless应用 GraalVM内存参数 GraalVM运行模式
JIT模式 JIT#xff08; Just-In-Time #xff09;模式 #xff0c;即时编译模… 文章目录 GraalVM运行模式JIT模式AOT模式 GraalVM的问题和解决方案GraalVM企业级应用传统架构的问题Serverless架构函数计算Serverless应用场景Serverless应用 GraalVM内存参数 GraalVM运行模式
JIT模式 JIT Just-In-Time 模式 即时编译模式 JIT模式的处理方式满足两个特点 ✓ Write Once,Run Anywhere - 一次编写到处运行。 ✓ 预热之后通过内置的Graal即时编译器优化热点代码生成比Hotspot JIT更高性能的机器码。 GraalVM的JIT编译器在编译过程中使用了即时优化技术包括方法内联、循环优化、逃逸分析等。这些优化技术可以提高代码的执行效率并且针对不同的应用场景进行了优化例如对于大型企业应用、嵌入式系统或数据密集型应用等。
AOT模式
AOTAhead-Of-Time模式 提前编译模式在AOT模式下GraalVM将Java字节码编译成本地机器代码并生成一个可执行文件可以直接在目标平台上运行而无需Java虚拟机JVM。这使得Java应用程序可以像传统的本地应用程序一样启动和执行而无需依赖JVM。但是不具备跨平台特性不同平台使用需要单独编译。这种模式生成的文件称之为Native Image本地镜像。GraalVM的AOT模式为Java应用程序提供了更快的启动时间和更低的内存消耗同时仍然保持了良好的性能和跨平台的特性。这使得Java应用程序可以更好地适应云原生、嵌入式和边缘计算等场景的需求。
GraalVM的问题和解决方案
GraalVM的AOT模式虽然在启动速度、内存和CPU开销上非常有优势但是使用这种技术会带来几个问题
跨平台问题在不同平台下运行需要编译多次,编译平台的依赖库等环境要与运行平台保持一致。使用框架之后编译本地镜像的时间比较长同时也需要消耗大量的CPU和内存。AOT 编译器在编译时需要知道运行时所有可访问的所有类。但是Java中有一些技术在运行时创建类例如反射、动态代理等。这些技术在很多框架比如Spring中大量使用所以框架需要对AOT编译器进行适配解决类似的问题。 解决方案
使用公有云的Docker等容器化平台进行在线编译确保编译环境和运行环境是一致的同时解决编译资源问题。使用SpringBoot3等整合GraalVM AOT模式的框架版本
GraalVM企业级应用
传统架构的问题
传统的系统架构中服务器等基础设施的运维、安全、高可用等工作都需要企业自行完成存在两个主要问题
开销大包括人力的开销、机房建设的开销资源浪费面对一些突发的流量冲击比如秒杀必须提前规划好容量准备好大量的服务器这些服务器在其他时候会处于闲置的状态造成大量的浪费
Serverless架构
随着虚拟化技术、云原生技术的愈发成熟云服务商提供了一套称为Serverless无服务器化的架构。企业无需进行服务器的任何配置和部署完全由云服务商提供。比较典型的有亚马逊AWS、阿里云等。
函数计算
Serverless架构中第一种常见的服务是函数计算Function as a Service将一个应用拆分成多个函数每个函数会以事件驱动的方式触发。典型代表有AWS的Lambda、阿里云的FC。 Serverless应用场景
函数计算主要应用场景有如下几种
小程序、API服务中的接口此类接口的调用频率不高使用常规的服务器架构容易产生资源浪费使用Serverless可以实现按需付费降低成本同时支持自动伸缩能应对流量的突发情况。大规模任务的处理比如音视频文件转码、审核等可以利用事件机制当文件上传后自动触发对应的任务。函数计算的计费标准中包含CPU和内存使用量使用GraalVM AOT模式编译本地镜像可以节省成本。
Serverless应用
函数计算的服务资源比较受限比如AWS的Lambda服务一般无法支持超过15分钟的函数执行所以云服务商提供另外一套方案基于容器的Serverless应用无需手动配置K8s中的Pod、Service等内容只需选择镜像就可自动生成应用服务。同样Serverless应用的计费标准中包含CPU和内存使用量所以使用GraalVM AOT模式编译出来的本地镜像可以节省更多的成本。
GraalVM内存参数
由于GraalVM是一款独立的JDK大部分HotSpot中的虚拟机参数都不适用。 ⚫ 社区版只能使用串行垃圾回收器Serial GC使用串行垃圾回收器的默认最大 Java 堆大小会设置为物理内存大小的 80%调整方式为使用 -Xmx最大堆大小。如果希望在编译期就指定该大小可以在编译时添加参数-R:MaxHeapSize最大堆大小。 ⚫ G1垃圾回收器只能在企业版中使用开启方式为添加–gcG1参数有效降低垃圾回收的延迟。 ⚫ 另外提供一个Epsilon GC开启方式–gcepsilon 它不会产生任何的垃圾回收行为所以没有额外的内存、CPU开销。如果在公有云上运行的程序生命周期短暂不产生大量的对象可以使用该垃圾回收器以节省最大的资源。-XX:PrintGC -XX:VerboseGC 参数打印垃圾回收详细信息
