[[412969]]

本文轉(zhuǎn)載自微信公眾號「程序新視界」，作者丑胖俠二師兄。轉(zhuǎn)載本文請聯(lián)系程序新視界公眾號。

實戰(zhàn)中受過的傷，才能領(lǐng)悟的更透徹，二師兄帶你分析實戰(zhàn)案例。

線程安全問題一直是系統(tǒng)亙古不變的痛點。這不，最近在項目中發(fā)了一個錯誤使用線程同步的案例。表面上看已經(jīng)使用了同步機制，一切歲月靜好，但實際上線程同步卻毫無作用。

關(guān)于線程安全的問題，基本上就是在挖坑與填坑之間博弈，這也是為什么面試中線程安全必不可少的原因。下面，就來給大家分析一下這個案例。

有隱患的代碼

先看一個脫敏的代碼實例。代碼要處理的業(yè)務邏輯很簡單，就是多線程訪問一個單例對象的成員變量，對其進行自增處理。

SyncTest類實現(xiàn)了Runnable接口，run方法中處理業(yè)務邏輯。在run方法中通過synchronized來保證線程安全問題，在main方法中創(chuàng)建一個SyncTest類的對象，兩個線程同時操作這一個對象。

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(); 
    } 
} 

在上述代碼中，兩個線程訪問SyncTest的同一個對象，并對該對象的count屬性進行自增操作。由于是多線程，那就要保證count++的線程安全。

代碼中使用了synchronized來鎖定代碼塊，進行同步處理。為了演示效果，在處理完業(yè)務邏輯對線程進行睡眠。

理想的狀況是第一個線程執(zhí)行完畢，然后第二個線程才能進入并執(zhí)行。

表面上看，一切都很完美，下面我們來執(zhí)行一下程序看看結(jié)果。

執(zhí)行驗證

執(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來進行同步處理，那么第一個線程進入run方法之后，會進行鎖定。先執(zhí)行“開始休眠”，然后再執(zhí)行“結(jié)束休眠”，最后釋放鎖之后，第二個線程才能夠進入。

但分析上面的日志，會發(fā)現(xiàn)兩個線程同時進入了“開始休眠”狀態(tài)，也就是說鎖并未起效，線程安全依舊存在問題。下面我們就針對synchronized失效原因進行逐步分析。

synchronized知識回顧

在分析原因之前，我們先來回顧一下synchronized關(guān)鍵字的使用。

synchronized關(guān)鍵字解決并發(fā)問題時通常有三種使用方式：

同步普通方法，鎖的是當前對象;

同步靜態(tài)方法，鎖的是當前Class對象;

同步塊，鎖的是()中的對象;

很顯然，上面的場景中，使用的是第三種方式進行鎖定處理。

synchronized實現(xiàn)同步的過程是：JVM通過進入、退出對象監(jiān)視器(Monitor)來實現(xiàn)對方法、同步塊的同步的。

代碼在編譯時，編譯器會在同步方法調(diào)用前加入一個monitor.enter指令，在退出方法和異常處插入monitor.exit的指令。其本質(zhì)就是對一個對象監(jiān)視器(Monitor)進行獲取，而這個獲取過程具有排他性從而達到了同一時刻只能一個線程訪問的目的。

原因分析

經(jīng)過上面基礎(chǔ)知識的鋪墊，我們就來排查分析一下上述代碼的問題。其實，對于這個問題，IDE已經(jīng)能夠給出提示了。

如果你使用的IDE帶有代碼檢查的插件，synchronized (count)的count上會有如下提示：

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.

很多人可能會忽視掉這個提示，但它已經(jīng)明確指出此處代碼有線程安全問題。提示的核心是“同步處理應用在了非final修飾的變量上”。

對于synchronized關(guān)鍵字來說，如果加鎖的對象是一個可變的對象，那么當這個變量的引用發(fā)生了改變，不同的線程可能鎖定不同的對象，進而都會成功獲得各自的鎖。

用一個圖來回顧一下上述過程：

在上圖中，Thread0在①處進行了鎖定，但鎖定的對象是Integer(0);Thread1中②處也進行鎖定，但此時count已經(jīng)進行自增，導致Thread1鎖定的是對象Integer(1);也就是說，兩個線程鎖定的對象不是同一個，也就無法保證線程安全了。

解決方案

既然找到了問題的原因，我們就可以有針對性的進行解決，這里用的count屬性很顯然不可能用final進行修飾，不然就無法進行自增處理。這里我們采用對象鎖的方式來進行處理，也就鎖對象為當前this或者說是當前類的實例對象。修改之后的代碼如下：

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(); 
            } 
        } 
    } 
    // ... 
} 

在上述代碼中鎖定了當前對象，而當前對象在這個示例中是同一個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 

可以看到，第一個線程完全執(zhí)行完畢之后，第二個線程才進行執(zhí)行，達到預期的同步處理目標。

上面鎖定當前對象還是有一個小缺點，大家在使用時需要注意：比如該類有其他方法也使用了synchronized (this)，那么由于兩個方法鎖定的都是當前對象，其他方法也會進行阻塞。所以通常情況下，建議每個方法鎖定各自定義的對象。

比如，單獨定義一個private的變量，然后進行鎖定：

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使用小常識

在使用synchronized時，我們首先要搞清楚它鎖定的是哪個對象，這能幫助我們設(shè)計更安全的多線程程式。

在使用和設(shè)計鎖時，我們還要了解一下知識點：

• 對象建議定義為private的，然后通過getter方法訪問。而不是定義為public/protected，否則外界能夠繞過同步方法的控制而直接取得對象并改變它。這也是JavaBean的標準實現(xiàn)方式之一。
• 當鎖定對象為數(shù)組或ArrayList等類型時，getter方法獲得的對象仍可以被改變，這時就需要將get方法也加上synchronized同步，并且只返回這個private對象的clone()。這樣，調(diào)用端得到的就是對象副本的引用了。
• 無論synchronized關(guān)鍵字加在方法上還是對象上，取得的鎖都是對象，而不是把一段代碼或函數(shù)當作鎖。同步方法很可能還會被其他線程的對象訪問;
• 每個對象只有一個鎖(lock)和之相關(guān)聯(lián);
• 實現(xiàn)同步是要很大的系統(tǒng)開銷作為代價的，甚至可能造成死鎖，所以盡量避免無謂的同步控制;

小結(jié)

通過本文的實踐案例主要為大家輸出兩個關(guān)鍵點：第一，不要忽視IDE對代碼的提示信息，某些提示真的很有用，如果深挖還能發(fā)現(xiàn)很多性能問題或代碼bug;第二，對于多線程的運用，不僅要全面了解相關(guān)的基礎(chǔ)知識點，還需要盡可能的進行壓測，這樣才能讓問題事先暴露出來。