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

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

誰還沒在 Spring 裏栽過跟頭呢，從哪兒跌倒，就從哪兒睡一下子，而後再爬起來。git

講點兒武德

這是由一個真實的 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是不肯定的。github

getCallback方法每次調用，會隨機生成一個100之內的數字，而後將 callback中的{token}替換爲這個隨機數字，最後的格式就像這樣的：redis

https://ip.com/token=88

而後在 main方法中接收控制檯輸入，每次輸入的數字大於0，調用 getCallback方法，而後輸出 url。數據庫

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

執行程序以後，無論你輸入多少次數字，最後輸出的 callback都是第一次的那個。設計模式

雖然每次生成的隨機數都變了，可是 callback沒變。微信

其實就是單例

有同窗說，你過度了啊，這我能不知道爲啥嗎？app

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 中存的是沒問題的，能夠正常使用。

那完全排除是定時任務的問題了，問題的癥結應該就出在兩個地方：

一、在獲取 redis 中的access_token的過程；

二、將獲取到的 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 殺手，擅長解決問題。一個兼具深度與廣度的程序員鼓勵師，本打算寫詩卻寫起了代碼的田園碼農！堅持原創乾貨輸出，你可選擇如今就關注我，或者看看歷史文章再關注也不遲。長按二維碼關注，跟我一塊兒變優秀！