作為Java并發(fā)編程中最基礎(chǔ)的同步機制，synchronized看似簡單直接，只需在方法或代碼塊上加上關(guān)鍵字，就能確保線程安全。然而，這種表面的簡單背后，卻隱藏著諸多陷阱。

在我十年的Java開發(fā)生涯中，親眼目睹過無數(shù)由synchronized使用不當導致的系統(tǒng)災(zāi)難：從莫名其妙的數(shù)據(jù)錯亂，到令人頭痛的性能瓶頸，再到那些讓整個團隊通宵排查的神秘死鎖。這些問題往往在開發(fā)環(huán)境中難以復(fù)現(xiàn)，卻在生產(chǎn)環(huán)境中肆意妄為，給業(yè)務(wù)帶來嚴重影響。

今天，我將揭開synchronized使用中最常見的三個問題，通過真實案例幫助你徹底理解這些陷阱，并掌握對應(yīng)的解決方案。

一、鎖對象與被保護資源不匹配

準備在開發(fā)一個多線程計數(shù)器服務(wù)，需要讓多個線程安全地遞增同一個計數(shù)器，使用synchronized關(guān)鍵字來保護共享資源。

public class CounterService {
    private int counter = 0;
    
    public void incrementCounter() {
        // 每次調(diào)用都創(chuàng)建新的鎖對象
        Object lock = new Object();
        synchronized(lock) {
            counter++;  // 看似加鎖，實際無保護效果
        }
    }
    
    public int getCounter() {
        return counter;
    }
}

在修改counter時使用了synchronized塊。然而，實際運行時發(fā)現(xiàn)計數(shù)器的值非常混亂，與預(yù)期完全不符。

問題就在于鎖對象的選擇上。

在這段代碼中，每次調(diào)用incrementCounter()方法都會創(chuàng)建一個全新的lock對象。這就好比每個人進入同一個房間時都帶著自己的鑰匙，而不是使用同一把鑰匙來控制入口 - 自然無法起到互斥的作用！

要解決這個問題，我們需要確保所有線程使用相同的鎖對象：

public class CounterService {
    private int counter = 0;
    private final Object lock = new Object(); // 使用一個一致的鎖對象
    
    public void incrementCounter() {
        synchronized(lock) {
            counter++;
        }
    }
    
    public int getCounter() {
        synchronized(lock) { // 讀取操作也需要加鎖
            return counter;
        }
    }
}

所有線程現(xiàn)在都是使用同一個“l(fā)ock對象”來控制對計數(shù)器的訪問。對讀取操作加了鎖，這確保了讀取操作能夠看到其他線程的最新修改，解決了可見性問題。

在實際項目中，這種改進可能看起來微小，但卻能徹底解決由于鎖選擇不當導致的競態(tài)條件，在并發(fā)環(huán)境下避免出錯。

二、鎖粒度選擇不當

隨著用戶量增長，需要開發(fā)了一個緩存系統(tǒng)來提高性能，這個系統(tǒng)需要允許多個線程同時讀寫不同的緩存項。

public class SimpleCache<K, V> {
    private Map<K, V> cache = new HashMap<>();
    
    public V get(K key) {
        synchronized(this) { // 對整個對象加鎖
            return cache.get(key);
        }
    }
    
    public void put(K key, V value) {
        synchronized(this) { // 對整個對象加鎖
            cache.put(key, value);
        }
    }
}

這段代碼確實是線程安全的，但隨著系統(tǒng)負載增加，你會發(fā)現(xiàn)性能開始急劇下降。用戶開始抱怨系統(tǒng)響應(yīng)緩慢，監(jiān)控顯示CPU利用率不高，但吞吐量卻很低。

在代碼中，我們對整個緩存對象加鎖，導致即使線程操作的是不同的鍵值對，也必須排隊等待，這就是所謂的"粗粒度鎖"問題。

解決方案是使用更細粒度的鎖設(shè)計，或者直接使用Java并發(fā)包中專門設(shè)計的并發(fā)集合：

public class ImprovedCache<K, V> {
    // 使用支持并發(fā)的集合
    private final ConcurrentHashMap<K, V> cache = new ConcurrentHashMap<>();
    
    public V get(K key) {
        return cache.get(key);
    }
    
    public void put(K key, V value) {
        cache.put(key, value);
    }
    
    // 對于需要原子性的復(fù)合操作
    public V putIfAbsent(K key, V value) {
        return cache.putIfAbsent(key, value);
    }
}

這樣的改進就像是將超市改造成多個入口，顧客可以直接進入自己想去的區(qū)域。ConcurrentHashMap內(nèi)部實現(xiàn)了分段鎖機制，不同的鍵可能映射到不同的鎖，大大提高了并發(fā)處理能力。

在實際項目中，這種優(yōu)化可能會將系統(tǒng)的并發(fā)吞吐量提升數(shù)倍甚至數(shù)十倍。特別是在微服務(wù)架構(gòu)中，一個看似小的鎖優(yōu)化可能會對整個系統(tǒng)的響應(yīng)時間產(chǎn)生顯著影響。在高并發(fā)環(huán)境中，細粒度鎖往往是性能提升的關(guān)鍵。

三、多鎖導致的死鎖問題

在銀行系統(tǒng)中，用戶可以在不同賬戶之間轉(zhuǎn)移資金。一個直觀的實現(xiàn)可能是這樣的：

public class BankAccount {
    private double balance;
    private final String accountId;
    
    public BankAccount(String accountId, double initialBalance) {
        this.accountId = accountId;
        this.balance = initialBalance;
    }
    
    public void transfer(BankAccount to, double amount) {
        synchronized(this) { // 先鎖住當前賬戶
            if (balance >= amount) {
                synchronized(to) { // 再鎖住目標賬戶
                    this.balance -= amount;
                    to.balance += amount;
                }
            }
        }
    }
}

這段代碼看起來合理，先鎖住源賬戶確認余額充足，再鎖住目標賬戶完成轉(zhuǎn)賬。然而，在測試過程中，你可能會偶然發(fā)現(xiàn)系統(tǒng)有時會完全卡住，沒有任何錯誤日志，應(yīng)用程序也沒有崩潰，但就是停止響應(yīng)了。

這正是臭名昭著的死鎖問題。

想象兩個顧客A和B各自持有一把鑰匙，且都需要兩把鑰匙才能完成操作。如果A拿著鑰匙1等鑰匙2，而B拿著鑰匙2等鑰匙1，他們將永遠等待下去。在我們的代碼中，當兩個線程同時嘗試在兩個賬戶之間相互轉(zhuǎn)賬時：

• 線程1執(zhí)行：accountA.transfer(accountB, 100)，鎖住了accountA，等待accountB的鎖
• 同時，線程2執(zhí)行：accountB.transfer(accountA, 50)，鎖住了accountB，等待accountA的鎖

兩個線程都無法繼續(xù)執(zhí)行，形成了死鎖，系統(tǒng)陷入了永久等待狀態(tài)。

解決這個問題需要一個巧妙的策略，讓所有線程以相同的順序獲取鎖：

public class SafeBankAccount {
    private double balance;
    private final String accountId;
    
    public SafeBankAccount(String accountId, double initialBalance) {
        this.accountId = accountId;
        this.balance = initialBalance;
    }
    
    public void transfer(SafeBankAccount to, double amount) {
        SafeBankAccount first = this;
        SafeBankAccount second = to;
        
        // 根據(jù)賬戶ID確定鎖的獲取順序，防止死鎖
        if (this.accountId.compareTo(to.accountId) > 0) {
            first = to;
            second = this;
        }
        
        synchronized(first) {
            synchronized(second) {
                if (this.balance >= amount) {
                    this.balance -= amount;
                    to.balance += amount;
                }
            }
        }
    }
}

這種解決方案就像是制定了一個規(guī)則：不管誰先到，都必須按照賬戶ID的字典順序獲取鎖。這樣，所有線程都遵循相同的獲取鎖順序，從根本上避免了死鎖的可能性。

在實際項目中，這種鎖順序策略可以防止系統(tǒng)出現(xiàn)難以排查的死鎖問題，大大提高了系統(tǒng)的穩(wěn)定性和可靠性。特別是在金融系統(tǒng)中，這種穩(wěn)定性至關(guān)重要。值得注意的是，這種解決方案不僅保持了轉(zhuǎn)賬操作的原子性，還巧妙地避免了死鎖風險。

四、正確使用synchronized

1.鎖對象與資源的匹配問題

確保鎖對象與被保護資源有明確的對應(yīng)關(guān)系，并且在所有線程間共享同一把鎖。就像一個房間只能用一把鑰匙控制進入一樣。

2.鎖粒度的選擇問題

根據(jù)性能需求選擇合適的鎖粒度。粗粒度鎖實現(xiàn)簡單但并發(fā)度低，細粒度鎖并發(fā)度高但復(fù)雜度增加。在高并發(fā)系統(tǒng)中，恰當?shù)逆i粒度設(shè)計常常是性能優(yōu)化的關(guān)鍵。

3.建立一致的鎖獲取順序

當系統(tǒng)中需要多個鎖時，制定明確的鎖獲取規(guī)則，所有線程按照相同的順序獲取鎖，從根本上避免死鎖風險。

4.根據(jù)系統(tǒng)需求選擇合適的鎖粒度

在保證線程安全的前提下，盡可能使用細粒度鎖來提高系統(tǒng)并發(fā)性能。在高并發(fā)場景下，考慮使用ConcurrentHashMap等并發(fā)集合類來替代簡單的synchronized塊。

五、總結(jié)

本文深入探討了Java開發(fā)中使用synchronized可能遇到的三個典型問題及其解決方案。

在Java并發(fā)編程中，正確使用synchronized可以保證線程安全，但使用不當則會引發(fā)各種問題。開發(fā)者需要確保鎖對象與資源的正確對應(yīng)、選擇合適的鎖粒度、制定一致的鎖獲取順序，才能構(gòu)建既安全又高效的多線程應(yīng)用。這些看似簡單的原則，卻是解決多線程編程中大多數(shù)復(fù)雜問題的基礎(chǔ)。