使用了Synchronized，竟然還有線程安全問題！
本文轉(zhuǎn)載自微信公眾號(hào)「程序新視界」，作者丑胖俠二師兄。轉(zhuǎn)載本文請聯(lián)系程序新視界公眾號(hào)。
實(shí)戰(zhàn)中受過的傷，才能領(lǐng)悟的更透徹，二師兄帶你分析實(shí)戰(zhàn)案例。
線程安全問題一直是系統(tǒng)亙古不變的痛點(diǎn)。這不，最近在項(xiàng)目中發(fā)了一個(gè)錯(cuò)誤使用線程同步的案例。表面上看已經(jīng)使用了同步機(jī)制，一切歲月靜好，但實(shí)際上線程同步卻毫無作用。
關(guān)于線程安全的問題，基本上就是在挖坑與填坑之間博弈，這也是為什么面試中線程安全必不可少的原因。下面，就來給大家分析一下這個(gè)案例。
有隱患的代碼
先看一個(gè)脫敏的代碼實(shí)例。代碼要處理的業(yè)務(wù)邏輯很簡單，就是多線程訪問一個(gè)單例對象的成員變量，對其進(jìn)行自增處理。
SyncTest類實(shí)現(xiàn)了Runnable接口，run方法中處理業(yè)務(wù)邏輯。在run方法中通過synchronized來保證線程安全問題，在main方法中創(chuàng)建一個(gè)SyncTest類的對象，兩個(gè)線程同時(shí)操作這一個(gè)對象。
- public class SyncTest implements Runnable {
- private Integer count = 0;
- @Override
- public void run() {
- synchronized (count) {
- System.out.println(new Date() + " 開始休眠" + Thread.currentThread().getName());
- count++;
- try {
- Thread.sleep(10000);
- System.out.println(new Date() + " 結(jié)束休眠" + Thread.currentThread().getName());
- } catch (InterruptedException e) {
- e.printStackTrace();
- }
- }
- }
- public static void main(String[] args) throws InterruptedException {
- SyncTest test = new SyncTest();
- new Thread(test).start();
- Thread.sleep(100);
- new Thread(test).start();
- }
- }
在上述代碼中，兩個(gè)線程訪問SyncTest的同一個(gè)對象，并對該對象的count屬性進(jìn)行自增操作。由于是多線程，那就要保證count++的線程安全。
代碼中使用了synchronized來鎖定代碼塊，進(jìn)行同步處理。為了演示效果，在處理完業(yè)務(wù)邏輯對線程進(jìn)行睡眠。
理想的狀況是第一個(gè)線程執(zhí)行完畢，然后第二個(gè)線程才能進(jìn)入并執(zhí)行。
表面上看，一切都很完美，下面我們來執(zhí)行一下程序看看結(jié)果。
執(zhí)行驗(yàn)證
執(zhí)行main方法打印結(jié)果如下：
- Fri Jul 23 22:10:34 CST 2021 開始休眠Thread-0
- Fri Jul 23 22:10:34 CST 2021 開始休眠Thread-1
- Fri Jul 23 22:10:44 CST 2021 結(jié)束休眠Thread-0
- Fri Jul 23 22:10:45 CST 2021 結(jié)束休眠Thread-1
正常來說，由于使用了synchronized來進(jìn)行同步處理，那么第一個(gè)線程進(jìn)入run方法之后，會(huì)進(jìn)行鎖定。先執(zhí)行“開始休眠”，然后再執(zhí)行“結(jié)束休眠”，最后釋放鎖之后，第二個(gè)線程才能夠進(jìn)入。
但分析上面的日志，會(huì)發(fā)現(xiàn)兩個(gè)線程同時(shí)進(jìn)入了“開始休眠”狀態(tài)，也就是說鎖并未起效，線程安全依舊存在問題。下面我們就針對synchronized失效原因進(jìn)行逐步分析。
synchronized知識(shí)回顧
在分析原因之前，我們先來回顧一下synchronized關(guān)鍵字的使用。
synchronized關(guān)鍵字解決并發(fā)問題時(shí)通常有三種使用方式：
同步普通方法，鎖的是當(dāng)前對象;
同步靜態(tài)方法，鎖的是當(dāng)前Class對象;
同步塊，鎖的是()中的對象;
很顯然，上面的場景中，使用的是第三種方式進(jìn)行鎖定處理。
synchronized實(shí)現(xiàn)同步的過程是：JVM通過進(jìn)入、退出對象監(jiān)視器(Monitor)來實(shí)現(xiàn)對方法、同步塊的同步的。
代碼在編譯時(shí)，編譯器會(huì)在同步方法調(diào)用前加入一個(gè)monitor.enter指令，在退出方法和異常處插入monitor.exit的指令。其本質(zhì)就是對一個(gè)對象監(jiān)視器(Monitor)進(jìn)行獲取，而這個(gè)獲取過程具有排他性從而達(dá)到了同一時(shí)刻只能一個(gè)線程訪問的目的。
原因分析
經(jīng)過上面基礎(chǔ)知識(shí)的鋪墊，我們就來排查分析一下上述代碼的問題。其實(shí)，對于這個(gè)問題，IDE已經(jīng)能夠給出提示了。
如果你使用的IDE帶有代碼檢查的插件，synchronized (count)的count上會(huì)有如下提示：
Synchronization on a non-final field 'xxx' Inspection info: Reports synchronized statements where the lock expression is a reference to a non-final field. Such statements are unlikely to have useful semantics, as different threads may be locking on different objects even when operating on the same object.
很多人可能會(huì)忽視掉這個(gè)提示，但它已經(jīng)明確指出此處代碼有線程安全問題。提示的核心是“同步處理應(yīng)用在了非final修飾的變量上”。
對于synchronized關(guān)鍵字來說，如果加鎖的對象是一個(gè)可變的對象，那么當(dāng)這個(gè)變量的引用發(fā)生了改變，不同的線程可能鎖定不同的對象，進(jìn)而都會(huì)成功獲得各自的鎖。
用一個(gè)圖來回顧一下上述過程：
在上圖中，Thread0在①處進(jìn)行了鎖定，但鎖定的對象是Integer(0);Thread1中②處也進(jìn)行鎖定，但此時(shí)count已經(jīng)進(jìn)行自增，導(dǎo)致Thread1鎖定的是對象Integer(1);也就是說，兩個(gè)線程鎖定的對象不是同一個(gè)，也就無法保證線程安全了。
解決方案
既然找到了問題的原因，我們就可以有針對性的進(jìn)行解決，這里用的count屬性很顯然不可能用final進(jìn)行修飾，不然就無法進(jìn)行自增處理。這里我們采用對象鎖的方式來進(jìn)行處理，也就鎖對象為當(dāng)前this或者說是當(dāng)前類的實(shí)例對象。修改之后的代碼如下：
- public class SyncTest implements Runnable {
- private Integer count = 0;
- @Override
- public void run() {
- synchronized (this) {
- System.out.println(new Date() + " 開始休眠" + Thread.currentThread().getName());
- count++;
- try {
- Thread.sleep(10000);
- System.out.println(new Date() + " 結(jié)束休眠" + Thread.currentThread().getName());
- } catch (InterruptedException e) {
- e.printStackTrace();
- }
- }
- }
- // ...
- }
在上述代碼中鎖定了當(dāng)前對象，而當(dāng)前對象在這個(gè)示例中是同一個(gè)SyncTest的對象。
再次執(zhí)行main方法，打印日志如下：
- Fri Jul 23 23:13:55 CST 2021 開始休眠Thread-0
- Fri Jul 23 23:14:05 CST 2021 結(jié)束休眠Thread-0
- Fri Jul 23 23:14:05 CST 2021 開始休眠Thread-1
- Fri Jul 23 23:14:15 CST 2021 結(jié)束休眠Thread-1
可以看到，第一個(gè)線程完全執(zhí)行完畢之后，第二個(gè)線程才進(jìn)行執(zhí)行，達(dá)到預(yù)期的同步處理目標(biāo)。
上面鎖定當(dāng)前對象還是有一個(gè)小缺點(diǎn)，大家在使用時(shí)需要注意：比如該類有其他方法也使用了synchronized (this)，那么由于兩個(gè)方法鎖定的都是當(dāng)前對象，其他方法也會(huì)進(jìn)行阻塞。所以通常情況下，建議每個(gè)方法鎖定各自定義的對象。
比如，單獨(dú)定義一個(gè)private的變量，然后進(jìn)行鎖定：
- public class SyncTest implements Runnable {
- private Integer count = 0;
- private final Object locker = new Object();
- @Override
- public void run() {
- synchronized (locker) {
- System.out.println(new Date() + " 開始休眠" + Thread.currentThread().getName());
- count++;
- try {
- Thread.sleep(10000);
- System.out.println(new Date() + " 結(jié)束休眠" + Thread.currentThread().getName());
- } catch (InterruptedException e) {
- e.printStackTrace();
- }
- }
- }
- }
synchronized使用小常識(shí)
在使用synchronized時(shí)，我們首先要搞清楚它鎖定的是哪個(gè)對象，這能幫助我們設(shè)計(jì)更安全的多線程程式。
在使用和設(shè)計(jì)鎖時(shí)，我們還要了解一下知識(shí)點(diǎn)：
- 對象建議定義為private的，然后通過getter方法訪問。而不是定義為public/protected，否則外界能夠繞過同步方法的控制而直接取得對象并改變它。這也是JavaBean的標(biāo)準(zhǔn)實(shí)現(xiàn)方式之一。
- 當(dāng)鎖定對象為數(shù)組或ArrayList等類型時(shí)，getter方法獲得的對象仍可以被改變，這時(shí)就需要將get方法也加上synchronized同步，并且只返回這個(gè)private對象的clone()。這樣，調(diào)用端得到的就是對象副本的引用了。
- 無論synchronized關(guān)鍵字加在方法上還是對象上，取得的鎖都是對象，而不是把一段代碼或函數(shù)當(dāng)作鎖。同步方法很可能還會(huì)被其他線程的對象訪問;
- 每個(gè)對象只有一個(gè)鎖(lock)和之相關(guān)聯(lián);
- 實(shí)現(xiàn)同步是要很大的系統(tǒng)開銷作為代價(jià)的，甚至可能造成死鎖，所以盡量避免無謂的同步控制;
小結(jié)
通過本文的實(shí)踐案例主要為大家輸出兩個(gè)關(guān)鍵點(diǎn)：第一，不要忽視IDE對代碼的提示信息，某些提示真的很有用，如果深挖還能發(fā)現(xiàn)很多性能問題或代碼bug;第二，對于多線程的運(yùn)用，不僅要全面了解相關(guān)的基礎(chǔ)知識(shí)點(diǎn)，還需要盡可能的進(jìn)行壓測，這樣才能讓問題事先暴露出來。
