當前位置:聯(lián)升科技 > 技術資訊 > 開發(fā)技術 >

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

2020-11-09    作者:Java技術棧    來源:今日頭條    閱讀:
話說棧長前陣子寫了一個功能,測試 0 bug 就上線了,上線后也運行好好的,好多天都沒有人反饋bug,超爽。。
不出問題還好,出問題就是大問題。。
最近有個客戶反饋某些數(shù)據(jù)混亂問題,看代碼死活看不出什么問題,很詭異,再仔細看代碼,原來是一個全局變量的問題,導致在并發(fā)情況下出現(xiàn)了線程不安全的問題,事后被同事們打臉!!!
慎用全局變量,我在公司一直在強調(diào),沒想到這么低級的問題居然發(fā)生在自己身上,說起來真的慚愧啊。。
最開始使用的是 Spring 注入對象的方式:
@Autowired 
private Object object; 
因為 Spring 默認是單例,所以這樣寫是沒有問題的,后來隨著業(yè)務的發(fā)展,需要多個不同的業(yè)務實例,我改成了這種方式:
@Setter 
private Object object; 
這個 @Setter 是 Lombok 的注解,用來生成 setters 方法,現(xiàn)在想起來,真是低級啊,同時操作的情況下,這個對象肯定會出現(xiàn)覆蓋的情況,從而導致上面說的問題。
寫了一個這么低級bug,我也不怕不好意思發(fā)出來,大家都謹記一下吧。
另外,我再總結幾個慎用全局變量的場景:
1、SimpleDateFormat
SimpleDateFormat 禁止定義成 static 變量或者全局共享變量,因為它是線程不安全的,都被寫進阿里巴巴的《Java開發(fā)手冊》里了:

寫了個全局變量的bug,被同事們打臉
最新的完整版可以點擊文末下面的了解更多鏈接關注:Java技術棧,回復 “手冊” 獲取。
為什么說 SimpleDateFormat 不是線程安全的呢?
來看下它的 format 方法源碼:
寫了個全局變量的bug,被同事們打臉

可以看到 calendar 變量居然也是全局變量,多線程情況下就會存在設置臟變量的情況。
所以,如果要用 SimpleDateFormat,就在每次用的時候都創(chuàng)建一個 SimpleDateFormat 對象,做到線程間隔離。
2、資源連接
資源連接包括數(shù)據(jù)庫連接、FTP連接、Redis連接等,這種也要慎用全局變量,一量使用全局變量,就會遇到以下問題:
關閉連接的時候,就可能把別人正在操作的連接給關了,導致其他線程的業(yè)務中斷;
因為是全局變量,創(chuàng)建的時候可能會創(chuàng)建多個實例,在關閉連接的時候,就可能只關閉了一個對象的連接,造成其他連接沒有被關閉,最后導致連接耗光系統(tǒng)不可用;
3、數(shù)字運算
這也是個很經(jīng)典的問題了,如果要用多線程對一個數(shù)字進行累加等其他運算處理,千萬不要用全局基礎類型的變量,如下所示:
private long count; 
多線程情況下,某個線程獲取到的值可能已經(jīng)被其他線程修改了,最后得到的值就不準確了。
當然,上面的示例可以通過加鎖的方式來解決,也可以使用全局的原子類(java.util.concurrent.atomic.Atom*)進行處理,比如:
private AtomicInteger count = new AtomicInteger(); 
注意,這種原子類使用全局變量就沒有線程安全的問題,它使用了 CAS 算法保證了數(shù)據(jù)一致性。
不過,阿里推薦使用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對象就變成了真實對象了,不再是代理對象,就變成了文章最開始的時候我說的那種多線程安全問題了,如果線上出現(xiàn) session 會話混亂,用戶 A 就可能看到用戶 B 的數(shù)據(jù),你想想可不可怕?
所以,即使可以這樣使用,也得千萬小心謹慎,最好是在方法級別使用這些對象。
總結
今天,棧長總結了一下我是怎么寫出這個全局變量的低級 bug,也總結了下慎用全局變量的 4 種情況,相信大家多多少都遇到過類似的問題,希望能幫助大家少踩坑。
全局變量雖好,但我們也得謹慎使用啊,一定要考慮是否引起多線程安全問題,不然會引起重大問題。


相關文章

我們很樂意傾聽您的聲音!
即刻與我們?nèi)〉寐?lián)絡
成為日后肩并肩合作的伙伴。

行業(yè)資訊

聯(lián)系我們

13387904606

地址:新余市仙女湖區(qū)仙女湖大道萬商紅A2棟

手機:13755589003
QQ:122322500
微信號:13755589003

江西新余網(wǎng)站設計_小程序制作_OA系統(tǒng)開發(fā)_企業(yè)ERP管理系統(tǒng)_app開發(fā)-新余聯(lián)升網(wǎng)絡科技有限公司 贛ICP備19013599號-1   贛公網(wǎng)安備 36050202000267號   

微信二維碼