這個 bug 讓我更加理解 Spring 單例了

風的姿態發表於2020-12-22

我是風箏,公眾號「古時的風箏」,一個兼具深度與廣度的程式設計師鼓勵師,一個本打算寫詩卻寫起了程式碼的田園碼農!
文章會收錄在 JavaNewBee 中,更有 Java 後端知識圖譜,從小白到大牛要走的路都在裡面。

誰還沒在 Spring 裡栽過跟頭呢,從哪兒跌倒,就從哪兒睡一會兒,然後再爬起來。

講點兒武德

這是由一個真實的 bug 引起的,bug 產生的原因就是忽略了 Spring Bean 的單例模式。來,先看一段簡單的程式碼。

public class TestService {
    
    private String callback = "https://ip.com/token={token}";

    public String getCallback() {
        Random random = new Random();
        int number = random.nextInt(100);
        System.out.println("本次隨機數為:" + number);
        callback = callback.replace("{token}", String.valueOf(number));
        return callback;
    }


    public static void main(String[] args) {
        TestService testService = new TestService();
        while (true) {
            Scanner reader = new Scanner(System.in);
            int number = reader.nextInt();
            if (number > 0) {
                String url = testService.getCallback();
                System.out.println(url);
            }
        }
    }
}

callback是一個帶有一個回撥地址,引數 token是不確定的。

getCallback方法每次呼叫,會隨機生成一個100以內的數字,然後將 callback中的{token}替換為這個隨機數字,最後的格式就像這樣的:

https://ip.com/token=88

然後在 main方法中接收控制檯輸入,每次輸入的數字大於0,呼叫 getCallback方法,然後輸出 url。

相信各位都能輕易的看出這段程式的輸出。

執行程式之後,不管你輸入多少次數字,最後輸出的 callback都是第一次的那個。

雖然每次生成的隨機數都變了,但是 callback沒變。

其實就是單例

有同學說,你過分了啊,這我能不知道為啥嗎?

main方法只建立了一個TestService例項,在第一次呼叫 getCallback方法的時候,callback這個字串就被修改成 https://ip.com/token=89了,所以,之後不管你再呼叫多少次,都不會執行 replace動作了,因為 callback中已經沒有 {token}這一段了。

TestService 在整個程式執行過程中就是一個單例,所以,在 callback第一次被修改後,後面再執行

callback.replace("{token}", String.valueOf(number));

的動作,拿到的 callback中就已經沒有 {token}了,所以說,不會有替換的動作。

當然,這只是用最簡單的程式說明單例中的這個問題,真正的專案中想用單例的話,還要藉助於單例設計模式實現。

回到那個 bug

有個弟弟在做微信服務號的開發,微信服務號或者訂閱號中有個 access_token的概念,這是所有請求的憑證,有效期 2 個小時,到期之前要進行重新整理。

他是這樣設計的,在專案啟動的時候立即呼叫微信介面獲取 access_token,然後寫了一個定時任務每1個小時重新整理一次,獲取來的 access_token放到 redis 和 資料庫中,當呼叫微信服務號其他介面的時候,在 redis 中獲取 access_token並拼接到介面地址中。

開發除錯的時候一起順利,看上去非常完美。

問題出現了

當專案部署到測試環境測試的時候,問題出現了。專案剛發版的時候,測試都正常,但是過一段時間,就會出現錯誤,檢視日誌的時候,發現是微信服務號的介面返回了錯誤碼,意思就是 access_token已過期,需要重新獲取。

弟弟第一時間懷疑是定時任務出現了問題,但是通過日誌和資料庫中的更新時間,發現定時任務是完全沒有問題的,重新整理 access_token的時間和定時任務是完全吻合的,說明已經及時重新整理了。

我讓他用 redis 或資料庫中的access_token去調一下服務號介面,看看是不是也有同樣的過期問題。

結果一試,redis 中存的是沒問題的,可以正常使用。

那徹底排除是定時任務的問題了,問題的癥結應該就出在兩個地方:

1、在獲取 redis 中的access_token的過程;

2、將獲取到的 access_token拼接到請求介面 URL 上發生了錯誤;

到這裡就很好判斷了,他把從 redis 拿到的access_token和最後拼接好的 URL 都輸出到日誌中一看,果然,兩個是不一致的。

從 redis 取出的確實是最新可用的 access_token ,但是拼接到介面 URL 上之後,發現是另外一個。那就確定是拿到的 access_token 是沒問題的,但是最後拼接到 URL 卻有問題。這時,弟弟仔細檢查了程式碼,然後徹底蒙了。

講點武德

既然問題出在哪兒已經確定了,那就分析那段程式碼就好了。

專案整體採用的是 Spring Boot,程式碼很簡單,就是在一個 Controller 中呼叫 Service 中的一個方法。大致 demo 是這樣的。

@RestController
@RequestMapping(value = "test")
public class TestController {

    @Autowired
    private TestService testService;

    @GetMapping(value = "call")
    public Object getCallback() {
        return testService.getCallback();
    }
}

@Service
public class TestService {

    private String callback = "https://ip.com/token={token}";

    public String getCallback() {
        Random random = new Random();
        int number = random.nextInt(100);
        System.out.println("本次隨機數為:" + number);
        callback = callback.replace("{token}", String.valueOf(number));
        return callback;
    }
}  

看到這裡,各位肯定已經發現問題原因了。雖然有多次請求,但因為 Spring Bean 預設是單例模式,所以實際上和前面演示的那個控制檯程式是類似的,從頭到尾都只有一個 TestService 例項,所以只有第一次能將{token}替換成真正的access_token

對應到實際的服務號場景中,在第一次呼叫這個介面時,從 redis 拿到 access_token拼接到具體的 URL中是沒問題的,但是一旦這個access_token過期(1小時後),再次請求這個介面就會出現 access_token過期的問題。

這裡違反了 Spring 單例模式的一個點,那就是 Spring 單例模式,不適合儲存有狀態的值,比如這裡的 callback就是個有狀態的值,它應該隨著定時任務的進行,獲取到不同的值。

關於 Spring 或 Spring Boot 工作流程的介紹可以閱讀文末的兩篇文章,其中包括 Bean 例項化過程。

修改建議

如何解決這個問題呢?

其實很簡單,不讓callback每次呼叫發生變化就可以了,每次拼接 URL 的時候,先將 callback賦給一個區域性變數,然後在這個變數上操作就好了。

public String getCallback() {
  Random random = new Random();
  int number = random.nextInt(100);
  System.out.println("本次隨機數為:" + number);
  String tempCallback = callback;
  tempCallback = tempCallback.replace("{token}", String.valueOf(number));
  return tempCallback;
}

另外,說到 Spring 單例模式,Spring 本身還支援其他幾種模式,與單例模式對應的就是 prototype模式,這種模式是每個請求都重新生成例項。所以,如果你確定這個 Controller 和 Service 可以不用單例模式,可以加上 @Scope(value = "prototype")註解。

@RestController
@RequestMapping(value = "test")
@Scope(value = "prototype")
public class TestController {

    @Autowired
    private TestService testService;

    @GetMapping(value = "call")
    public Object getCallback() {
        return testService.getCallback();
    }
}

@Service
@Scope(value = "prototype")
public class TestService {

    private String callback = "https://ip.com/token={token}";

    public String getCallback() {
        Random random = new Random();
        int number = random.nextInt(100);
        System.out.println("本次隨機數為:" + number);
        callback = callback.replace("{token}", String.valueOf(number));
        return callback;
    }
}

這樣一來,每次都是新的例項,自然就不存在那個問題了。

看完就懂的 Spring IoC 實現過程

從 Spring Boot 出發,分析 Spring IoC 過程


這位英俊瀟灑的少年,如果覺得還不錯的話,給個推薦可好!

公眾號「古時的風箏」,Java 開發者,全棧工程師,bug 殺手,擅長解決問題。
一個兼具深度與廣度的程式設計師鼓勵師,本打算寫詩卻寫起了程式碼的田園碼農!堅持原創乾貨輸出,你可選擇現在就關注我,或者看看歷史文章再關注也不遲。長按二維碼關注,跟我一起變優秀!

相關文章