quarkus依赖注入之十:学习和改变bean懒加载规则

欢迎访问我的GitHub

这里分类和汇总了欣宸的全部原创(含配套源码):https://github.com/zq2599/blog_demos

本篇概览

  • 本篇是《quarkus依赖注入》系列的第十篇,来看一个容易被忽略的知识点:bean的懒加载,咱们先去了解quarkus框架下的懒加载规则,然后更重要的是掌握如何改变规则,以达到提前实例化的目标
  • 总的来说本篇由以下内容构成
  1. 关于懒加载
  2. 编码体验懒加载
  3. 改变懒加载规则的第一种手段
  4. 改变懒加载规则的第二种手段(居然和官方资料有出入)
  5. 小结

关于懒加载(Lazy Instantiation

  • CDI规范下的懒加载规则:
  1. 常规作用域的bean(例如ApplicationScoped、RequestScoped),在注入时,实例化的是其代理类,而真实类的实例化发生在bean方法被首次调用的时候
  2. 伪作用域的bean(Dependent和Singleton),在注入时就会实例化
  • quarkus也遵循此规则,接下来编码验证

编码验证懒加载

  • 为了验证bean的懒加载,接下来会写这样一些代码
  1. NormalApplicationScoped.java:作用域是ApplicationScoped的bean,其构造方法中打印日志,带有自己的类名
  2. NormalSingleton.java:作用域是Singleton的bean,其构造方法中打印日志,带有自己的类名
  3. ChangeLazyLogicTest.java:这是个单元测试类,里面注入了NormalApplicationScoped和NormalSingleton的bean,在其ping方法中依次调用上面两个bean的方法
  • 以上就是稍后要写的代码,咱们根据刚刚提到的懒加载规则预测一下要输出的内容和顺序:
  1. 首先,在ChangeLazyLogicTest的注入点,NormalSingleton会实例化,NormalApplicationScoped的代理类会实例化
  2. 然后,在ChangeLazyLogicTest#ping方法中,由于调用了NormalApplicationScoped的方法,会导致NormalApplicationScoped的实例化
  • 接下来开始写代码,第一个bean,NormalApplicationScoped.java
package com.bolingcavalry;

import com.bolingcavalry.service.impl.NormalApplicationScoped;
import com.bolingcavalry.service.impl.NormalSingleton;
import io.quarkus.logging.Log;
import io.quarkus.test.junit.QuarkusTest;
import org.junit.jupiter.api.Test;
import javax.inject.Inject;

@QuarkusTest
class ChangeLazyLogicTest {

    @Inject
    NormalSingleton normalSingleton;

    @Inject
    NormalApplicationScoped normalApplicationScoped;

    @Test
    void ping() {
        Log.info("start invoke normalSingleton.ping");
        normalSingleton.ping();
        Log.info("start invoke normalApplicationScoped.ping");
        normalApplicationScoped.ping();
    }
}
  • 第二个bean,NormalSingleton.java
package com.bolingcavalry.service.impl;

import io.quarkus.logging.Log;
import javax.inject.Singleton;

@Singleton
public class NormalSingleton {

    public NormalSingleton() {
        Log.info("Construction from " + this.getClass().getSimpleName());
    }

    public String ping() {
        return "ping from NormalSingleton";
    }
}
  • 然后是单元测试类ChangeLazyLogicTest,可见NormalApplicationScoped构造方法的日志应该在start invoke normalApplicationScoped.ping这一段之后
package com.bolingcavalry;

import com.bolingcavalry.service.impl.NormalApplicationScoped;
import com.bolingcavalry.service.impl.NormalSingleton;
import io.quarkus.logging.Log;
import io.quarkus.test.junit.QuarkusTest;
import org.junit.jupiter.api.Test;

import javax.inject.Inject;

@QuarkusTest
class ChangeLazyLogicTest {

    @Inject
    NormalSingleton normalSingleton;

    @Inject
    NormalApplicationScoped normalApplicationScoped;

    @Test
    void ping() {
        Log.info("start invoke normalSingleton.ping");
        normalSingleton.ping();
        Log.info("start invoke normalApplicationScoped.ping");
        normalApplicationScoped.ping();
    }
}
  • 编码完成,运行单元测试类,验证我们之前的预测,控制台输出结果如下图所示,符合预期

image-20220429184753022

  • 至此,懒加载基本规则咱们已经清楚了,聪明的您应该想到了此规则的弊端:如果在构造方法中有一些耗时操作,必须等到第一次调用bean的方法时才会执行,这可能不符合我们的预期,有时候我们希望应用初始化的时候把耗时的事情做完,这样执行bean方法的时候就没有影响了
  • 显然,quarkus也意识到了这个问题,于是,给出了两中改变懒加载规则的方法,使得bean的实例化可以更早完成,接下来咱们逐个尝试

改变懒加载规则的第一种手段

  • 让bean尽早实例化的第一种手段,是让bean消费StartupEvent事件,这是quarkus框架启动成功后发出的事件,从时间上来看,此事件的时间比注入bean的时间还要早,这样消费事件的bean就会实例化

  • 咱们给NormalApplicationScoped增加下图红框中的代码,让它消费StartupEvent事件

image-20220501093358565
  • 运行代码前,先预测一下修改后的结果
  1. 首先应该是NormalApplicationScoped的实例化
  2. NormalApplicationScoped实例收到StarttupEvent事件,打印日志
  3. 开始注入bean到ChangeLazyLogicTest,引发NormalApplicationScoped代理类和NormalSingleton的实例化
  4. 简单地说:原本最晚实例化的NormalApplicationScoped,由于消费StarttupEvent事件,现在变成了最早实例化的
  • 现在运行代码验证,如下图,符合预期
image-20220501094806401

改变懒加载规则的第二种手段(居然和官方资料有出入)

  • 第二种方法更简单了:用StartupEvent修饰类,下图是完整NormalApplicationScoped代码,可见改动仅有红框位置
image-20220501101416574
  • 在运行代码前,先预测一下运行结果,理论上应该和第一种手段的结果差不多:NormalApplicationScoped、NormalApplicationScoped代理、NormalSingleton,
  • 上述推测的依据来自Startup源码中的注释,如下图,官方表示StartupEvent和Startup效果一致
image-20220501102631368
  • 官方都这么说了,我岂敢不信,不过流程还是要完成的,把修改后的代码再运行一遍,截个图贴到文中,走走过场...

  • 然而,这次运行的结果,却让人精神一振,StartupEvent和Startup效果是不一样的!!!

  • 运行结果如下图,最先实例化的居然不是被Startup注解修饰的NormalApplicationScoped,而是它的代理类!

image-20220501102150488
  • 由此可见,Startup可以将bean的实例化提前,而且是连带bean的代理类的实例化也提前了
  • 回想一下,虽然结果与预期不符合,而预期来自官方注释,但这并不代表官方注释有错,人家只说了句functionally equivalent,从字面上看并不涉及代理类的实例化
  • 另外Startup也有自己的独特之处,一共有以下两点
  1. Startup注解的value属性值,是bean的优先级,这样,多个bean都使用Startup的时候,可以通过value值设置优先级,以此控制实例化顺序(实际上控制的是事件observer的创建顺序)
  2. 如果一个类只有Startup注解修饰,而没有设置作用域的时候,quarkus自动将其作用域设置为ApplicationScoped,也就是说,下面这段代码中,ApplicationScoped注解写不写都一样
@ApplicationScoped
@Startup
public class NormalApplicationScoped {

小结

  • 懒加载、StartupEvent、Startup这三种情况下的实例化顺序各不相同,最好是有个对比让大家一目了然,方便选择使用
  • 接下来就画个对比图,图中有懒加载、StartupEvent、Startup三个场景,每个场景都是三个阶段:quarkus框架初始化、注入bean、bean的方法被调用,每个阶段都有哪些对象被实例化就是它们最大的区别,如下所示
流程图 (3)
  • 至此,懒加载相关的知识点学习完毕,个人认为这是个很重要的技能,用好了它对业务有不小的助力,希望能给您一些参考吧

欢迎关注博客园:程序员欣宸

学习路上,你不孤单,欣宸原创一路相伴...

posted @ 2023-08-09 07:03  程序员欣宸  Views(299)  Comments(0Edit  收藏  举报