寫了個(gè)全局變量的bug,被同事們打臉!!!

Java技術(shù)棧

www.javastack.cn

關(guān)注閱讀更多優(yōu)質(zhì)文章

話說棧長(zhǎng)前陣子寫了一個(gè)功能，測(cè)試 0 bug 就上線了，上線后也運(yùn)行好好的，好多天都沒有人反饋bug，超爽。。

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

最近有個(gè)客戶反饋某些數(shù)據(jù)混亂問題，看代碼死活看不出什么問題，很詭異，再仔細(xì)看代碼，原來是一個(gè)全局變量的問題，導(dǎo)致在并發(fā)情況下出現(xiàn)了線程不安全的問題，事后被同事們打臉！?。?/p>

慎用全局變量，我在公司一直在強(qiáng)調(diào)，沒想到這么低級(jí)的問題居然發(fā)生在自己身上，說起來真的慚愧啊。。

最開始使用的是 Spring 注入對(duì)象的方式：

@Autowired
private?Object?object;

因?yàn)?Spring 默認(rèn)是單例，所以這樣寫是沒有問題的，后來隨著業(yè)務(wù)的發(fā)展，需要多個(gè)不同的業(yè)務(wù)實(shí)例，我改成了這種方式：

@Setter
private?Object?object;

這個(gè) @Setter 是 Lombok 的注解，用來生成 setters 方法，現(xiàn)在想起來，真是低級(jí)啊，同時(shí)操作的情況下，這個(gè)對(duì)象肯定會(huì)出現(xiàn)覆蓋的情況，從而導(dǎo)致上面說的問題。

寫了一個(gè)這么低級(jí)bug，我也不怕不好意思發(fā)出來，大家都謹(jǐn)記一下吧。

另外，我再總結(jié)幾個(gè)慎用全局變量的場(chǎng)景：

1、SimpleDateFormat

SimpleDateFormat 禁止定義成 static 變量或者全局共享變量，因?yàn)樗蔷€程不安全的，都被寫進(jìn)阿里巴巴的《Java開發(fā)手冊(cè)》里了：

最新的完整版可以關(guān)注公眾號(hào)：Java技術(shù)棧，回復(fù) "手冊(cè)" 獲取。

為什么說 SimpleDateFormat 不是線程安全的呢？

來看下它的 format 方法源碼：

可以看到 calendar 變量居然也是全局變量，多線程情況下就會(huì)存在設(shè)置臟變量的情況。

所以，如果要用 SimpleDateFormat，就在每次用的時(shí)候都創(chuàng)建一個(gè) SimpleDateFormat 對(duì)象，做到線程間隔離。

2、資源連接

資源連接包括數(shù)據(jù)庫(kù)連接、FTP連接、Redis連接等，這種也要慎用全局變量，一旦使用全局變量，就會(huì)遇到以下問題：

1）關(guān)閉連接的時(shí)候，就可能把別人正在操作的連接給關(guān)了，導(dǎo)致其他線程的業(yè)務(wù)中斷；

2）因?yàn)槭侨肿兞?，?chuàng)建的時(shí)候可能會(huì)創(chuàng)建多個(gè)實(shí)例，在關(guān)閉連接的時(shí)候，就可能只關(guān)閉了一個(gè)對(duì)象的連接，造成其他連接沒有被關(guān)閉，最后導(dǎo)致連接耗光系統(tǒng)不可用；

3、數(shù)字運(yùn)算

這也是個(gè)很經(jīng)典的問題了，如果要用多線程對(duì)一個(gè)數(shù)字進(jìn)行累加等其他運(yùn)算處理，千萬不要用全局基礎(chǔ)類型的變量，如下所示：

private?long?count;

多線程情況下，某個(gè)線程獲取到的值可能已經(jīng)被其他線程修改了，最后得到的值就不準(zhǔn)確了。

當(dāng)然，上面的示例可以通過加鎖的方式來解決，也可以使用全局的原子類（java.util.concurrent.atomic.Atom*）進(jìn)行處理，比如：

private?AtomicInteger?count?=?new?AtomicInteger();

注意，這種原子類使用全局變量就沒有線程安全的問題，它使用了 CAS 算法保證了數(shù)據(jù)一致性。

不過，阿里推薦使用LongAdder，因?yàn)樾阅芨茫?/p>

java.util.concurrent.atomic.LongAdder

4、全局session

來看下面的例子：

@Autowired
protected?HttpSession?session;

全局注入一個(gè) Session 對(duì)象，在 Spring 中，這樣全局注入使用上面是默認(rèn)沒問題的，包括 request, response 對(duì)象，都可以通過全局注入來獲取。

這樣會(huì)存在線程安全性嗎？

不會(huì)！

使用這種方式，當(dāng) Bean 初始化時(shí)，Spring 并沒有注入真實(shí)對(duì)象，而是注入了一個(gè)代理對(duì)象，真正使用的時(shí)候通過該代理對(duì)象獲取真正的對(duì)象。

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

具體就不展開了，詳細(xì)的介紹及測(cè)試大家可以點(diǎn)擊這個(gè)鏈接查看這篇文章。

既然是線程安全，但也得小心，如果我在方法中主動(dòng)使 session 對(duì)象失效并重建了：

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

這樣，session對(duì)象就變成了真實(shí)對(duì)象了，不再是代理對(duì)象，就變成了文章最開始的時(shí)候我說的那種多線程安全問題了，如果線上出現(xiàn) session 會(huì)話混亂，用戶 A 就可能看到用戶 B 的數(shù)據(jù)，你想想可不可怕？

所以，即使可以這樣使用，也得千萬小心謹(jǐn)慎，最好是在方法級(jí)別使用這些對(duì)象。

總結(jié)

今天，棧長(zhǎng)總結(jié)了一下我是怎么寫出這個(gè)全局變量的低級(jí) bug，也總結(jié)了下慎用全局變量的 4 種情況，相信大家多多少都遇到過類似的問題，希望能幫助大家少踩坑。

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

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

關(guān)注公眾號(hào)，棧長(zhǎng)陸續(xù)分享更多好玩得Java技術(shù)~最近熱文：1、Java 14 祭出神器，Lombok 被干掉了？2、一周面試了 30 人，面到我心態(tài)爆炸…3、求求你們別再寫滿屏的 try catch 了！4、阿里發(fā)布《Java開發(fā)手冊(cè)（泰山版）》
5、推薦一款 IDEA 代碼神器，再也不加班了！6、微信、淘寶類掃碼登錄是怎么實(shí)現(xiàn)的？7、Spring Boot 2.3 優(yōu)雅關(guān)閉新姿勢(shì)，真香！8、Redis 到底是單線程還是多線程？
9、我天！xx.equals(null) 是什么騷操作？？
10、Struts2 為什么被淘汰？自己作死！掃碼關(guān)注Java技術(shù)棧公眾號(hào)閱讀更多干貨。

點(diǎn)擊「閱讀原文」帶你飛～