天天看點

寫了個全局變量的bug,被同僚們打臉!!!

話說棧長前陣子寫了一個功能,測試 0 bug 就上線了,上線後也運作好好的,好多天都沒有人回報bug,超爽。。

不出問題還好,出問題就是大問題。。

最近有個客戶回報某些資料混亂問題,看代碼死活看不出什麼問題,很詭異,再仔細看代碼,原來是一個全局變量的問題,導緻在并發情況下出現了線程不安全的問題,事後被同僚們打臉!!!

慎用全局變量,我在公司一直在強調,沒想到這麼低級的問題居然發生在自己身上,說起來真的慚愧啊。。

最開始使用的是 Spring 注入對象的方式:

@Autowired
private Object object;      

因為 Spring 預設是單例,是以這樣寫是沒有問題的,後來随着業務的發展,需要多個不同的業務執行個體,我改成了這種方式:

@Setter
private Object object;      

這個 @Setter 是 Lombok 的注解,用來生成 setters 方法,現在想起來,真是低級啊,同時操作的情況下,這個對象肯定會出現覆寫的情況,進而導緻上面說的問題。

寫了一個這麼低級bug,我也不怕不好意思發出來,大家都謹記一下吧。

另外,我再總結幾個慎用全局變量的場景:

1、SimpleDateFormat

SimpleDateFormat 禁止定義成 static 變量或者全局共享變量,因為它是線程不安全的,都被寫進阿裡巴巴的《Java開發手冊》裡了:

寫了個全局變量的bug,被同僚們打臉!!!

最新的完整版可以關注公衆号:Java技術棧,回複 "手冊" 擷取。

為什麼說 SimpleDateFormat 不是線程安全的呢?

來看下它的 format 方法源碼:

寫了個全局變量的bug,被同僚們打臉!!!

可以看到 calendar 變量居然也是全局變量,多線程情況下就會存在設定髒變量的情況。

是以,如果要用 SimpleDateFormat,就在每次用的時候都建立一個 SimpleDateFormat 對象,做到線程間隔離。

2、資源連接配接

資源連接配接包括資料庫連接配接、FTP連接配接、Redis連接配接等,這種也要慎用全局變量,一量使用全局變量,就會遇到以下問題:

1)關閉連接配接的時候,就可能把别人正在操作的連接配接給關了,導緻其他線程的業務中斷;

2)因為是全局變量,建立的時候可能會建立多個執行個體,在關閉連接配接的時候,就可能隻關閉了一個對象的連接配接,造成其他連接配接沒有被關閉,最後導緻連接配接耗光系統不可用;

3、數字運算

這也是個很經典的問題了,如果要用多線程對一個數字進行累加等其他運算處理,千萬不要用全局基礎類型的變量,如下所示:

private long count;      

多線程情況下,某個線程擷取到的值可能已經被其他線程修改了,最後得到的值就不準确了。

當然,上面的示例可以通過加鎖的方式來解決,也可以使用全局的原子類(java.util.concurrent.atomic.Atom*)進行處理,比如:

private AtomicInteger count = new AtomicInteger();      

注意,這種原子類使用全局變量就沒有線程安全的問題,它使用了 CAS 算法保證了資料一緻性。

不過,阿裡推薦使用LongAdder,因為性能更好:

java.util.concurrent.atomic.LongAdder

寫了個全局變量的bug,被同僚們打臉!!!

4、全局session

來看下面的例子:

@Autowired
protected HttpSession session;      

全局注入一個 Session 對象,在 Spring 中,這樣全局注入使用上面是預設沒問題的,包括 request, response 對象,都可以通過全局注入來擷取。

這樣會存線上程安全性嗎?

不會!

使用這種方式,當 Bean 初始化時,Spring 并沒有注入真實對象,而是注入了一個代理對象,真正使用的時候通過該代理對象擷取真正的對象。

并且,在注入此類對象時,Spring使用了線程局部變量(ThreadLocal),這就保證了 request/response/session 對象的線程安全性了。

具體就不展開了,詳細的介紹及測試大家可以點選這個連結檢視這篇文章。

既然是線程安全,但也得小心,如果我在方法中主動使 session 對象失效并重建了:

session.invalidate();
session = request.getSession();      

這樣,session對象就變成了真實對象了,不再是代理對象,就變成了文章最開始的時候我說的那種多線程安全問題了,如果線上出現 session 會話混亂,使用者 A 就可能看到使用者 B 的資料,你想想可不可怕?

是以,即使可以這樣使用,也得千萬小心謹慎,最好是在方法級别使用這些對象。

總結

今天,棧長總結了一下我是怎麼寫出這個全局變量的低級 bug,也總結了下慎用全局變量的 4 種情況,相信大家多多少都遇到過類似的問題,希望能幫助大家少踩坑。

全局變量雖好,但我們也得謹慎使用啊,一定要考慮是否引起多線程安全問題,不然會引起重大問題。

你還遇到過哪些全局變量的問題,歡迎留言分享哦!