归去来兮★

quarkus核心编程笔记

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

大佬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();
    }
}

发布订阅模式

同步事件

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

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类型的事件，消费者应该是处理普通用户事件的方法，简单的说就是同一个数据结构的事件可能用在不同场景，如下图

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

此刻，您是否回忆起前面文章中的一个场景：依赖注入时，如何从多个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 [email protected]
 * @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生命周期的不同阶段，都可以触发自定义代码的执行

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

拦截器模式

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

如果要自定义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 [email protected]
 * @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

@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 {
```

总结

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

先定义三个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是不同的实例

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 + "]";
    }
}

配置方式一览

方式一：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即可，这样修改后，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;