關于bean的作用域（scope）

• 官方資料：https://lordofthejars.github.io/quarkus-cheat-sheet/#_injection
• 上一篇《quarkus依賴注入之一：創建bean》
• 作為《quarkus依賴注入》系列的第二篇，繼續學習一個重要的知識點：bean的作用域（scope），每個bean的作用域是唯一的，不同類型的作用域，決定了各個bean實例的生命周期，例如：何時何處創建，又何時何處銷毀。
• bean的作用域在代碼中是什么樣的？回顧前文的代碼，如下，ApplicationScoped就是作用域，表明bean實例以單例模式一直存活（只要應用還存活著），這是業務開發中常用的作用域類型：

@ApplicationScoped
public class ClassAnnotationBean {

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

• 作用域有多種，如果按來源區分一共兩大類：quarkus內置和擴展組件中定義，本篇聚焦quarkus的內置作用域
• 下面是整理好的作用域一覽，接下來會逐個講解。

常規作用域和偽作用域

• 常規作用域，quarkus官方稱之為normal scope，包括：ApplicationScoped、RequestScoped、SessionScoped三種。
• 偽作用域稱之為pseudo scope，包括：Singleton、RequestScoped、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是何時被實例化的？有以下兩種可能：

1. 第一種：ClassAnnotationController被實例化的時候，classAnnotationBean會被注入，這時ClassAnnotationBean被實例化。
2. 第二種：get方法第一次被調用的時候，classAnnotationBean真正發揮作用，這時ClassAnnotationBean被實例化。

• 所以，一共有兩個時間點：注入時和get方法首次執行時，作用域不同，這兩個時間點做的事情也不同，下面用表格來解釋。

• 至此，您應該明白兩種作用域的區別了：偽作用域的bean，在注入的時候實例化，常規作用域的bean，在注入的時候并未實例化，只有它的方法首次執行的時候才會實例化，如下圖：

• 接下來細看每個作用域。

ApplicationScoped

• ApplicationScoped算是最常用的作用域了，它修飾的bean，在整個應用中只有一個實例。

RequestScoped

• 這是與當前http請求綁定的作用域，它修飾的bean，在每次http請求時都有一個全新實例，來寫一段代碼驗證。
• 首先是bean類RequestScopeBean.java，注意作用域是RequestScoped，如下，在構造方法中打印日志，這樣可以通過日志行數知道實例化次數。

package com.bolingcavalry.service.impl;

import io.quarkus.logging.Log;
import javax.enterprise.context.RequestScoped;

@RequestScoped
public class RequestScopeBean {

    /**
     * 在構造方法中打印日志，通過日志出現次數對應著實例化次數
     */
    public RequestScopeBean() {
        Log.info("Instance of " + this.getClass().getSimpleName());
    }

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

• 然后是使用bean的代碼，是個普通的web服務類。

package com.bolingcavalry;

import com.bolingcavalry.service.impl.RequestScopeBean;
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;
import java.time.LocalDateTime;

@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次。

package com.bolingcavalry;

import com.bolingcavalry.service.impl.RequestScopeBean;
import io.quarkus.test.junit.QuarkusTest;
import org.junit.jupiter.api.RepeatedTest;
import org.junit.jupiter.api.Test;

import static io.restassured.RestAssured.given;
import static org.hamcrest.CoreMatchers.containsString;

@QuarkusTest
class RequestScopeControllerTest {

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

• 由于單元測試中接口會調用10次，按照RequestScoped作用域的定義，RequestScopeBean會實例化10次，執行單元測試試試吧。
• 執行結果如下圖，紅框4顯示每次http請求都會觸發一次RequestScopeBean實例化，符合預期，另外還有意外收獲，稍后馬上就會提到。

• 另外，請重點關注藍框和藍色注釋文字，這是意外收獲，居然看到了代理類的日志，看樣子代理類是繼承了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，會空指針異常的。

• 運行代碼驗證是否有代理類，找到剛才的RequestScopeBean.java，將作用域改成Singleton，運行單元測試類RequestScopeControllerTest.java，結果如下圖紅框，只有RequestScopeBean自己構造方法的日志。

• 再將作用域改成ApplicationScoped，如下圖藍框，代理類日志出現。

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一模一樣，就不貼出來了。
• 最后寫個單元測試類驗證HelloDependent的特殊能力。

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

• 運行單元測試，如下圖紅框，首先，HelloDependent的日志打印了兩次，證明的確實例化了兩個HelloDependent對象，其次日志的內容也準確的將注入點的類的信息打印出來。

擴展組件的作用域

• quarkus的擴展組件豐富多彩，自己也能按照官方指引制作，所以擴展組件對應的作用域也隨著組件的不同而各不相同，就不在此列舉了，就舉一個例子吧：quarkus-narayana-jta組件中定義了一個作用域javax.transaction.TransactionScoped，該作用域修飾的bean，每個事物對應一個實例。
• 至此，quarkus作用域的了解和實戰已經完成，這樣一來，不論是使用bean還是創建bean，都能按業務需要來準確控制其生命周期了。