• 运行代码前，先预测一下修改后的结果

1. 首先应该是NormalApplicationScoped的实例化
2. NormalApplicationScoped实例收到StarttupEvent事件，打印日志
3. 开始注入bean到ChangeLazyLogicTest，引发NormalApplicationScoped代理类和NormalSingleton的实例化
4. 简单地说：原本最晚实例化的NormalApplicationScoped，由于消费StarttupEvent事件，现在变成了最早实例化的

• 现在运行代码验证，如下图，符合预期

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

• 第二种方法更简单了：用StartupEvent修饰类，下图是完整NormalApplicationScoped代码，可见改动仅有红框位置

• 在运行代码前，先预测一下运行结果，理论上应该和第一种手段的结果差不多：NormalApplicationScoped、NormalApplicationScoped代理、NormalSingleton，
• 上述推测的依据来自Startup源码中的注释，如下图，官方表示StartupEvent和Startup效果一致

• 官方都这么说了，我岂敢不信，不过流程还是要完成的，把修改后的代码再运行一遍，截个图贴到文中，走走过场...

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

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

• 由此可见，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的方法被调用，每个阶段都有哪些对象被实例化就是它们最大的区别，如下所示

• 至此，懒加载相关的知识点学习完毕，个人认为这是个很重要的技能，用好了它对业务有不小的助力，希望能给您一些参考吧

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

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