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

大佬quarkus笔记

依赖注入

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

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

修饰符匹配

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

@Qualifier
@Retention(RUNTIME)
@Target({TYPE, METHOD, FIELD, PARAMETER})
public @interface MyQualifier {
    @Nonbinding String value();
}

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

在这里插入图片描述

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

修饰符匹配要注意的地方

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

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

Named注解的属性匹配

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

根据优先级选择

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

写代码注入bean

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


@QuarkusTest
public class InstanceTest {

    @Inject
    Instance<HelloInstance> instance;

    @Test
    public void testSelectHelloInstanceA() {
        Class<HelloInstanceA> clazz = HelloInstanceA.class;

        Assertions.assertEquals(clazz.getSimpleName(),
                instance.select(clazz).get().hello());
    }

    @Test
    public void testSelectHelloInstanceB() {
        Class<HelloInstanceB> clazz = HelloInstanceB.class;

        Assertions.assertEquals(clazz.getSimpleName(),
                instance.select(clazz).get().hello());
    }
}

拦截器

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

定义和使用拦截器的操作介绍

定义和使用拦截器一共需要做三件事
1. 定义：新增一个注解（假设为A），要用@InterceptorBinding修饰该注解
2. 实现：拦截器A到底要做什么事情，需要在一个类中实现，该类需要两个注解来修饰：A和Interceptor
3. 使用：用A来修饰要拦截器的Bean

@InterceptorBinding
@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface HandleError {
}

/**
 * Priority注解的作用 设定HandlerError 拦截器的优先级（值越小优先级越高），可以同时用多个拦截器拦截同一个方法
 */
@HandleError
@Interceptor
@Priority(Interceptor.Priority.APPLICATION +1)
public class HandleErrorInterceptor {

    /**
     * AroundInvoke注解的作用 是表明execute会在拦截bean方法时被调用
     * @param context 可以从入参context处取得被拦截实例和方法的信息
     * @return
     */
    @AroundInvoke
    Object execute(InvocationContext context) {
        try {
            Log.info(context.getContextData());
            // 注意proceed方法的含义：调用下一个拦截器，直到最后一个才会执行被拦截的方法
            return context.proceed();
        } catch (Exception exception) {
            Log.errorf(exception,
                    "method error from %s.%s\n",
                    context.getTarget().getClass().getSimpleName(),
                    context.getMethod().getName());
        }

        return null;
    }
}


@ApplicationScoped
@HandleError
public class HandleErrorDemo {

    public void executeThrowError() {
        throw new IllegalArgumentException("this is business logic exception");
    }

    public void hello(){
        System.out.println("hello world");
    }
}

@QuarkusTest
public class InterceptorTest {

    @Inject
    HandleErrorDemo handleErrorDemo;

    @Test
    public void testHandleError() {
        handleErrorDemo.hello();
    }
}

拦截构造方法

@InterceptorBinding
@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface HandleConstruction {
}

@HandleConstruction
@Interceptor
@Priority(Interceptor.Priority.APPLICATION +1)
public class HandleConstructionInterceptor {

    @AroundConstruct
    void execute(InvocationContext context) throws Exception {
        // 执行业务逻辑可以在此
        Log.infov("start construction interceptor");

        // 执行bean的构造方法
        context.proceed();

        // 注意，对于context.getTarget()的返回值，此时不是null，如果在context.proceed()之前，则是null
        Log.infov("bean instance of {0}", context.getTarget().getClass().getSimpleName());
    }
}

@ApplicationScoped
@HandleConstruction
public class HandleonstructionDemo {

    public HandleonstructionDemo() {
        super();
        Log.infov("construction of {0}", HandleonstructionDemo.class.getSimpleName());
    }

    public void hello() {
        Log.info("hello world!");
    }
}

@QuarkusTest
public class InterceptorTest {

    @Inject
    HandleonstructionDemo handleonstructionDemo;

    @Test
    public void testHandleonstruction() {
        handleonstructionDemo.hello();
    }
}

获取被拦截方法的参数

@InterceptorBinding
@Target({TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface TrackParams {
}

@TrackParams
@Interceptor
@Priority(Interceptor.Priority.APPLICATION + 1)
public class TrackParamsInterceptor {

    @AroundInvoke
    Object execute(InvocationContext context) throws Exception {

        // context.getParameters()返回拦截方法的所有参数，
        // 用Optional处理非空时候的数组
        Optional.of(Arrays.stream(context.getParameters()))
                .ifPresent(stream -> {
                    stream.forEach(object -> Log.infov("parameter type [{0}], value [{1}]",
                                                       object.getClass().getSimpleName(),
                                                       object)
                    );
                });

        return context.proceed();
    }
}

@ApplicationScoped
@TrackParams
public class TrackParamsDemo {

    public void hello(String name, int id) {
        Log.infov("Hello {0}, your id is {1}", name, id);
    }
}

@QuarkusTest
public class InterceptorTest {

    @Inject
    TrackParamsDemo trackParamsDemo;

    @Test
    public void testTrackParams() {
        trackParamsDemo.hello("Tom", 101);
    }
}

多个拦截器之间传递参数

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

@InterceptorBinding
@Target({TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface ContextData {
    String KEY_PROCEED_INTERCEPTORS = "proceedInterceptors";
}

package com.bolingcavalry.interceptor.impl;

import io.quarkus.logging.Log;

import javax.interceptor.InvocationContext;
import java.util.ArrayList;
import java.util.List;
import java.util.Map;

import static com.bolingcavalry.interceptor.define.ContextData.KEY_PROCEED_INTERCEPTORS;

public class BaseContextDataInterceptor {

    Object execute(InvocationContext context) throws Exception {
        // 取出保存拦截器间共享数据的map
        Map<String, Object> map = context.getContextData();

        List<String> list;

        String instanceClassName = this.getClass().getSimpleName();

        // 根据指定key从map中获取一个list
        if (map.containsKey(KEY_PROCEED_INTERCEPTORS)) {
            list = (List<String>) map.get(KEY_PROCEED_INTERCEPTORS);
        } else {
            // 如果map中没有，就在此新建一个list，存如map中
            list = new ArrayList<>();
            map.put(KEY_PROCEED_INTERCEPTORS, list);

            Log.infov("from {0}, this is first processor", instanceClassName);
        }

        // 将自身内容存入list中，这样下一个拦截器只要是BaseContextDataInterceptor的子类，
        // 就能取得前面所有执行过拦截操作的拦截器
        list.add(instanceClassName);

        Log.infov("From {0}, all processors {0}", instanceClassName, list);

        return context.proceed();
    }
}

@ContextData
@Interceptor
@Priority(Interceptor.Priority.APPLICATION + 1)
public class ContextDataInterceptorA extends BaseContextDataInterceptor {

    @AroundInvoke
    Object execute(InvocationContext context) throws Exception {
        return super.execute(context);
    }
}

@ContextData
@Interceptor
@Priority(Interceptor.Priority.APPLICATION + 2)
public class ContextDataInterceptorB extends BaseContextDataInterceptor {

    @AroundInvoke
    Object execute(InvocationContext context) throws Exception {
        return super.execute(context);
    }
}

@ApplicationScoped
@ContextData
public class ContextDataDemo {

    public void hello() {
        Log.info("Hello world!");
    }
}

@QuarkusTest
public class InterceptorTest {

    @Inject
    ContextDataDemo contextDataDemo;

    @Test
    public void testContextData() {
        contextDataDemo.hello();
    }
}

发布订阅模式

同步事件

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

流程图 (20)

public class MyEvent {
    /**
     * 事件源
     */
    private String source;

    /**
     * 事件被消费的总次数
     */
    private AtomicInteger consumeNum;

    public MyEvent(String source) {
        this.source = source;
        consumeNum = new AtomicInteger();
    }

    /**
     * 事件被消费次数加一
     * @return
     */
    public int addNum() {
        return consumeNum.incrementAndGet();
    }

    /**
     * 获取事件被消费次数
     * @return
     */
    public int getNum() {
        return consumeNum.get();
    }

    @Override
    public String toString() {
        return "MyEvent{" +
                "source='" + source + '\'' +
                ", consumeNum=" + getNum() +
                '}';
    }
}

@ApplicationScoped
public class MyProducer {

    @Inject
    Event<MyEvent> event;

    /**
     * 发送同步消息
     * @param source 消息源
     * @return 被消费次数
     */
    public int syncProduce(String source) {
        MyEvent myEvent = new MyEvent("syncEvent");
        Log.infov("before sync fire, {0}", myEvent);
        event.fire(myEvent);
        Log.infov("after sync fire, {0}", myEvent);
        return myEvent.getNum();
    }
}

@ApplicationScoped
public class MyConsumer {

    /**
     * 消费同步事件
     * @param myEvent
     */
    public void syncConsume(@Observes MyEvent myEvent) {
        Log.infov("receive sync event, {0}", myEvent);

        // 模拟业务执行，耗时100毫秒
        try {
            Thread.sleep(100);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        // 计数加一
        myEvent.addNum();
    }
}

@QuarkusTest
public class EventTest {

    @Inject
    MyProducer myProducer;

    @Inject
    MyConsumer myConsumer;

    @Test
    public void testSync() {
        Assertions.assertEquals(1, myProducer.syncProduce("testSync"));
    }
}

异步事件

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

public int asyncProduce(String source) {
        MyEvent myEvent = new MyEvent(source);
        Log.infov("before async fire, {0}", myEvent);
        event.fireAsync(myEvent)
             .handleAsync((e, error) -> {
                 if (null!=error) {
                     Log.error("handle error", error);
                 } else {
                     Log.infov("finish handle, {0}", myEvent);
                 }

                 return null;
             });
        Log.infov("after async fire, {0}", myEvent);
        return myEvent.getNum();
    }

发送异步事件的API是fireAsync

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

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

public void aSyncConsume(@ObservesAsync MyEvent myEvent) {
        Log.infov("receive async event, {0}", myEvent);

        // 模拟业务执行，耗时100毫秒
        try {
            Thread.sleep(100);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        // 计数加一
        myEvent.addNum();
    }

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

 @Test
    public void testAsync() throws InterruptedException {
        Assertions.assertEquals(0, myProducer.asyncProduce("testAsync"));
        // 如果不等待的话，主线程结束的时候会中断正在消费事件的子线程，导致子线程报错
        Thread.sleep(150);
    }

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

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

同一种事件类，用在不同的业务场景

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

流程图 (21)

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

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

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

public class TwoChannelEvent {
    /**
     * 事件源
     */
    private String source;

    /**
     * 事件被消费的总次数
     */
    private AtomicInteger consumeNum;

    public TwoChannelEvent(String source) {
        this.source = source;
        consumeNum = new AtomicInteger();
    }

    /**
     * 事件被消费次数加一
     * @return
     */
    public int addNum() {
        return consumeNum.incrementAndGet();
    }

    /**
     * 获取事件被消费次数
     * @return
     */
    public int getNum() {
        return consumeNum.get();
    }

    @Override
    public String toString() {
        return "TwoChannelEvent{" +
                "source='" + source + '\'' +
                ", consumeNum=" + getNum() +
                '}';
    }
}

然后就是关键点：自定义注解Admin，这是管理员事件的过滤器，要用Qualifier修饰
```
@Qualifier
@Retention(RUNTIME)
@Target({FIELD, PARAMETER})
public @interface Admin {
}
```

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

@Qualifier
@Retention(RUNTIME)
@Target({FIELD, PARAMETER})
public @interface Normal {
}

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

@ApplicationScoped
public class TwoChannelWithTwoEvent {

    @Inject
    @Admin
    Event<TwoChannelEvent> adminEvent;

    @Inject
    @Normal
    Event<TwoChannelEvent> normalEvent;

    /**
     * 管理员消息
     * @param source
     * @return
     */
    public int produceAdmin(String source) {
        TwoChannelEvent event = new TwoChannelEvent(source);
        adminEvent.fire(event);
        return event.getNum();
    }

    /**
     * 普通消息
     * @param source
     * @return
     */
    public int produceNormal(String source) {
        TwoChannelEvent event = new TwoChannelEvent(source);
        normalEvent.fire(event);
        return event.getNum();
    }
}

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

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

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

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

@ApplicationScoped
public class TwoChannelConsumer {

    /**
     * 消费管理员事件
     * @param event
     */
    public void adminEvent(@Observes @Admin TwoChannelEvent event) {
        Log.infov("receive admin event, {0}", event);
        // 管理员的计数加两次，方便单元测试验证
        event.addNum();
        event.addNum();
    }

    /**
     * 消费普通用户事件
     * @param event
     */
    public void normalEvent(@Observes @Normal TwoChannelEvent event) {
        Log.infov("receive normal event, {0}", event);
        // 计数加一
        event.addNum();
    }

    /**
     * 如果不用注解修饰，所有TwoChannelEvent类型的事件都会在此被消费
     * @param event
     */
    public void allEvent(@Observes TwoChannelEvent event) {
        Log.infov("receive event (no Qualifier), {0}", event);
        // 计数加一
        event.addNum();
    }
}

@QuarkusTest
public class EventTest {
  
    @Inject
    TwoChannelWithTwoEvent twoChannelWithTwoEvent;

    @Test
    public void testTwoChnnelWithTwoEvent() {
        // 对管理员来说，
        // TwoChannelConsumer.adminEvent消费时计数加2，
        // TwoChannelConsumer.allEvent消费时计数加1，
        // 所以最终计数是3
        Assertions.assertEquals(3, twoChannelWithTwoEvent.produceAdmin("admin"));

        // 对普通人员来说，
        // TwoChannelConsumer.normalEvent消费时计数加1，
        // TwoChannelConsumer.allEvent消费时计数加1，
        // 所以最终计数是2
        Assertions.assertEquals(2, twoChannelWithTwoEvent.produceNormal("normal"));
    }
}

小优化，不需要注入多个Event实例

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

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

/**
 * @author will
 * @email zq2599@gmail.com
 * @date 2022/4/3 10:16
 * @description 用同一个事件结构体TwoChannelEvent，分别发送不同业务类型的事件
 */
@ApplicationScoped
public class TwoChannelWithSingleEvent {

    @Inject
    Event<TwoChannelEvent> singleEvent;
    
    /**
     * 管理员消息
     * @param source
     * @return
     */
    public int produceAdmin(String source) {
        TwoChannelEvent event = new TwoChannelEvent(source);

        singleEvent.select(new AnnotationLiteral<Admin>() {})
                   .fire(event);

        return event.getNum();
    }

    /**
     * 普通消息
     * @param source
     * @return
     */
    public int produceNormal(String source) {
        TwoChannelEvent event = new TwoChannelEvent(source);

        singleEvent.select(new AnnotationLiteral<Normal>() {})
                .fire(event);

        return event.getNum();
    }
}

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

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

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

@QuarkusTest
public class EventTest {
    @Inject
    TwoChannelWithSingleEvent twoChannelWithSingleEvent;

    @Test
    public void testTwoChnnelWithSingleEvent() {
        // 对管理员来说，
        // TwoChannelConsumer.adminEvent消费时计数加2，
        // TwoChannelConsumer.allEvent消费时计数加1，
        // 所以最终计数是3
        Assertions.assertEquals(3, twoChannelWithSingleEvent.produceAdmin("admin"));

        // 对普通人员来说，
        // TwoChannelConsumer.normalEvent消费时计数加1，
        // TwoChannelConsumer.allEvent消费时计数加1，
        // 所以最终计数是2
        Assertions.assertEquals(2, twoChannelWithSingleEvent.produceNormal("normal"));
    }
}

事件元数据

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

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

public void allEvent(@Observes TwoChannelEvent event, EventMetadata eventMetadata) {
        Log.infov("receive event (no Qualifier), {0}", event);

        // 打印事件类型
        Log.infov("event type : {0}", eventMetadata.getType());

        // 获取该事件的所有注解
        Set<Annotation> qualifiers = eventMetadata.getQualifiers();

        // 将事件的所有注解逐个打印
        if (null!=qualifiers) {
            qualifiers.forEach(annotation -> Log.infov("qualify : {0}", annotation));
        }

        // 计数加一
        event.addNum();
}

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

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

生命周期回调

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

流程图 - 2022-04-05T094019.781

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

拦截器模式

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

流程图 (19)

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

@InterceptorBinding
@Target({TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface TrackLifeCycle {
}

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

@TrackLifeCycle
@Interceptor
@Priority(Interceptor.Priority.APPLICATION + 1)
public class LifeCycleInterceptor {

    @AroundConstruct
    void execute(InvocationContext context) throws Exception {
        Log.info("start AroundConstruct");
        try {
            context.proceed();
        } catch (Exception e) {
            e.printStackTrace();
        }
        Log.info("end AroundConstruct");
    }

    @PostConstruct
    public void doPostConstruct(InvocationContext ctx) {
        Log.info("life cycle PostConstruct");
    }

    @PreDestroy
    public void doPreDestroy(InvocationContext ctx) {
        Log.info("life cycle PreDestroy");
    }
}

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

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

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

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

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

@ApplicationScoped
@TrackLifeCycle
public class Hello {

    public Hello() {
        Log.info(this.getClass().getSimpleName() + " at instance");
    }

    public void helloWorld() {
        Log.info("Hello world!");
    }
}

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

@QuarkusTest
public class LifeCycleTest {

    @Inject
    Hello hello;

    @Test
    public void testLifyCycle() {
        hello.helloWorld();
    }
}

自定义模式

刚才的拦截器模式有个明显问题：如果不同bean的生命周期回调有不同业务需求，该如何是好？为每个bean做一个拦截器吗？随着bean的增加会有大量拦截器，似乎不是个好的方案
如果您熟悉spring，对下面的代码要改不陌生，这是来自spring官网的内容，直接在bean的方法上用PostConstruct和PreDestroy修饰，即可在bean的创建完成和销毁前被调用

public class CachingMovieLister {

  @PostConstruct
  public void populateMovieCache() {
      // populates the movie cache upon initialization...
  }

  @PreDestroy
  public void clearMovieCache() {
      // clears the movie cache upon destruction...
  }
}

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

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

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

@ApplicationScoped
@TrackLifeCycle
public class Hello {

    public Hello() {
        Log.info(this.getClass().getSimpleName() + " at instance");
    }

    @PostConstruct
    public void doPostConstruct() {
        Log.info("at doPostConstruct");
    }

    @PreDestroy
    public void doPreDestroy() {
        Log.info("at PreDestroy");
    }

    public void helloWorld() {
        Log.info("Hello world!");
    }
}

dispose注解：实现销毁前自定义操作，dispose是另一种可选方案

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

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

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

package com.bolingcavalry.service.impl;

import io.quarkus.logging.Log;

/**
 * @author zq2599@gmail.com
 * @Title: 资源管理类
 * @Package
 * @Description:
 * @date 4/10/22 10:20 AM
 */
public class ResourceManager {

    public ResourceManager () {
        Log.info("create instance, " + this.getClass().getSimpleName());
    }

    /**
     * 假设再次方法中打开资源，如网络、文件、数据库等
     */
    public void open() {
        Log.info("open resource here");
    }

    /**
     * 假设在此方法中关闭所有已打开的资源
     */
    public void closeAll() {
        Log.info("close all resource here");
    }
}

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

package com.bolingcavalry.config;

import com.bolingcavalry.service.impl.ResourceManager;
import javax.enterprise.context.RequestScoped;

public class SelectBeanConfiguration {

    @RequestScoped
    public ResourceManager getResourceManager() {
        return new ResourceManager();
    }  
}

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

package com.bolingcavalry;

import com.bolingcavalry.service.impl.ResourceManager;

import javax.inject.Inject;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;

@Path("/resourcemanager")
public class ResourceManagerController {

    @Inject
    ResourceManager resourceManager;

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String get() {
        resourceManager.open();
        return "success";
    }
}

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

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

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

/**
 * 使用了Disposes注解后，ResourceManager类型的bean在销毁前，此方法都会执行
 * @param resourceManager
 */
public void closeResource(@Disposes ResourceManager resourceManager) {
    // 在这里可以做一些额外的操作，不需要bean参与
    Log.info("do other things that bean do not care");

    // 也可以执行bean的方法
    resourceManager.closeAll();
}

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

@QuarkusTest
public class DisposeTest {

    @RepeatedTest(3)
    public void test() {
        given()
                .when().get("/resourcemanager")
                .then()
                .statusCode(200)
                // 检查body内容
                .body(is("success"));
    }
}

装饰器（Decorator）

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

实战功能说明

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

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

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

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

编码实践

public interface Coffee {

    /**
     * 咖啡名称
     * @return
     */
    String name();

    /**
     * 当前咖啡的价格
     * @return
     */
    int getPrice();
}

/**
 * 意式浓缩咖啡，价格3美元
 */
@ApplicationScoped
public class Espresso implements Coffee {

    @Override
    public String name() {
        return "Espresso";
    }

    @Override
    public int getPrice() {
        return 3;
    }
}

@Decorator
@Priority(11)
public class Latte implements Coffee {
    /**
     * 牛奶价格：2美元
     */
    private static final int MILK_PRICE = 2;
 		/**
     * 使用quarkus的装饰器功能时，有两件事必须要做：装饰类要用注解Decorator修饰，被装饰类要用注解						Delegate修饰
     * 因此，Latte被注解Decorator修饰，Latte的成员变量delegate是被装饰类，要用注解Delegate修饰，
     * Latte的成员变量delegate并未指明是Espresso，quarkus会选择Espresso的bean注入到这里
     */

    @Delegate
    @Inject
    Coffee delegate;

    @Override
    public String name() {
        return "Latte";
    }

    @Override
    public int getPrice() {
        // 将Latte的代理类打印出来，看quarkus注入的是否正确
        Log.info("Latte's delegate type : " + this.delegate.name());
        return delegate.getPrice() + MILK_PRICE;
    }
}

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

/**
 * 焦糖玛奇朵：拿铁+焦糖
 */
@Decorator
@Priority(10)
public class CaramelMacchiato implements Coffee {

    /**
     * 焦糖价格：1美元
     */
    private static final int CARAMEL_PRICE = 1;

    @Delegate
    @Inject
    Coffee delegate;

    @Override
    public String name() {
        return "CaramelMacchiato";
    }

    @Override
    public int getPrice() {
        // 将CaramelMacchiato的代理类打印出来，看quarkus注入的是否正确
        Log.infov("CaramelMacchiato's delegate type : " + this.delegate.name());
        return delegate.getPrice() + CARAMEL_PRICE;
    }
}

重要知识点

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

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

流程图 - 2022-04-09T203421.135

@QuarkusTest
public class DecoratorTest {

    @Inject
    Coffee coffee;

    @Test
    public void testDecoratorPrice() {
        Assertions.assertEquals(6, coffee.getPrice());
    }
}

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

bean读写锁

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

直接结论

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

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

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

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

学习和改变bean懒加载规则

关于懒加载（Lazy Instantiation

CDI规范下的懒加载规则：

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

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

编码验证懒加载

@ApplicationScoped
public class NormalApplicationScoped {

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

    public String ping() {
        return "ping from NormalApplicationScoped";
    }
}

@Singleton
public class NormalSingleton {

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

    public String ping() {
        return "ping from NormalSingleton";
    }
}

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

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

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

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

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

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

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

Startup注解的value属性值，是bean的优先级，这样，多个bean都使用Startup的时候，可以通过value值设置优先级，以此控制实例化顺序（实际上控制的是事件observer的创建顺序）
如果一个类只有Startup注解修饰，而没有设置作用域的时候，quarkus自动将其作用域设置为ApplicationScoped，也就是说，下面这段代码中，ApplicationScoped注解写不写都一样
```
@ApplicationScoped
@Startup
public class NormalApplicationScoped {
```

总结

流程图 (3)

拦截器高级特性（属性设置和重复使用）

先定义三个bean

public interface SayHello {
    void hello();
}

@ApplicationScoped
@Named("A")
public class SayHelloA implements SayHello {
    @SendMessage
    @Override
    public void hello() {
        Log.info("hello from A");
    }
}


@ApplicationScoped
@Named("B")
public class SayHelloB implements SayHello {
    @SendMessage(sendType = "email")
    @Override
    public void hello() {
        Log.info("hello from B");
    }
}

@ApplicationScoped
@Named("C")
public class SayHelloC implements SayHello {
    @SendMessage
    @SendMessage(sendType = "email")
    @Override
    public void hello() {
        Log.info("hello from C");
    }
}

需求：

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

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

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

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

定义拦截器

@InterceptorBinding
@Repeatable(SendMessage.SendMessageList.class)
@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface SendMessage {

    /**
     * 消息类型 : "sms"表示短信，"email"表示邮件
     * @return
     */
    @Nonbinding
    String sendType() default "sms";

    @Target({ElementType.TYPE, ElementType.METHOD})
    @Retention(RetentionPolicy.RUNTIME)
    @interface SendMessageList {
        SendMessage[] value();
    }
}

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

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

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

可以作用在方法上
不能作用在类上
不能作用在stereotypes上

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

@SendMessage
@Interceptor
public class SendMessageInterceptor {

    @AroundInvoke
    Object execute(InvocationContext context) throws Exception {
        // 先执行被拦截的方法
        Object rlt = context.proceed();

        // 获取被拦截方法的类名
        String interceptedClass = context.getTarget().getClass().getSimpleName();

        // 代码能走到这里，表示被拦截的方法已执行成功，未出现异常
        // 从context中获取通知类型，由于允许重复注解，因此通知类型可能有多个
        List<String> allTypes = getAllTypes(context);

        // 将所有消息类型打印出来
        Log.infov("{0} messageTypes : {1}", interceptedClass, allTypes);

        // 遍历所有消息类型，调用对应的方法处理
        for (String type : allTypes) {
            switch (type) {
                // 短信
                case "sms":
                    sendSms();
                    break;
                // 邮件
                case "email":
                    sendEmail();
                    break;
            }
        }

        // 最后再返回方法执行结果
        return rlt;
    }

    /**
     * 从InvocationContext中取出所有注解，过滤出SendMessage类型的，将它们的type属性放入List中返回
     * @param invocationContext
     * @return
     */
    private List<String> getAllTypes(InvocationContext invocationContext) {
        // 取出所有注解
        Set<Annotation> bindings = InterceptorBindings.getInterceptorBindings(invocationContext);

        List<String> allTypes = new ArrayList<>();

        // 遍历所有注解，过滤出SendMessage类型的
        for (Annotation binding : bindings) {
            if (binding instanceof SendMessage) {
               allTypes.add(((SendMessage) binding).sendType());
            }
        }

        return allTypes;
    }

    /**
     * 模拟发送短信
     */
    private void sendSms() {
        Log.info("operating success, from sms");
    }

    /**
     * 模拟发送邮件
     */
    private void sendEmail() {
        Log.info("operating success, from email");
    }
}

@QuarkusTest
public class SendMessageTest {

    @Named("A")
    SayHello sayHelloA;

    @Named("B")
    SayHello sayHelloB;

    @Named("C")
    SayHello sayHelloC;

    @Test
    public void testSendMessage() {
        sayHelloA.hello();
        sayHelloB.hello();
        sayHelloC.hello();
    }
}

禁用类级别拦截器

类拦截器和方法拦截器的叠加效果

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

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

@InterceptorBinding
@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface TrackClass {
}

@TrackClass
@Interceptor
public class TrackClassInterceptor {

    @AroundInvoke
    Object execute(InvocationContext context) throws Exception {
        Log.info("from TrackClass");
        return context.proceed();
    }
}

@InterceptorBinding
@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface TrackMethod {
}

@TrackMethod
@Interceptor
public class TrackMethodInterceptor {

    @AroundInvoke
    Object execute(InvocationContext context) throws Exception {
        Log.info("from TrackMethod");
        return context.proceed();
    }
}

@ApplicationScoped
@TrackClass
public class ExcludeInterceptorDemo {

    public void test0() {
        Log.info("from test0");
    }

    @TrackMethod
    public void test1() {
        Log.info("from test1");
    }
}

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

测试

@QuarkusTest
public class ExcludeInterceptorTest {
   
    @Inject
    ExcludeInterceptorDemo excludeInterceptorDemo;

    @Test
    public void test() {
        excludeInterceptorDemo.test0();
        Log.info("*****************************");
        excludeInterceptorDemo.test1();
    }
}

用注解NoClassInterceptors使类拦截器失效

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

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

NoClassInterceptors的影响范围

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

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

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

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

其他重要知识点大串讲

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

简化之一：bean注入

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

@ApplicationScoped
public class ConfigBean {
    @ConfigProperty(name = "aaa.name")
    String greetingMsg;

    public String getGreetingMsg() {
        return greetingMsg;
    }
}

简化之二：bean构造方法

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

@ApplicationScoped
public class MyCoolService {

  private SimpleProcessor processor;

  MyCoolService() { // dummy constructor needed
  }

  @Inject // constructor injection
  MyCoolService(SimpleProcessor processor) {
    this.processor = processor;
  }
}

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

@ApplicationScoped
public class MyCoolService {

  private SimpleProcessor processor;

  MyCoolService(SimpleProcessor processor) {
    this.processor = processor;
  }
}

简化之三：bean生产方法

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

class Producers {
  
  @Produces
  @ApplicationScoped
  MyService produceServ
    ice() {
    return new MyService(coolProperty);
  }
}

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

class Producers {

  @ApplicationScoped
  MyService produceService() {
    return new MyService(coolProperty);
  }
}

WithCaching注解：避免不必要的多次实例化

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

@Dependent
public class HelloDependent {

    public HelloDependent(InjectionPoint injectionPoint) {
        Log.info("injecting from bean "+ injectionPoint.getMember().getDeclaringClass());
    }

    public String hello() {
        return this.getClass().getSimpleName();
    }
}

@QuarkusTest
public class WithCachingTest {

    @Inject
    Instance<HelloDependent> instance;

    @Test
    public void test() {
        // 第一次调用Instance#get方法
        HelloDependent helloDependent = instance.get();
        helloDependent.hello();

        // 第二次调用Instance#get方法
        helloDependent = instance.get();
        helloDependent.hello();
    }
}

如果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，这一点尤其要注意，例如下图红框中的代码，在拦截静态方法是就会抛出空指针异常

All更加直观的注入

public interface SayHello {
    void hello();
}

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

public class InjectAllTest {
    /**
     * 用Instance接收注入，得到所有SayHello类型的bean
     */
    @Inject
    Instance<SayHello> instance;

    @Test
    public void testInstance() {
        // instance中有迭代器，可以用遍历的方式得到所有bean
        for (SayHello sayHello : instance) {
            sayHello.hello();
        }
    }
}

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

@QuarkusTest
public class InjectAllTest {
    /**
     * 用All注解可以将SayHello类型的bean全部注入到list中，
     * 这样更加直观
     */
    @All
    List<SayHello> list;

    @Test
    public void testAll() {
        for (SayHello sayHello : list) {
            sayHello.hello();
        }
    }
}

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

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

@QuarkusTest
public class InjectAllTest {
    
    @All
    List<InstanceHandle<SayHello>> list;

    @Test
    public void testQuarkusAllAnnonation() {
        for (InstanceHandle<SayHello> instanceHandle : list) {
            // InstanceHandle#get可以得到注入bean
            SayHello sayHello = instanceHandle.get();

            // InjectableBean封装了注入bean的元数据信息
            InjectableBean<SayHello> injectableBean = instanceHandle.getBean();

            // 例如bean的作用域就能从InjectableBean中取得
            Class clazz = injectableBean.getScope();

            // 打印出来验证
            Log.infov("bean [{0}], scope [{1}]", sayHello.getClass().getSimpleName(), clazz.getSimpleName() );
        }
    }
}

统一处理异步事件的异常

需要提前说一下，本段落涉及的知识点和AsyncObserverExceptionHandler类有关，而《quarkus依赖注入》系列所用的quarkus-2.7.3.Final版本中并没有AsyncObserverExceptionHandler类，后来将quarkus版本更新为2.8.2.Final，就可以正常使用AsyncObserverExceptionHandler类了
本段落的知识点和异步事件有关：如果消费异步事件的过程中发生异常，而开发者有没有专门写代码处理异步消费结果，那么此异常就默默无闻的被忽略了，我们也可能因此错失了及时发现和处理问题的时机

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

public class TestEvent {
}

@ApplicationScoped
public class TestEventProducer {

    @Inject
    Event<TestEvent> event;

    /**
     * 发送异步事件
     */
    public void asyncProduce() {
        event.fireAsync(new TestEvent());
    }
}

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

@ApplicationScoped
public class TestEventConsumer {

    /**
     * 消费异步事件，这里故意抛出异常
     */
    public void aSyncConsume(@ObservesAsync TestEvent testEvent) throws Exception {
       throw new Exception("exception from aSyncConsume");
    }
}

@QuarkusTest
public class EventExceptionHandlerTest {

    @Inject
    TestEventProducer testEventProducer;

    @Test
    public void testAsync() throws InterruptedException {
       testEventProducer.asyncProduce();
    }
}

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

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

@ApplicationScoped
public class NoopAsyncObserverExceptionHandler implements AsyncObserverExceptionHandler {

    @Override
    public void handle(Throwable throwable, ObserverMethod<?> observerMethod, EventContext<?> eventContext) {
        // 异常信息
        Log.info("exception is - " + throwable);
        // 事件信息
        Log.info("observer type is - " + observerMethod.getObservedType().getTypeName());
    }
}

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

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

小点回顾补充

CDI

官方提醒

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

Quarkus is designed with Substrate VM in mind. For this reason, we encourage you to use *package-private* scope instead of *private*.

关于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规范的内容（请原谅欣宸的英语水平）：

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

关于CDI的bean

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

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

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

创建bean实例：注解修饰在类上

@ApplicationScoped
public class ClassAnnotationBean {

    public String hello() {
        return "from " + this.getClass().getSimpleName();
    }
}

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

@Path("/classannotataionbean")
public class ClassAnnotationController {

    @Inject
    ClassAnnotationBean classAnnotationBean;

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String hello() {
        return String.format("Hello RESTEasy, %s, %s",
                LocalDateTime.now(),
                classAnnotationBean.hello());
    }
}

创建bean实例：注解修饰在方法上

public interface HelloService {
    String hello();
}

public class HelloServiceImpl implements HelloService {
    @Override
    public String hello() {
        return "from " + this.getClass().getSimpleName();
    }
}

public class MethodAnnonationBean {

    @Produces  // 可省略
    @ApplicationScoped
    public HelloService getHelloService() {
        return new HelloServiceImpl();
    }
}

这种用于创建bean的方法，被quarkus称为producer method
看过上述代码，相信聪明的您应该明白了用这种方式创建bean的优点：在创建HelloService接口的实例时，可以控制所有细节（构造方法的参数、或者从多个HelloService实现类中选择一个），没错，在SpringBoot的Configuration类中咱们也是这样做的
前面的getHelloService方法的返回值，可以直接在业务代码中依赖注入，如下所示

@Path("/methodannotataionbean")
public class MethodAnnotationController {

    @Inject
    HelloService helloService;

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String get() {
        return String.format("Hello RESTEasy, %s, %s",
                LocalDateTime.now(),
                helloService.hello());
    }
}

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

public class MethodAnnonationBean {

    @Produces
    @ApplicationScoped
    public HelloService getHelloService(OtherService otherService) {
        return new HelloServiceImpl();
    }
}

创建bean实例：注解修饰在成员变量上

public class OtherServiceImpl {

    public String hello() {
        return "from " + this.getClass().getSimpleName();
    }
}

public class FieldAnnonationBean {

    @Produces
    @ApplicationScoped
    OtherServiceImpl otherServiceImpl = new OtherServiceImpl();
}

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

关于synthetic bean

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

@BuildStep
@Record(STATIC_INIT)
SyntheticBeanBuildItem syntheticBean(TestRecorder recorder) {
   return SyntheticBeanBuildItem.configure(Foo.class).scope(Singleton.class)
                .runtimeValue(recorder.createFoo("parameters are recorder in the bytecode")) 
                .done();
}

quarkus依赖注入之二：bean的作用域

关于bean的作用域（scope）

作为《quarkus依赖注入》系列的第二篇，继续学习一个重要的知识点：bean的作用域（scope），每个bean的作用域是唯一的，不同类型的作用域，决定了各个bean实例的生命周期，例如：何时何处创建，又何时何处销毁
bean的作用域在代码中是什么样的？回顾前文的代码，如下，ApplicationScoped就是作用域，表明bean实例以单例模式一直存活（只要应用还存活着），这是业务开发中常用的作用域类型：

@ApplicationScoped
public class ClassAnnotationBean {

    public String hello() {
        return "from " + this.getClass().getSimpleName();
    }
}

请添加图片描述

内置

常规作用域和伪作用域

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

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

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

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

@ApplicationScoped
public class ClassAnnotationBean {

    public String hello() {
        return "from " + this.getClass().getSimpleName();
    }
}

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

@Path("/classannotataionbean")
public class ClassAnnotationController {

    @Inject
    ClassAnnotationBean classAnnotationBean;

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String get() {
        return String.format("Hello RESTEasy, %s, %s",
                LocalDateTime.now(),
                classAnnotationBean.hello());
    }
}

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

常规作用域

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

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

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

时间点	常规作用域	为作用域
注入的时候	注入的是一个代理类，此时ClassAnnotationBean并未实例化	触发ClassAnnotationBean的实例化
get方法首次执行的时候	1. 触发ClassAnnotationBean实例化 2.执行常规业务代码	执行常规代码

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

RequestScoped

SessionScoped

ApplicationScoped
- ApplicationScoped算是最常用的作用域了，它修饰的bean，在整个应用中只有一个实例

RequestScoped

这是与当前http请求绑定的作用域，它修饰的bean，在每次http请求时都有一个全新实例，来写一段代码验证
首先是bean类RequestScopeBean.java，注意作用域是RequestScoped，如下，在构造方法中打印日志，这样可以通过日志行数知道实例化次数

@RequestScoped
public class RequestScopeBean {

    /**
     * 在构造方法中打印日志，通过日志出现次数对应着实例化次数
     */
    public RequestScopeBean() {
        Log.info("Instance of " + this.getClass().getSimpleName());
    }

    public String hello() {
        return "from " + this.getClass().getSimpleName();
    }
}

然后是使用bean的代码，是个普通的web服务类

@Path("/requestscope")
public class RequestScopeController {

    @Inject
    RequestScopeBean requestScopeBean;

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String get() {
        return String.format("Hello RESTEasy, %s, %s",
                LocalDateTime.now(),
                requestScopeBean.hello());
    }
}

最后是单元测试代码RequestScopeControllerTest.java，要注意的是注解RepeatedTest，有了此注解，testGetEndpoint方法会重复执行，次数是注解的value属性值，这里是10次

@QuarkusTest
class RequestScopeControllerTest {

    @RepeatedTest(10)
    public void testGetEndpoint() {
        given()
                .when().get("/requestscope")
                .then()
                .statusCode(200)
                // 检查body内容，是否含有ClassAnnotationBean.hello方法返回的字符串
                .body(containsString("from " + RequestScopeBean.class.getSimpleName()));
    }
}

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

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

SessionScoped
- SessionScoped与RequestScoped类似，区别是范围，RequestScoped是每次http请求做一次实例化，SessionScoped是每个http会话，以下场景都在session范围内，共享同一个bean实例：
1. servlet的service方法
2. servlet filter的doFileter方法
3. web容器调用HttpSessionListener、AsyncListener、ServletRequestListener等监听器
Singleton
- 提到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，会空指针异常的
Dependent
- Dependent是个伪作用域，它的特点是：每个依赖注入点的对象实例都不同
- 假设DependentClinetA和DependentClinetB都用@Inject注解注入了HelloDependent，那么DependentClinetA引用的HelloDependent对象，DependentClinetB引用的HelloDependent对象，是两个实例，如下图，两个hello是不同的实例

流程图 (18)

Dependent的特殊能力

Dependent的特点是每个注入点的bean实例都不同，针对这个特点，quarkus提供了一个特殊能力：bean的实例中可以取得注入点的元数据
对应上图的例子，就是HelloDependent的代码中可以取得它的使用者：DependentClientA和DependentClientB的元数据
写代码验证这个特殊能力
首先是HelloDependent的定义，将作用域设置为Dependent，然后注意其构造方法的参数，这就是特殊能力所在，是个InjectionPoint类型的实例，这个参数在实例化的时候由quarkus容器注入，通过此参数即可得知使用HelloDependent的类的身份

@Dependent
public class HelloDependent {

    public HelloDependent(InjectionPoint injectionPoint) {
        Log.info("injecting from bean "+ injectionPoint.getMember().getDeclaringClass());
    }

    public String hello() {
        return this.getClass().getSimpleName();
    }
}

然后是HelloDependent的使用类DependentClientA

@ApplicationScoped
public class DependentClientA {

    @Inject
    HelloDependent hello;

    public String doHello() {
        return hello.hello();
    }
}

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

@QuarkusTest
public class DependentTest {

    @Inject
    DependentClientA dependentClientA;

    @Inject
    DependentClientB dependentClientB;

    @Test
    public void testSelectHelloInstanceA() {
        Class<HelloDependent> clazz = HelloDependent.class;

        Assertions.assertEquals(clazz.getSimpleName(), dependentClientA.doHello());
        Assertions.assertEquals(clazz.getSimpleName(), dependentClientB.doHello());
    }
}

用注解选择注入bean

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

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

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

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

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

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

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

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

定义一个接口TryLookupIfProperty.java

public interface TryLookupIfProperty {
    String hello();
}

以及两个实现类

public class TryLookupIfPropertyAlpha implements TryLookupIfProperty {
    @Override
    public String hello() {
        return "from " + this.getClass().getSimpleName();
    }
}

public class TryLookupIfPropertyBeta implements TryLookupIfProperty {
    @Override
    public String hello() {
        return "from " + this.getClass().getSimpleName();
    }
}

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

public class SelectBeanConfiguration {

    @LookupIfProperty(name = "service.alpha.enabled", stringValue = "true")
    @ApplicationScoped
    public TryLookupIfProperty tryLookupIfPropertyAlpha() {
        return new TryLookupIfPropertyAlpha();
    }

    @LookupIfProperty(name = "service.beta.enabled", stringValue = "true")
    @ApplicationScoped
    public TryLookupIfProperty tryLookupIfPropertyBeta() {
        return new TryLookupIfPropertyBeta();
    }
}

@QuarkusTest
public class BeanInstanceSwitchTest {

    @BeforeAll
    public static void setUp() {
        System.setProperty("service.alpha.enabled", "true");
    }

    // 注意，前面的LookupIfProperty不能决定注入bean是否实力话，只能决定Instance.get是否能取到，
    //所以此处要注入的是Instance，而不是TryLookupIfProperty本身
    @Inject
    Instance<TryLookupIfProperty> service;

    @Test
    public void testTryLookupIfProperty() {
        Assertions.assertEquals("from " + tryLookupIfPropertyAlpha.class.getSimpleName(),
                                service.get().hello());
    }
}

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

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

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

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

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

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

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

public interface TryIfBuildProfile {
    String hello();
}

public class TryIfBuildProfileProd implements TryIfBuildProfile {
    @Override
    public String hello() {
        return "from " + this.getClass().getSimpleName();
    }
}

public class TryIfBuildProfileDefault implements TryIfBuildProfile {
    @Override
    public String hello() {
        return "from " + this.getClass().getSimpleName();
    }
}

再来看IfBuildProfile的用法，在刚才的SelectBeanConfiguration.java中新增两个方法，如下所示，应用运行时，如果profile是test，那么tryIfBuildProfileProd方法会被执行，还要注意的是注解DefaultBean的用法，如果profile不是test，那么quarkus的bean容器中就没有TryIfBuildProfile类型的bean了，此时DefaultBean修饰的tryIfBuildProfileDefault方法就会被执行，导致TryIfBuildProfileDefault的实例注册在quarkus容器中
```
// 两者选择其一个执行
@Produces
@IfBuildProfile("test")
public TryIfBuildProfile tryIfBuildProfileProd() {
	return new TryIfBuildProfileProd();
}

@Produces
@DefaultBean
public TryIfBuildProfile tryIfBuildProfileDefault() {
	return new TryIfBuildProfileDefault();
}
 
```

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

@Inject
TryIfBuildProfile tryIfBuildProfile;

@Test
public void testTryLookupIfProperty() {
	Assertions.assertEquals("from " + TryLookupIfPropertyAlpha.class.getSimpleName(),
                            service.get().hello());
}

@Test
public void tryIfBuildProfile() {
	Assertions.assertEquals("from " + TryIfBuildProfileProd.class.getSimpleName(),
                tryIfBuildProfile.hello());
}

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

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

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

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

@Dependent
public class TracerConfiguration {

    @Produces
    @IfBuildProperty(name = "some.tracer.enabled", stringValue = "true")
    public Tracer realTracer(Reporter reporter, Configuration configuration) {
        return new RealTracer(reporter, configuration);
    }

    @Produces
    @DefaultBean
    public Tracer noopTracer() {
        return new NoopTracer();
    }
}

配置

请添加图片描述

@Path("/actions")
public class HobbyResource {

    @ConfigProperty(name = "greeting.message")
    String message;

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String hello() {
        return "Hello RESTEasy, " + LocalDateTime.now() + " [" + message + "]";
    }
}

配置方式一览

config sources

方式一：System properties

java -Dgreeting.message="from system properties" -jar hello-quarkus-1.0-SNAPSHOT-runner.jar

方式二：Environment variables

在设置环境变量时，要注意转换规则：全大写、点号变下划线，因此greeting.message在环境变量中应该写成GREETING_MESSAGE
打开控制台，执行以下命令，即可在当前会话中设置环境变量：

export GREETING_MESSAGE="from Environment variables"

方式三：.env file

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

GREETING_MESSAGE=from .env file

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

方式四：config目录下的application.properties

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

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

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

greeting.message=from config/application.properties

方式五：src/main/resources目录下的application.properties

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

方式六：MicroProfile Config configuration file

为了避免之前的操作带来的影响，请将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=from config/application.properties

配置内容：引用其他配置

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

greeting.name=Will
greeting.message=hello, ${greeting.name:xxxxxx}

配置内容：UUID

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

greeting.message=hello, ${quarkus.uuid}

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

配置内容：集合

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

my.collection=dog,cat,turtle

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

@Path("/actions")
public class HobbyResource {

    @ConfigProperty(name = "my.collection")
    List<String> message;

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String hello() {
        return "Hello RESTEasy, " + LocalDateTime.now() + ", " + message + "";
    }
}

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

my.collection[0]=dog
my.collection[1]=cat,turtle
my.collection[2]=turtle

使用配置

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

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

最基本的配置

greeting.message = hello from application.properties

@ConfigProperty(name = "greeting.message") 
  String message;

配置项不存在导致的异常

带默认值的配置

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

@Path("/actions")
public class HobbyResource {

    // 配置文件中不存在名为not.exists.config的配置项
    @ConfigProperty(name = "not.exists.config", defaultValue = "112233")
    String notExistsConfig;

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String hello() {
        return "Hello RESTEasy, " + LocalDateTime.now() + ", [" + notExistsConfig + "]";
    }
}

defaultValue属性的自动转换

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

在这里插入图片描述

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

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

// 配置文件中不存在名为not.exists.config的配置项
@ConfigProperty(name = "not.exists.config", defaultValue = "123")
int notExistsConfig;

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

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

@ConfigProperty(name = "server.address", defaultValue = "192.168.1.1")
InetAddress serverAddress;

如果ConfigProperty修饰的变量是boolean型，或者Boolean型，则defaultValue值的自动转换逻辑有些特别： “true”, “1”, “YES”, “Y” "ON"这些都会被转为true(而且不区分大小写，"on"也被转为true)，其他值会被转为false
还有一处要注意的：defaultValue的值如果是空字符串，就相当于没有设置defaultValue，此时如果在配置文件中没有该配置项，启动应用会报错

支持Optional

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

@Path("/actions")
public class HobbyResource {

    // 配置文件中存在名为greeting.message的配置项
    @ConfigProperty(name = "greeting.message")
    String message;

    // 配置文件中，不论是否存在名为optional.message的配置项，应用都不会抛出异常
    @ConfigProperty(name = "optional.message")
    Optional<String> optionalMessage;

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String hello() {
        List<String> list = new ArrayList<>();
        list.add(message);

        // 只有配置项optional.message存在的时候，才会执行list.add方法
        optionalMessage.ifPresent(list::add);

        return "Hello RESTEasy, " + LocalDateTime.now() + ", " + list;
    }
}

编码获取配置项

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

@Path("/actions")
public class HobbyResource {

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String hello() {
        List<String> list = new ArrayList<>();

        // 可以用静态方法取得Config实例
        Config config = ConfigProvider.getConfig();

        // getValue可取得指定配置项的指定类型值
        String greet = config.getValue("greeting.message", String.class);

        list.add(greet);

        // getOptionalValue可以将配置项的值包状为Optional对象，如果配置项不存在，也不会报错
        Optional<String> optional = config.getOptionalValue("not.exists.config", String.class);

        // 函数式编程：只用optional中有对象时，才会执行list.add方法
        optional.ifPresent(list::add);

        return "Hello RESTEasy, " + LocalDateTime.now() + ", " + list;
    }
}

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

配置接口

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

student.name=Tom
student.age=11
student.description=He is a good boy

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

@ConfigMapping(prefix = "student")
public interface StudentConfiguration {
    /**
     * 名字与配置项一致
     * @return
     */
    String name();

    /**
     * 名字与配置项一致，自动转为int型
     * @return
     */
    int age();

    /**
     * 名字与配置项不一致时，用WithName注解指定配置项
     * @return
     */
    @WithName("description")
    String desc();

    /**
     * 用WithDefault注解设置默认值，如果配置项"student.favorite"不存在，则默认值生效
     * @return
     */
    @WithDefault("default from code")
    String favorite();
}


 /// 这个好强

配置项是多个单词时，如何对应配置接口的方法？

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

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

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

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

@ConfigMapping(prefix = "student", namingStrategy = ConfigMapping.NamingStrategy.SNAKE_CASE)
public interface StudentConfiguration {
    /**
     * 名字与配置项一致
     * @return
     */
    String name();
    ...

配置接口嵌套

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

student.name=Tom
student.age=11
student.description=He is a good boy

student.address.province=guangdong
student.address.city=shenzhen

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

public interface Address {
    String province();
    String city();
}

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

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

配置项转为map

前面的接口嵌套，虽然将多层级的配置以对象的形式清晰的表达出来，但也引出一个问题：配置越多，接口定义或者接口方法就越多，代码随之增加
如果配置项的层级简单，还有种简单的方式将其映射到配置接口中：转为map
```
student.address.province=guangdong
student.address.city=shenzhen
```
对应的代码改动如下图，只要把address方法的返回值从Address改为Map<String, String>即可，这样修改后，address层级下面再增加配置项，也不用修改配置项有关的代码了：

内置配置项

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

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

上述文档中，有很多配置项带有加锁的图标，如下图红框所示，有这个图标的配置项，其值在应用构建的时候已经固定了，在应用运行期间始终保持只读状态

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

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

profile

设定profile

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

# 这个配置信息在各个环境中都是相同的
quarkus.profile=dev

# 如果不指定profile，就使用此配置
quarkus.http.port=8080

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

java -Dquarkus.profile="dev" -jar hello-quarkus-1.0-SNAPSHOT-runner.jar

同一个配置项在不同profile时的值

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

# 指定当前profile
quarkus.profile=dev

# 这个配置信息在各个环境中都是相同的
greeting.message=hello

# 如果profile为dev，就是用此配置
%dev.quarkus.http.port=8081
# 如果profile为production，就是用此配置
%production.quarkus.http.port=8082
# 如果不指定profile，或者profile既不是dev也不是production，就使用此配置
quarkus.http.port=8080

需要大写的场景

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

# 这个配置信息在各个环境中都是相同的
GREETING_MESSAGE=hello

# 如果profile为dev，就是用此配置
_DEV_QUARKUS_HTTP_PORT=8081

# 如果profile为production，就是用此配置
_PRODUCTION_QUARKUS_HTTP_PORT=8082

# 如果不指定profile，就使用此配置
QUARKUS_HTTP_PORT=8080

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

java -Dquarkus.profile=dev -jar hello-quarkus-1.0-SNAPSHOT-runner.jar

不指定profile时的默认值

不指定profile的时候，quarkus会给profile设置默认值，有三种可能：dev、test、prod，具体逻辑如下：
```
  如果启动命令是mvn quarkus:dev，profile等于dev，如下图，大家应该见过多次了：
```

在这里插入图片描述

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

在这里插入图片描述

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

在这里插入图片描述

每个profile对应一个配置文件

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

resources
├── META-INF
│   └── resources
│       └── index.html
├── application-staging.properties
└── application.properties

application.properties内容如下

shell
复制代码greeting.message=hello
quarkus.http.port=8080

application-staging.properties内容如下

shell
复制代码greeting.message=hello
quarkus.http.port=8081

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

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

Parent Profile

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

# 指定profile的名字
quarkus.profile=dev
# 指定parent的名字
quarkus.config.profile.parent=common

%common.quarkus.http.port=9090
%dev.quarkus.http.ssl-port=9443

quarkus.http.port=8080
quarkus.http.ssl-port=8443

当前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

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

mvn clean package -U -Dquarkus.package.type=uber-jar -Dquarkus.profile=prod-aws

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

三个关键注意事项（重要）

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

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

io.quarkus.runtime.configuration.ProfileManager#getActiveProfile

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

@ConfigProperty("quarkus.profile")
 String profile;

quarkus核心编程笔记

依赖注入

修饰符匹配

Named注解的属性匹配

根据优先级选择

写代码注入bean

拦截器

定义和使用拦截器的操作介绍

拦截构造方法

获取被拦截方法的参数

多个拦截器之间传递参数

发布订阅模式

同步事件

异步事件

同一种事件类，用在不同的业务场景

小优化，不需要注入多个Event实例

事件元数据

生命周期回调

拦截器模式

自定义模式

dispose注解：实现销毁前自定义操作，dispose是另一种可选方案

装饰器（Decorator）

重要知识点

bean读写锁

学习和改变bean懒加载规则

关于懒加载（Lazy Instantiation

编码验证懒加载

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

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

总结

拦截器高级特性（属性设置和重复使用）

禁用类级别拦截器

类拦截器和方法拦截器的叠加效果

用注解NoClassInterceptors使类拦截器失效

其他重要知识点大串讲

简化之一：bean注入

简化之二：bean构造方法

简化之三：bean生产方法

WithCaching注解：避免不必要的多次实例化

拦截静态方法

All更加直观的注入

统一处理异步事件的异常

小点回顾补充

CDI

创建bean实例：注解修饰在类上

创建bean实例：注解修饰在方法上

创建bean实例：注解修饰在成员变量上

关于synthetic bean

quarkus依赖注入之二：bean的作用域

关于bean的作用域（scope）

常规作用域和伪作用域

ApplicationScoped

RequestScoped

SessionScoped

Singleton

Dependent

用注解选择注入bean

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

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

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

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

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

配置

配置方式一览

方式一：System properties

方式二：Environment variables

方式三：.env file

方式四：config目录下的application.properties

方式五：src/main/resources目录下的application.properties

方式六：MicroProfile Config configuration file

配置内容：常规

配置内容：引用其他配置

配置内容：UUID

配置内容：集合

使用配置

最基本的配置

配置项不存在导致的异常

带默认值的配置

defaultValue属性的自动转换

支持Optional