不可不知的 JVM 预热

一、JVM 架构基础

JVM 进程启动时,ClassLoader 会将需要的所有类加载到内存,主要分为以下三步:

  • Bootstrap Class:核心类库,由” Bootstrap Class Loader“负责加载,例如基础的运行时类库 JRE\lib\rt.jar
  • Extension Class: _java.ext.dirs_路径下的类,由ExtClassLoader 负责加载。在实际开发中,如果需要添加额外的类库,通常放置于此位置。
  • Application Class: 实际应用包含的类,由AppClassLoader 负责加载。

二、JVM 预热是指什么?

类加载过程完毕后,所有需要的类会进入JVM cache (native code) ,这样就可以被快速的实时访问。当然,还有许多其它与JVM启动无关的类此时并未被加载。

当应用的第一个请求到来,会触发逻辑相关类的第一次加载,此过程会有一定的耗时,会影响第一次调用的实时响应。这主要是因为JVM的懒加载及JIT机制。因此对于低延迟应用,必须采用特定的策略来处理第一次的预加载逻辑,以保障第一次的请求的快速响应。此过程,我们称之为 JVM 的预热。

三、Tiered Compilation

JVM 即时编译机制会将使用频率较高的方法或者代码块儿编译优化放入本地缓存。以提高程序响应速度。基于此,我们可以通过在应用启动之初,强制加载我们预先认知的高频方法。相应设置参数包括如下:

-XX:+TieredCompilation:开启分层编译(1.7 Server 模式默认开启)

-XX:CompileThreshold:设置触发即时编译阈值

-XX:+PrintCompilation:打印被编译成本地代码的方法名称

通常虚拟机会通过解释器来收集反馈到编译器的方法调用信息。

附:解释器 & 编译器

解释器:快速启动,执行

编译器:将热点方法及代码块儿编译成本地代码,提高执行效率

即时编译器编译本地代码需要占用程序运行时间,同时,为了编译出高效的本地代码,解释器需要收集相应的性能监控信息(基于采样、计数器热点探测)供编译器使用,从而影响解释器的执行速度。

分层编译:平衡程序启动相应速度及运行效率

C0:解释执行,不进行编译器编译

C1:将字节码编译为本地代码,进行简单可靠的优化,必要时加入性能监控逻辑

C2:将字节码编译为本地代码,基于性能监控,启用一些优化程度更高,编译耗时更长的优化。

四、自定义实现

基于上一小节所述,我们可以额外实现特定逻辑来进行特定方法的多次调用(-XX:CompileThreshold),以触发JVM的编译。如下示例:

首先,我们定义一个包含基础方法的类:

public class Dummy {

    public void m() {

    }
}

其次,我们创建一个加载类,在其内部添加静态方法,循环100000次重复生成Dummy对象,并调用其方法:

public class ManualClassLoader {

    protected static void load() {
        for (int i = 0; i < 100000; i++) {
            Dummy dummy = new Dummy();
            dummy.m();
        }
    }
}

现在我们使用如下过程,测试性能:

public class MainApplication {

    static {
        long start = System.nanoTime();
        ManualClassLoader.load();
        long end = System.nanoTime();
        System.out.println("Warm Up time : " + (end - start));
    }

    public static void main(String[] args) {
        long start = System.nanoTime();
        ManualClassLoader.load();
        long end = System.nanoTime();
        System.out.println("Total time taken : " + (end - start));
    }

}

如下为测试结果:

预热之后

未预热

差别 (%)

1220056

8903640

730

1083797

13609530

1256

1026025

9283837

905

1024047

7234871

706

868782

9146180

1053

预热之后的性能明显好于未预热状态下的调用。

当然,这里只是一个简单的示例测试,具体到实际的应用中,还需要考虑特定的业务逻辑需求。

五、 工具

通常用于基准测试,基本使用如下:

依赖 pom.xml:

org.openjdk.jmh
    jmh-core
    1.19

    org.openjdk.jmh
    jmh-generator-annprocess
    1.19

maven 库连接:Central Maven Repository

定义预热处理方法,并添加@Benchmark注解:

@Benchmark
public void init() {

    //code todo

}

将需要预热的业务逻辑放置于预热处理方法内。

六、附加订阅

Original: https://www.cnblogs.com/niejunlei/p/14435438.html
Author: WindWant
Title: 不可不知的 JVM 预热

原创文章受到原创版权保护。转载请注明出处:https://www.johngo689.com/533749/

转载文章受原作者版权保护。转载请注明原作者出处!

(0)

大家都在看

亲爱的 Coder【最近整理,可免费获取】👉 最新必读书单  | 👏 面试题下载  | 🌎 免费的AI知识星球