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

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

這是由乙個真實的 bug 引起的，bug 產生的原因就是忽略了 spring bean 的單例模式。來，先看一段簡單的**。

public class testservice ";
public string getcallback() ", string.valueof(number));
return callback;
}public static void main(string args) }}
}

callback是乙個帶有乙個**位址，引數token是不確定的。

getcallback方法每次呼叫，會隨機生成乙個100以內的數字，然後將callback中的替換為這個隨機數字，最後的格式就像這樣的：

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

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

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

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

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

main方法只建立了乙個testservice例項，在第一次呼叫getcallback方法的時候，callback這個字串就被修改成了，所以，之後不管你再呼叫多少次，都不會執行replace動作了，因為callback中已經沒有這一段了。

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

callback.replace("", string.valueof(number));

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

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

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

弟弟第一時間懷疑是定時任務出現了問題，但是通過日誌和資料庫中的更新時間，發現定時任務是完全沒有問題的，重新整理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
public class testcontroller 
}@service
public class testservice ";
public string getcallback() ", string.valueof(number));
return callback;}}

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

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

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

如何解決這個問題呢？

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

public string getcallback() ", string.valueof(number));
return tempcallback;
}

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

@restcontroller
@scope(value = "prototype")
public class testcontroller 
}@service
@scope(value = "prototype")
public class testservice ";
public string getcallback() ", string.valueof(number));
return callback;}}

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

看完就懂的 spring ioc 實現過程

從 spring boot 出發，分析 spring ioc 過程

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

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

JPA 這個功能差點讓我丟了工作！

這個世界欠我的，我遲早讓加倍償還！

但願有人看到這個讓我失眠的問題！

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

JPA 這個功能差點讓我丟了工作！

這個世界欠我的，我遲早讓加倍償還！

但願有人看到這個讓我失眠的問題！

相關推薦