quarkus核心编程笔记

此篇只做总结，有大佬做的更详细

大佬quarkus笔记

在应用中，一个接口有多个实现是很常见的，那么依赖注入时，如果类型是接口，如何准确选择实现呢？

1. 修饰符匹配
2. Named注解属性匹配
3. 根据优先级选择
4. 写代码选择

• 先看一个注解Default，这个注解被@Qualifier修饰，这种被@Qualifier修饰的注解，称之为Qualifier修饰符
• 如果我们新建一个注解，也用Qualifier修饰，这个MyQualifier也是Qualifier的修饰符

• 在quarkus容器中的每一个bean都应该有一个Qualifier修饰符在修饰，如果没有，就会被quarkus添加Default注解

• 依赖注入时，直接用Qualifier修饰符修饰注入对象，这样quarkus就会去寻找被这个Qualifier修饰符修饰的bean，找到就注入（找不到就报错，找到多个业报错）

​ 修饰符匹配要注意的地方

​ 修饰符匹配的逻辑非常简单：bean定义和bean注入的地方用一个修饰符即可，使用中有三个笛梵要注意

1. 在注入bean的地方，如果有了Qualifier修饰符，可以把@Infect省略不写
2. 在定义bean的地方，如果没有了Qualifier修饰符去修饰bean，quarkus会默认添加Default

• Named注解的功能和前面的Qualifier修饰符是一样的，其特殊之处在于通过注解属性来匹配修饰符bean和注入的bean

• 使用优先级选择注入是一种简洁的方式，其核心使用Alternative和Priority两个注解修饰备选bean，然后用Priority的属性值（int型）作为优先级，该值越大优先级越高
• 在注入位置(@Inject)，quarkus会选择优先级最高的bean注入

• 如果不用修饰符匹配，再回到最初的问题：有三个bean都实现了同一个接口，应该如何注入？

1. 定义和使用拦截器的操作步骤介绍
2. 拦截异常
3. 拦截构造方法
4. 获取被拦截方法的参数
5. 多个拦截器之间传递参数

• 定义和使用拦截器一共需要做三件事

  1. 定义：新增一个注解（假设为A），要用@InterceptorBinding修饰该注解

  2. 实现：拦截器A到底要做什么事情，需要在一个类中实现，该类需要两个注解来修饰：A和Interceptor

  3. 使用：用A来修饰要拦截器的Bean

• 多个拦截器拦截同一个方法是很正常的，他们各司其职，根据优先级按顺序执行，如果这些拦截器之间有一定逻辑关系，例如第二个拦截器需要第一个拦截器的执行结果，此时又该如何呢？

• 同步事件是指事件发布后，事件接受者会在同一个线程处理事件，对事件发布者来说，相当于发布之后的代码不会立即执行，要等到事件处理的代码执行完毕后

• 发送事件的代码还是写在MyPorducer.java，如下，有两处要注意的地方稍后提到

发送异步事件的API是fireAsync

fireAsync的返回值是CompletionStage，我们可以调用其handleAsync方法，将响应逻辑（对事件消费结果的处理）传入，这段响应逻辑会在事件消费结束后被执行，上述代码中的响应逻辑是检查异常，若有就打印

• 消费异步事件的代码写在MyConsumer，与同步的相比唯一的变化就是修饰入参的注解改成了ObservesAsync

• 单元测试代码，有两点需要注意，稍后会提到

• 上述代码有以下两点需要注意

1. 异步事件的时候，发送事件的线程不会等待，所以myEvent实例的计数器在消费线程还没来得及加一，myProducer.asyncProduce方法就已经执行结束了，返回值是0，所以单元测试的assertEquals位置，期望值应该是0
2. testAsync方法要等待100毫秒以上才能结束，否则进程会立即结束，导致正在消费事件的子线程被打断，抛出异常

• 设想这样一个场景：管理员发送XXX类型的事件，消费者应该是处理管理员事件的方法，普通用户也发送XXX类型的事件，消费者应该是处理普通用户事件的方法，简单的说就是同一个数据结构的事件可能用在不同场景，如下图

从技术上分析，实现上述功能的关键点是：消息的消费者要精确过滤掉不该自己消费的消息

此刻，您是否回忆起前面文章中的一个场景：依赖注入时，如何从多个bean中选择自己所需的那个，这两个问题何其相似，而依赖注入的选择问题是用Qualifier注解解决的，今天的消息场景，依旧可以用Qualifier来对消息做精确过滤，接下来编码实战

首先定义事件类ChannelEvent.java，管理员和普通用户的消息数据都用这个类（和前面的MyEvent事件类的代码一样）

• 然后就是关键点：自定义注解Admin，这是管理员事件的过滤器，要用Qualifier修饰

• 自定义注解Normal，这是普通用户事件的过滤器，要用Qualifier修饰

• Admin和Normal先用在发送事件的代码中，再用在消费事件的代码中，这样就完成了匹配，先写发送代码，有几处要注意的地方稍后会提到

1. 注入了两个Event实例adminEvent和normalEvent，它们的类型一模一样，但是分别用Admin和Normal

注解修饰，相当于为它们添加了不同的标签，在消费的时候也可以用这两个注解来过滤

1. 发送代码并无特别之处，用adminEvent.fire发出的事件，在消费的时候不过滤、或者用Admin过滤，这两种方式都能收到

• 接下来看消费事件的代码TwoChannelConsumer.java，有几处要注意的地方稍后会提到

• 刚才的代码虽然可以正常工作，但是有一点小瑕疵：为了发送不同事件，需要注入不同的Event实例，如下图红框，如果事件类型越来越多，注入的Event实例岂不是越来越多？

• quarkus提供了一种缓解上述问题的方式，再写一个发送事件的类TwoChannelWithSingleEvent.java，代码中有两处要注意的地方稍后会提到

• 上述发送消息的代码，有以下两处需要注意

1. 不论是Admin事件还是Normal事件，都是用singleEvent发送的，如此避免了事件类型越多Event实例越多的情况发生
2. 执行fire方法发送事件前，先执行select方法，入参是AnnotationLiteral的匿名子类，并且通过泛型指定事件类型，这和前面TwoChannelWithTwoEvent类发送两种类型消息的效果是一样的

• 既然用select方法过滤和前面两个Event实例的效果一样，那么消费事件的类就不改动了

在消费事件时，除了从事件对象中取得业务数据（例如MyEvent的source和consumeNum字段），有时还可能需要用到事件本身的信息，例如类型是Admin还是Normal、Event对象的注入点在哪里等，这些都算是事件的元数据

为了演示消费者如何取得事件元数据，将TwoChannelConsumer.java的allEvent方法改成下面的样子，需要注意的地方稍后会提到

上述代码中，以下几处需要注意

• 给allEvent方法增加一个入参，类型是EventMetadata，bean容器会将事件的元数据设置到此参数
• EventMetadata的getType方法能取得事件类型
• EventMetadata的getType方法能取得事件的所有修饰注解，包括Admin或者Normal

• 本篇的知识点是bean的生命周期回调：在bean生命周期的不同阶段，都可以触发自定义代码的执行

• 有两种模式可以实现生命周期回调：拦截器模式和自定义模式，接下来通过编码依次学习

• 《拦截器(Interceptor)》已详细介绍了quarkus拦截器的自定义和使用，包括以下三个步骤

• 如果要自定义bean的生命周期回调，也是遵照上述步骤执行，接下来编码实现
• 首先定义拦截器，名为TrackLifeCycle，就是个普通拦截器，需要用注解InterceptorBinding修饰

• 然后是实现拦截器的功能，有几处要注意的地方稍后会提到

  用注解Interceptor和TrackLifeCycle修饰，说明这是拦截器TrackLifeCycle的实现

  被拦截bean实例化的时候，AroundConstruct修饰的方法execute就会被执行，这和《拦截器》一文中的AroundInvoke的用法很相似

  被拦截bean创建成功后，PostConstruct修饰的方法doPostConstruct就会被执行

  被拦截bean在销毁之前，PreDestroy修饰的方法doPreDestroy就会被执行

• 接下来是使用拦截器TrackLifeCycle了，用于演示的bean如下，用TrackLifeCycle修饰，有构造方法和简单的helloWorld方法

• 最后再写个单元测试类验证

• 刚才的拦截器模式有个明显问题：如果不同bean的生命周期回调有不同业务需求，该如何是好？为每个bean做一个拦截器吗？随着bean的增加会有大量拦截器，似乎不是个好的方案

• 如果您熟悉spring，对下面的代码要改不陌生，这是来自spring官网的内容，直接在bean的方法上用PostConstruct和PreDestroy修饰，即可在bean的创建完成和销毁前被调用

• 实际上，quarkus也支持上述方式，不过和拦截器相比有两个差异：

1. 在bean的内部，只能用PostConstruct和PreDestroy，不能用AroundConstruct，只有拦截器才能用AroundConstruct
2. 在拦截器中，PostConstruct和PreDestroy 修饰的方法必须要有InvocationContext类型的入参，但是在bean内部则没有此要求

• 咱们来改造Hello.java的源码，修改后如下，增加了两个方法，分别被PostConstruct和PreDestroy修饰

• 试想这样的场景：我的bean在销毁前要做自定义操作，但是如果用之前的两种方案，可能面临以下问题：

1. 不适合修改bean的代码，bean的类可能是第三方库
2. 也不适合修改生命周期拦截器代码，拦截器可能也是第三方库，也可能是多个bean共用，若修改会影响其他bean

• 好在quarkus为我们提供了另一个方案，不用修改bean和拦截器的代码，用注解dispose修饰指定方法即可，接下来编码验证
• 增加一个普通类ResourceManager.java，假设这是业务中的资源管理服务，可以打开和关闭业务资源，稍后会在配置类中将其指定为bean

• 配置类SelectBeanConfiguration.java，指定了ResourceManager的生命周期是每次http请求

• 再写一个web服务类ResourceManagerController.java，这里面使用了ResourceManager

由于ResourceManager的生命周期是RequestScoped，因此每次请求/resourcemanager都会实例化一个ResourceManager，请求结束后再将其销毁

现在，业务需求是每个ResourceManager的bean在销毁前，都要求其closeAll方法被执行

重点来了，在SelectBeanConfiguration.java中新增一个方法，入参是bean，而且要用Disposes注解修饰，如此，ResourceManager类型的bean在销毁前此方法都会被执行

• 最后是单元测试类DisposeTest.java，这里用了注解RepeatedTest表示重复执行，属性值为3，表示重复执行3次

掌握quarkus实现的一个CDI特性：装饰器（Decorator）

• 实战功能说明

一杯意式浓缩咖啡(Espresso)价格3美元

拿铁(Latte)由意式浓缩+牛奶组成，价格是意式浓缩和牛奶之和，即5美元

焦糖玛奇朵(CaramelMacchiato)由拿铁+焦糖组成，价格比拿铁多了焦糖的1美元，即6美元

每种咖啡都是一种对象，价格由getPrice方法返回

• 编码实践

• 接下来是CaramelMacchiato类(焦糖玛奇朵)，有几处要注意的地方稍后会说明

看到这里，相信您也发现了问题所在：CaramelMacchiato和Latte都有成员变量delegate，其注解和类型声明都一模一样，那么，如何才能保证Latte的delegate注入的是Espresso，而CaramelMacchiato的delegate注入的是Latte呢？

此刻就是注解Priority在发挥作用了，CaramelMacchiato和Latte都有注解Priority修饰，属性值却不同，属性值越大越接近原始类Espresso，如下图，所以，Latte装饰的就是Espresso，CaramelMacchiato装饰的是Latte

猜猜这里注入的谁，很神奇，先放这吧，不明实际应用场景

1. 关于多线程同步问题
2. 代码复现多线程同步问题
3. quarkus的bean读写锁

直接结论

在deposit和deduct都没有被调用时，get方法可以被调用，而且可以多线程同时调用，因为每个线程都能顺利拿到读锁

一旦deposit或者deduct被调用，其他线程在调用deposit、deduct、get方法时都被阻塞了，因为此刻不论读锁还是写锁都拿不到，必须等deposit执行完毕，它们才重新去抢锁

有了上述逻辑，再也不会出现deposit和deduct同时修改余额的情况了，预测单元测试应该能通过

这种读写锁的方法虽然可以确保逻辑正确，但是代价不小（一个线程执行，其他线程等待），所以在并发性能要求较高的场景下要慎用，可以考虑乐观锁、AtomicInteger这些方式来降低等待代价

• CDI规范下的懒加载规则：

1. 常规作用域的bean（例如ApplicationScoped、RequestScoped），在注入时，实例化的是其代理类，而真实类的实例化发生在bean方法被首次调用的时候
2. 伪作用域的bean（Dependent和Singleton），在注入时就会实例化

• quarkus也遵循此规则，接下来编码验证

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

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

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

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

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

• 由此可见，Startup可以将bean的实例化提前，而且是连带bean的代理类的实例化也提前了
• 回想一下，虽然结果与预期不符合，而预期来自官方注释，但这并不代表官方注释有错，人家只说了句functionally equivalent，从字面上看并不涉及代理类的实例化
• 另外Startup也有自己的独特之处，一共有以下两点

1. Startup注解的value属性值，是bean的优先级，这样，多个bean都使用Startup的时候，可以通过value值设置优先级，以此控制实例化顺序（实际上控制的是事件observer的创建顺序）

2. 如果一个类只有Startup注解修饰，而没有设置作用域的时候，quarkus自动将其作用域设置为ApplicationScoped，也就是说，下面这段代码中，ApplicationScoped注解写不写都一样

先定义三个bean

需求：

要求设计一个拦截器，名为SendMessage，功能是对外发送通知，通知的方式有短信和邮件两种，具体用哪种是可以设置的

用SendMessage拦截器拦截SayHelloA，通知类型是短信

用SendMessage拦截器拦截SayHelloB，通知类型是邮件

用SendMessage拦截器拦截SayHelloC，通知类型是短信和邮件都发送

定义拦截器

1. 允许在同一位置重复使用同一个注解，这是java注解的通用功能，并非quarkus独有
2. 重复使用注解时，必须定义注解容器，用来放置重复的注解，这里的容器是SendMessageList
3. 使用Repeatable修饰SendMessage，这样就能在同一位置重复使用SendMessage注解了，注意Repeatable的属性值是容器SendMessageList
4. sendType是注解属性，用来保存通知类型，任何使用SendMessage注解的地方都能通过设置sendType来指定通知类型，如果不指定则使用默认值sms
5. 要注意sendType的注解Nonbinding，此注解非常重要，如果不添加此注解，在使用SendMessage的时候，设置sendType为email时拦截器不会生效

quarkus对重复使用同一拦截器注解的限制

• 虽然可以在同一位置重复使用SendMessage拦截器，但是要注意quarkus的限制

1. 可以作用在方法上
2. 不能作用在类上
3. 不能作用在stereotypes上

• 关于2和3，官方的说法是将来会解决（This might be added in the future）

• 接下来进行编码，看看作用在类上和方法上的两个拦截器的叠加效果，要新建的文件清单如下

1. TrackClass.java：定义类级别的拦截器
2. TrackClassInterceptor.java：拦截器TrackClass的功能实现
3. TrackMethod.java：方法级别的拦截器
4. TrackMethodInterceptor.java：拦截器TrackMethod的功能实现
5. ExcludeInterceptorDemo.java：普通的bean，用TrackClass修饰其类，用TrackMethod修饰其test1方法
6. ExcludeInterceptorTest.java：单元测试类，运行ExcludeInterceptorDemo的方法，观察拦截效果

• 这两种拦截器，在定义上没有任何区别，不过就是该注解可以加在类上(该类的所有方法都将会被拦截)，也可以加在方法上（只拦截该方法）

测试

假设遇到了某些冲突（例如和数据库、IO相关等），导致TrackClassInterceptor和TrackMethodInterceptor两个拦截器不能同时对test1方法进行拦截，只能保留TrackMethodInterceptor

此时，可以用注解NoClassInterceptors修饰test1方法，如下图红框所示，这样类拦截器TrackClassInterceptor就会失效，只剩下TrackMethodInterceptor可以正常工作

NoClassInterceptors的影响范围

• 回顾类拦截器TrackClassInterceptor，如下图红框，可见其拦截方法有注解AroundInvoke修饰

而NoClassInterceptors的作用，就是针对有注解AroundInvoke修饰的方法，使他们失效

除了AroundInvoke，NoClassInterceptors还针对AroundConstruct修饰的方法，使他们失效

至此，拦截器的高级特性已经全部学习和实践完成，希望能给您提供一些参考，助您设计出更完善的拦截器

1. 几处可以简化编码的地方，如bean注入、构造方法等
2. WithCaching：特定场景下，减少bean实例化次数
3. 静态方法是否可以被拦截器拦截？
4. All注解，让多个bean的注入更加直观
5. 统一处理异步事件的异常

• quarkus在CDI规范的基础上做了简化，可以让我们少写几行代码
• 将配置文件中名为aaa.name的配置项注入到bean的成员变量greetingMsg中，按照CDI规范的写法如下

• 关于bean的构造方法，CDI有两个规定：首先，必须要有无参构造方法，其次，有参数的构造方法需要@Inject注解修饰，实例代码如下所示

• 但是，在quarkus框架下，无参构造方法可不写，有参数的构造方法也可以略去@Inject，写成下面这样的效果和上面的代码一模一样

• 在CDI规范中，通过方法生产bean的语法如下，可见要同时使用Produces和ApplicationScoped注解修饰返回bean的方法

• 在quarkus框架下可以略去@Produces，写成下面这样的效果和上面的代码一模一样

• 在介绍WithCaching注解之前，先来看一个普通场景
• 下面是一段单元测试代码，HelloDependent类型的bean通过Instance的方式被注入，再用Instance#get来获取此bean

• 如果HelloDependent的作用域是ApplicationScoped，上述代码一切正常，但是，如果作用域是Dependent呢？代码中执行了两次Instance#get，得到的HelloDependent实例是同一个吗？Dependent的特性是每次注入都实例化一次，这里的Instance#get又算几次注入呢？

• 最简单的方法就是运行上述代码看实际效果，这里先回顾HelloDependent.java的源码，如下所示，构造方法中会打印日志，这下好办了，只要看日志出现几次，就知道实例化几次了

• 现在问题来了：如果bean的作用域必须是Dependent，又希望多次Instance#get返回的是同一个bean实例，这样的要求可以做到吗？

• 答案是可以，用WithCaching注解修饰Instance即可，改动如下图红框1，改好后再次运行，红框2显示HelloDependent只实例化了一次

• 仅支持方法级别的拦截（即拦截器修饰的是方法）

• private型的静态方法不会被拦截

• 下图是拦截器实现的常见代码，通过入参InvocationContext的getTarget方法，可以得到被拦截的对象，然而，在拦截静态方法时，getTarget方法的返回值是null，这一点尤其要注意，例如下图红框中的代码，在拦截静态方法是就会抛出空指针异常

• 现在有三个bean都实现了SayHello接口，如果想要调用这三个bean的hello方法，应该怎么做呢？
• 按照CDI的规范，应该用Instance注入，然后使用Instance中的迭代器即可获取所有bean，代码如下

• quarkus提供了另一种方式，借助注解io.quarkus.arc.All，可以将所有SayHello类型的bean注入到List中，如下所示

• 和CDI规范相比，使用All注解可以让代码显得更为直观，另外还有以下三个特点

1. 此list是immutable的（内容不可变）
2. list中的bean是按照priority排序的
3. 如果您需要的不仅仅是注入bean，还需要bean的元数据信息（例如bean的scope），可以将List中的类型从SayHello改为InstanceHandle，这样即可以得到注入bean，也能得到注入bean的元数据(在InjectableBean中)，参考代码如下

• 需要提前说一下，本段落涉及的知识点和AsyncObserverExceptionHandler类有关，而《quarkus依赖注入》系列所用的quarkus-2.7.3.Final版本中并没有AsyncObserverExceptionHandler类，后来将quarkus版本更新为2.8.2.Final，就可以正常使用AsyncObserverExceptionHandler类了

• 本段落的知识点和异步事件有关：如果消费异步事件的过程中发生异常，而开发者有没有专门写代码处理异步消费结果，那么此异常就默默无闻的被忽略了，我们也可能因此错失了及时发现和处理问题的时机

来写一段代码复现上述问题，首先是事件定义TestEvent.java，就是个普通类，啥都没有

• 事件的消费者TestEventConsumer.java，这里在消费TestEvent事件的时候，故意抛出了异常

• 运行EventExceptionHandlerTest，结果如下图，DefaultAsyncObserverExceptionHandler处理了这个异常，这是quarkus框架的默认处理逻辑

• DefaultAsyncObserverExceptionHandler只是输出了日志，这样的处理对于真实业务是不够的（可能需要记录到特定地方，调用其他告警服务等），所以，我们需要自定义默认的异步事件异常处理器
• 自定义的全局异步事件异常处理器如下

• 此刻，咱们再执行一次单元测试，如下图所示，异常已经被NoopAsyncObserverExceptionHandler#handler处理，异常和事件相关的信息都能拿到，您可以按照实际的业务需求来进行定制了

• 另外还要说明一下，自定义的全局异步事件异常处理器，其作用域只能是ApplicationScoped或者Singleton

官方提醒

在使用依赖注入的时候，quankus官方建议不要使用私有变量(用默认可见性，即相同package内可见)，因为GraalVM将应用制作成二进制可执行文件时，编译器名为Substrate VM，操作私有变量需要用到反射，而GraalVM使用反射的限制，导致静态编译的文件体积增大

关于CDI

• 《 Contexts and Dependency Injection for Java 2.0》，简称CDI，该规范是对JSR-346的更新，quarkus对依赖注入的支持就是基于此规范实现的
• 从 2.0 版开始，CDI 面向 Java SE 和 Jakarta EE 平台，Java SE 中的 CDI 和 Jakarta EE 容器中的 CDI 共享core CDI 中定义的特性。
• 简单看下CDI规范的内容（请原谅欣宸的英语水平）：

1. 该规范定义了一组强大的补充服务，有助于改进应用程序代码的结构
2. 给有状态对象定义了生命周期，这些对象会绑定到上下文，上下文是可扩展的
3. 复杂的、安全的依赖注入机制，还有开发和部署阶段选择依赖的能力
4. 与Expression Language (EL)集成
5. 装饰注入对象的能力（个人想到了AOP，你拿到的对象其实是个代理）
6. 拦截器与对象关联的能力
7. 事件通知模型
8. web会话上下文
9. 一个SPI：允许便携式扩展与容器的集成（integrate cleanly ）

关于CDI的bean

• CDI的实现（如quarkus），允许对象做这些事情：

1. 绑定到生命周期上下文
2. 注入
3. 与拦截器和装饰器关联
4. 通过触发和观察事件，以松散耦合的方式交互

• 上述场景的对象统称为bean，上下文中的 bean 实例称为上下文实例，上下文实例可以通过依赖注入服务注入到其他对象中

• 这种注解修饰在类上的bean，被quarkus官方成为class-based beans
• 使用bean也很简单，如下，用注解Inject修饰ClassAnnotationBean类型的成员变量即可

• 这种用于创建bean的方法，被quarkus称为producer method

• 看过上述代码，相信聪明的您应该明白了用这种方式创建bean的优点：在创建HelloService接口的实例时，可以控制所有细节（构造方法的参数、或者从多个HelloService实现类中选择一个），没错，在SpringBoot的Configuration类中咱们也是这样做的

• 前面的getHelloService方法的返回值，可以直接在业务代码中依赖注入，如下所示

• producer method有个特性需要重点关注：如果刚才生产bean的getHelloService方法有个入参，如下所示，入参是OtherService对象，那么，这个OtherService对象也必须是个bean实例（这就像你用@Inject注入一个bean的时候，这个bean必须存在一样），如果OtherService不是个bean，那么应用初始化的时候会报错，（其实这个特性SpringBoot中也有，相信经验丰富的您在使用Configuration类的时候应该用到过）

• 种用于创建bean的成员变量（如上面的otherServiceImpl），被quarkus称为producer field
• 上述bean的使用方法如下，可见与前面的使用并无区别，都是从quarkus的依赖注入

还有一种bean，quarkus官方称之为synthetic bean（合成bean），这种bean只会在扩展组件中用到，而咱们日常的应用开发不会涉及，synthetic bean的特点是其属性值并不来自它的类、方法、成员变量的处理，而是由扩展组件指定的，在注册syntheitc bean到quarkus容器时，常用SyntheticBeanBuildItem类去做相关操作，来看一段实例化synthetic bean的代码

• 作为《quarkus依赖注入》系列的第二篇，继续学习一个重要的知识点：bean的作用域（scope），每个bean的作用域是唯一的，不同类型的作用域，决定了各个bean实例的生命周期，例如：何时何处创建，又何时何处销毁

• bean的作用域在代码中是什么样的？回顾前文的代码，如下，ApplicationScoped就是作用域，表明bean实例以单例模式一直存活（只要应用还存活着），这是业务开发中常用的作用域类型：

内置

常规作用域，quarkus官方称之为normal scope，包括：ApplicationScoped、RequestScoped、SessionScoped三种

伪作用域称之为pseudo scope，包括：Singleton、 Dependent两种

接下来，用一段最平常的代码来揭示常规作用域和伪作用域的区别

下面的代码中，ClassAnnotationBean的作用域ApplicationScoped就是normal scope，如果换成Singleton就是pseudo scope了

• 再来看使用ClassAnnotationBean的代码，如下所示，是个再平常不过的依赖注入

• 现在问题来了，ClassAnnotationBean是何时被实例化的？有以下两种可能：

常规作用域

第一种：ClassAnnotationController被实例化的时候，classAnnotationBean会被注入，这时ClassAnnotationBean被实例化

第二种：get方法第一次被调用的时候，classAnnotationBean真正发挥作用，这时ClassAnnotationBean被实例化

所以，一共有两个时间点：注入时和get方法首次执行时，作用域不同，这两个时间点做的事情也不同，下面用表格来解释

• 至此，您应该明白两种作用域的区别了：伪作用域的bean，在注入的时候实例化，常规作用域的bean，在注入的时候并未实例化，只有它的方法首次执行的时候才会实例化，如下图

RequestScoped

SessionScoped

1. • ApplicationScoped算是最常用的作用域了，它修饰的bean，在整个应用中只有一个实例
2. • 这是与当前http请求绑定的作用域，它修饰的bean，在每次http请求时都有一个全新实例，来写一段代码验证
   • 首先是bean类RequestScopeBean.java，注意作用域是RequestScoped，如下，在构造方法中打印日志，这样可以通过日志行数知道实例化次数
   • 然后是使用bean的代码，是个普通的web服务类
   • 最后是单元测试代码RequestScopeControllerTest.java，要注意的是注解RepeatedTest，有了此注解，testGetEndpoint方法会重复执行，次数是注解的value属性值，这里是10次

另外，请重点关注蓝框和蓝色注释文字，这是意外收获，居然看到了代理类的日志，看样子代理类是继承了RequestScopeBean类，于是父类构造方法中的日志代码也执行了，还把代理类的类名打印出来了

从日志可以看出：10次http请求，bean的构造方法执行了10次，代理类的构造方法只执行了一次，这是个重要结论：bean类被多次实例化的时候，代理类不会多次实例化

3. • SessionScoped与RequestScoped类似，区别是范围，RequestScoped是每次http请求做一次实例化，SessionScoped是每个http会话，以下场景都在session范围内，共享同一个bean实例：
   1. servlet的service方法
   2. servlet filter的doFileter方法
   3. web容器调用HttpSessionListener、AsyncListener、ServletRequestListener等监听器
4. • 提到Singleton，聪明的您是否想到了单例模式，这个scope也是此意：它修饰的bean，在整个应用中只有一个实例
   • Singleton和ApplicationScoped很像，它们修饰的bean，在整个应用中都是只有一个实例，然而它们也是有区别的：ApplicationScoped修饰的bean有代理类包裹，Singleton修饰的bean没有代理类
   • Singleton修饰的bean没有代理类，所以在使用的时候，对bean的成员变量直接读写都没有问题（safely），而ApplicationScoped修饰的bean，请不要直接读写其成员变量，比较拿都是代理的东西，而不是bean的类自己的成员变量
   • Singleton修饰的bean没有代理类，所以实际使用中性能会略好（slightly better performance）
   • 在使用QuarkusMock类做单元测试的时候，不能对Singleton修饰的bean做mock，因为没有代理类去执行相关操作
   • quarkus官方推荐使用的是ApplicationScoped
   • Singleton被quarkus划分为伪作用域，此时再回头品味下图，您是否恍然大悟：成员变量classAnnotationBean如果是Singleton，是没有代理类的，那就必须在@Inject位置实例化，否则，在get方法中classAnnotationBean就是null，会空指针异常的

5. • Dependent是个伪作用域，它的特点是：每个依赖注入点的对象实例都不同

   • 假设DependentClinetA和DependentClinetB都用@Inject注解注入了HelloDependent，那么DependentClinetA引用的HelloDependent对象，DependentClinetB引用的HelloDependent对象，是两个实例，如下图，两个hello是不同的实例

Dependent的特殊能力

• Dependent的特点是每个注入点的bean实例都不同，针对这个特点，quarkus提供了一个特殊能力：bean的实例中可以取得注入点的元数据

• 对应上图的例子，就是HelloDependent的代码中可以取得它的使用者：DependentClientA和DependentClientB的元数据

• 写代码验证这个特殊能力

• 首先是HelloDependent的定义，将作用域设置为Dependent，然后注意其构造方法的参数，这就是特殊能力所在，是个InjectionPoint类型的实例，这个参数在实例化的时候由quarkus容器注入，通过此参数即可得知使用HelloDependent的类的身份

• 然后是HelloDependent的使用类DependentClientA

• DependentClientB的代码和DependentClientA一模一样，就不贴出来了

LookupIfProperty，配置项的值符合要求才能使用bean

LookupUnlessProperty，配置项的值不符合要求才能使用bean

IfBuildProfile，如果是指定的profile才能使用bean

UnlessBuildProfile，如果不是指定的profile才能使用bean

IfBuildProperty，如果构建属性匹配才能使用bean

注解LookupIfProperty的作用是检查指定配置项，如果存在且符合要求，才能通过代码获取到此bean，

有个关键点请注意：下图是官方定义，可见LookupIfProperty并没有决定是否实例化beam，它决定的是能否通过代码取到bean，这个代码就是Instance来注入，并且用Instance.get方法来获取

• 定义一个接口TryLookupIfProperty.java

• 以及两个实现类

• 然后就是注解LookupIfProperty的用法了，如下所示，SelectBeanConfiguration是个配置类，里面有两个方法用来生产bean，都用注解LookupIfProperty修饰，如果配置项service.alpha.enabled的值等于true，就会执行tryLookupIfPropertyAlpah方法，如果配置项service.beta.enabled的值等于true，就会执行tryLookupIfPropertyBeta方法

  • 上述代码有以下两点要注意
  1. 注意TryLookupIfProperty的注入方式，对这种运行时才能确定具体实现类的bean，要用Instance的方式注入，使用时要用Instance.get方法取得bean
  2. 单元测试的BeforeAll注解用于指定测试前要做的事情，这里用System.setProperty设置配置项service.alpha.enabled，所以，理论上SelectBeanConfiguration.tryLookupIfPropertyAlpha方法应该会执行，也就是说注入的TryLookupIfProperty应该是TryLookupIfPropertyAlpha实例，所以testTryLookupIfProperty中用assertEquals断言预测：TryLookupIfProperty.hello的值来自TryLookupIfPropertyAlpha

LookupIfProperty和LookupUnlessProperty都有名为lookupIfMissing的属性，意思都一样：指定配置项不存在的时候，就执行注解所修饰的方法，修改SelectBeanConfiguration.java，如下图黄框所示，增加lookupIfMissing属性，指定值为true（没有指定的时候，默认值是false）

应用在运行时，其profile是固定的，IfBuildProfile检查当前profile是否是指定值，如果是，其修饰的bean就能被业务代码使用

对比官方对LookupIfProperty和IfBuildProfile描述的差别，LookupIfProperty决定了是否能被选择，IfBuildProfile决定了是否在容器中

• 再来看IfBuildProfile的用法，在刚才的SelectBeanConfiguration.java中新增两个方法，如下所示，应用运行时，如果profile是test，那么tryIfBuildProfileProd方法会被执行，还要注意的是注解DefaultBean的用法，如果profile不是test，那么quarkus的bean容器中就没有TryIfBuildProfile类型的bean了，此时DefaultBean修饰的tryIfBuildProfileDefault方法就会被执行，导致TryIfBuildProfileDefault的实例注册在quarkus容器中

• 单元测试代码写在刚才的BeanInstanceSwitchTest.java中，运行单元测试是profile被设置为test，所以tryIfBuildProfile的预期是TryIfBuildProfileProd实例，注意，这里和前面LookupIfProperty不一样的是：这里的TryIfBuildProfile直接注入就好，不需要Instance来注入

• 最后要提到注解是IfBuildProperty是，此注解与LookupIfProperty类似，下面是两个注解的官方描述对比，可见IfBuildProperty作用的熟悉主要是构建属性（前面的文章中提到过构建属性，它们的特点是运行期间只读，值固定不变）

• 限于篇幅，就不写代码验证了，来看看官方demo，用法上与LookupIfProperty类似，可以用DefaultBean来兜底，适配匹配失败的场景

• 在设置环境变量时，要注意转换规则：全大写、点号变下划线，因此greeting.message在环境变量中应该写成GREETING_MESSAGE

• 打开控制台，执行以下命令，即可在当前会话中设置环境变量：

​

• 为了避免之前的操作带来的影响，请重新打开一个控制台
• 在pom.xml文件所在目录新建文件.env，内容如下：

• 这种配置方式有个问题要注意：.env中的配置，在代码中使用System.getenv(String)无法取得
• 官方建议不要将.env文件提交到git、svn等版本控制工具中

为了避免之前的操作带来的影响，请删除刚才创建的.env文件

于hello-quarkus-1.0-SNAPSHOT-runner.jar文件所在目录，新建文件夹config

在config文件夹下新建文件application.properties，内容如下：

• 了避免之前的操作带来的影响，请删除刚才创建的config文件夹（里面的文件也删除）
• src/main/resources目录下的application.properties，这个配置相信您应该很熟悉，SpringBoot也是这样配置的

为了避免之前的操作带来的影响，请将src/main/resources/application.properties文件中的greeting.message配置项删除

MicroProfile是一个 Java 微服务开发的基础编程模型，它致力于定义企业 Java 微服务规范，其中的配置规范有如下描述：

图红框指出了MicroProfile规定的配置文件位置，咱们来试试在此位置放置配置文件是否能生效

如下图红框，在工程的src/main/resources/META-INF目录下新建文件microprofile-config.properties，内容如黄框所示

注意：microprofile-config.properties文件所在目录是src/main/resources/META-INF，不是src/main/resources/META-INF/resources

至此，六种配置方式及其实例验证都完成了，您可以按照自己的实际情况灵活选择

• 现在我们知道了通过何种途径将配置信息传给应用，接下来要看的是配置信息本身：我们可以在配置文件中输入哪些内容呢？
• 最常用的当然是字符串类型的键值对了，如下所示，刚才一直在用的，就不赘述了：

• 配置项的值可以引用其他配置项，如下所示，greeting.message的值由两部分拼接而成：固定的hello, 、以及配置项greeting.name的值，表达式的格式是**${配置项名称:配置项找不到时的默认值}**，:xxxxxx的意思是如果找不到配置项greeting.name，就用字符串xxxxxx代替

• 当同一个应用同时在多个机器上运行时，如何让每个进程有个独立的身份？
• quarkus提供了一个生成UUID的方式，可以低成本解决上述问题，如下所示，应用启动时，${quarkus.uuid}会生成一个UUID，此时的greeting.message的值也是唯一的

• 多刷几次浏览器，UUID始终不变，看来此UUID在整个进程存活期间都不会改变
• 重启应用，再用浏览器访问，如下图，UUID已更新，看来进程身份的唯一性可以通过此配置来保证

• 集合类型的配置也是常见需求，下面是常规的集合配置

• 对应的代码如下，可见只要被ConfigProperty修饰的成员变量是集合类型就行

• 还可以将集合中的每个元素分开写，如下所示，代码不变，效果和前面的配置一样

整篇文章由以下内容构成：

1. 创建工程，作为演示使用配置项操作的代码
2. 演示最基本的使用配置项操作
3. 展示配置项不存时会导致什么问题
4. 演示如何设置默认值，这样配置项不存在也不会出错
5. 默认值是字符串，而实际的变量可以是多种类型，它们之间的关系
6. Optional类型的配置注入
7. 不用注解注入，也可以写代码获取配置
8. 针对相同前缀的配置项，使用配置接口简化代码
9. 使用配置接口嵌套，简化多级的相同前缀配置项
10. 用map接受配置信息（减少配置项相关代码量）
11. quarkus及其扩展组件的内置配置项

• 对于上面演示的配置项不存在导致启动失败问题，可以给ConfigProperty注解设置默认值，这样一旦找不到配置项，就使用默认值注入，可以避免启动失败了
• HobbyResource.java的源码如下，成员变量notExistsConfig的注解了增加属性defaultValue

对于ConfigProperty注解的defaultValue属性还有一点要注意，来看ConfigProperty的源码，如下图，红框显示defaultValue的类型是String

上图中，defaultValue的注释有说明：如果ConfigProperty注解修饰的变量并非String型，那么defaultValue的字符串就会被自动quarkus字符转换

例如修饰的变量是int型，那么defaultValue的String类型的值会被转为int型再赋给变量，如下所示，notExistsConfig是int型，defaultValue的字符串可以被转为int：

• 除了上面试过的int，还有很多种类型都支持从defaultValue的字符串值被自动转换，它们是：

1. 基础类型：如boolean, byte, short
2. 装箱类型：如java.lang.Boolean, java.lang.Byte, java.lang.Short
3. Optional类型：java.util.Optional, java.util.OptionalInt, java.util.OptionalLong, and java.util.OptionalDouble
4. java枚举
5. java.time.Duration
6. JDK网络对象：如java.net.SocketAddress, java.net.InetAddress

• 如果ConfigProperty修饰的变量是boolean型，或者Boolean型，则defaultValue值的自动转换逻辑有些特别： “true”, “1”, “YES”, “Y” "ON"这些都会被转为true(而且不区分大小写，"on"也被转为true)，其他值会被转为false

• 还有一处要注意的：defaultValue的值如果是空字符串，就相当于没有设置defaultValue，此时如果在配置文件中没有该配置项，启动应用会报错

• 支持Optional这个特性很赞，首先Optional类型的成员变量可直接用于函数式编程，其次配置项不存在时又能避免启动失败
• 接下来试试用ConfigProperty注解修饰Optional类型的成员变量
• HobbyResource.java的源码如下，optionalMessage是Optional类型的成员变量，配置项optional.message就算不存在，应用也能正常启动，并且optionalMessage直接用于函数式编程中（optionalMessage.ifPresent）

• 除了用ConfigProperty注解来获取配置项的值，还可以用写代码的方式获取
• 下面的代码展示了通过API获取配置项的操作，请注意代码中的注释

另外，官方建议不要使用System.getProperty(String) 和 System.getEnv(String)去获取配置项了，它们并非quarkus的API，因此quarkus配置相关的功能与它们并无关系（例如感知配置变化、自动转换类型等）

• 假设配置项如下，都是相同的前缀student

• 针对上述配置项，可以用注解ConfigMapping将这些它们集中在一个接口类中获取，接口类StudentConfiguration.java如下

• 首先要看您的匹配项的命名风格，对多个单词是如何分隔的，一般有这三种：

1. 减号分隔：student-number
2. 下划线分隔：student_number
3. 驼峰命名：studentNumber

• ConfigMapping注解提供了namingStrategy的属性，其值有三种，分别对应上述三种命名风格，您根据自身情况选用即可

1. KEBAB_CASE（默认值）：减号分隔的配置项转为驼峰命令的方法，配置项student-number对应的方法是studentNumber
2. SNAKE_CASE：下划线分隔的配置项转为驼峰命令的方法，配置项student_number对应的方法是studentNumber
3. VERBATIM：完全对应，不做任何转换，配置项student_number对应的方法是student_number

• 再来看下面的配置，有两个配置项的前缀都是student.address，给人的感觉像是student对象里面有个成员变量是address类型的，而address有两个字段：province和city

• 针对上述配置，quarkus支持用接口嵌套来导入，具体做法分为两步，首先新增一个接口Address.java，源码如下

• 在配置接口StudentConfiguration.java中，增加下图红框中的一行代码（接口中返回接口，形成接口嵌套）

• 最后，修改HobbyResource.java代码，增加下图红框中的两行，验证能否正常取得address前缀的配置项目

• 前面的接口嵌套，虽然将多层级的配置以对象的形式清晰的表达出来，但也引出一个问题：配置越多，接口定义或者接口方法就越多，代码随之增加

• 如果配置项的层级简单，还有种简单的方式将其映射到配置接口中：转为map

  对应的代码改动如下图，只要把address方法的返回值从Address改为Map<String, String>即可，这样修改后，address层级下面再增加配置项，也不用修改配置项有关的代码了：

• quarkus有很多内置的配置项，例如web服务的端口quarkus.http.port就是其中一个，如果您熟悉SpringBoot的话，对这些内置配置项应该很好理解，数据库、消息、缓存，都有对应配置项

  篇幅所限就不在此讲解quarkus内置的配置项了，您可以参考这份官方提供的配置项列表，里面有详细说明：quarkus.io/guides/all-…

  这种带有加锁图标的配置项的值，在应用运行期间真的不能改变了吗？其实还是有办法的，官方文档指明，如果业务的情况特殊，一定要变，就走热部署的途径，您可以参考《quarkus实战之四：远程热部署》

  官方对开发者的建议：在开发quarkus应用的时候，不要使用quarkus作为配置项的前缀，因为目前quarkus框架及其插件们的配置项的前缀都是quarkus，应用开发应该避免和框架使用相同的配置项前缀，以免冲突

• profile自己是个普通的配置项，例如在application.properties文件中，是这样设置profile的

• 也可以在System properties中设置，如下所示，如此以来，不同环境只有启动命令不同，配置文件可以完全不用修改：

• profile的格式是%{profile-name}.config.name
• 以刚才的配置为例，quarkus.http.port配置项共出现三次，前两次带有前缀，格式是百分号+profile名称+点号，如下所示

• 在《quarkus实战之六：配置》一文中，曾提到过配置方式有六种，有几种要求配置项大写，例如在.env中的配置，此时格式变成了_{PROFILE}_CONFIG_KEY=value，举例如下

• 注意，实测发现在.env中配置QUARKUS_PROFILE=dev无效，也就是说不能在.env中指定profile，此时应该在启动命令中指定profile，例如：

• 不指定profile的时候，quarkus会给profile设置默认值，有三种可能：dev、test、prod，具体逻辑如下：

• 单元测试期间，例如执行命令mvn test，profile等于test

• 以上两种场景之外，profile等于prod，例如用命令java -jar hello-quarkus-1.0-SNAPSHOT-runner.jar启动应用

• 如果您希望每个profile都有自己的配置文件，quarkus也支持，如下所示，src/main/resources/目录下同时存在两个配置文件：application.properties和application-staging.properties

• application.properties内容如下

• application-staging.properties内容如下

• 如果启动命令指定了profile，如mvn quarkus:dev -Dquarkus.profile=staging，此时只有application-staging.properties文件生效，如下图

• 还要注意一点：此时如果指定一个不存在的profile，例如mvn quarkus:dev -Dquarkus.profile=xxxxxxx，此时生效的是application.properties文件生效，如下图

• parent profile解决的问题是：假设当前profile是aaa，那么配置项xxx对应的配置名应该是%dev.aaa，如果找不到%dev.aaa，就去找它的parent profile对应的配置项，来看个例子就清楚了，假设配置信息如下：

当前profile已经指定为dev

parent profile已经指定为common

对于配置项quarkus.http.port，由于没找到%dev.quarkus.http.port，就去找parent profile的配置，于是找到了%common.quarkus.http.port，所以值为9090

对于配置项quarkus.http.ssl-port，由于找到了%dev.quarkus.http.ssl-port，所以值为9443

对于配置项quarkus.http.port，如果%dev.quarkus.http.port和%common.quarkus.http.port都不存在，会用quarkus.http.port，值为8080

• 前面曾说到，启动的时候如果不指定profile，quarkus会指定默认的profile：将应用制作成jar，以java -jar命令启动时，profile会被设置为prod
• 如果您想让默认值从prod变为其他值，可以在构建的时候用-Dquarkus.profile去改变它，例如下面这个命令，jar包生成后，启动的时候默认profile是prod-aws

• 启动jar的时候不指定profile，如下图，profile已被设定为prod-aws

• quarkus官方给出了三个重点注意事项

1. 应用在运行时，只会有一种profile生效
2. 如果想在代码获取当前的profile，可以用此API

1. 用注解的方式获取profile是无效的，下面这段代码无法得到当前的profile