寫出高性能Java代碼，使用Synchronized的三個關鍵問題全解析
作為Java并發編程中最基礎的同步機制，synchronized看似簡單直接，只需在方法或代碼塊上加上關鍵字，就能確保線程安全。然而，這種表面的簡單背后，卻隱藏著諸多陷阱。
在我十年的Java開發生涯中，親眼目睹過無數由synchronized使用不當導致的系統災難：從莫名其妙的數據錯亂，到令人頭痛的性能瓶頸，再到那些讓整個團隊通宵排查的神秘死鎖。這些問題往往在開發環境中難以復現，卻在生產環境中肆意妄為，給業務帶來嚴重影響。
今天，我將揭開synchronized使用中最常見的三個問題，通過真實案例幫助你徹底理解這些陷阱，并掌握對應的解決方案。
一、鎖對象與被保護資源不匹配
準備在開發一個多線程計數器服務，需要讓多個線程安全地遞增同一個計數器，使用synchronized關鍵字來保護共享資源。
public class CounterService {
private int counter = 0;
public void incrementCounter() {
// 每次調用都創建新的鎖對象
Object lock = new Object();
synchronized(lock) {
counter++; // 看似加鎖，實際無保護效果
}
}
public int getCounter() {
return counter;
}
}在修改counter時使用了synchronized塊。然而，實際運行時發現計數器的值非常混亂，與預期完全不符。
問題就在于鎖對象的選擇上。
在這段代碼中，每次調用incrementCounter()方法都會創建一個全新的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;
}
}
}所有線程現在都是使用同一個“lock對象”來控制對計數器的訪問。對讀取操作加了鎖，這確保了讀取操作能夠看到其他線程的最新修改，解決了可見性問題。
在實際項目中，這種改進可能看起來微小，但卻能徹底解決由于鎖選擇不當導致的競態條件，在并發環境下避免出錯。
二、鎖粒度選擇不當
隨著用戶量增長，需要開發了一個緩存系統來提高性能，這個系統需要允許多個線程同時讀寫不同的緩存項。
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);
}
}
}這段代碼確實是線程安全的，但隨著系統負載增加，你會發現性能開始急劇下降。用戶開始抱怨系統響應緩慢，監控顯示CPU利用率不高，但吞吐量卻很低。
在代碼中，我們對整個緩存對象加鎖，導致即使線程操作的是不同的鍵值對，也必須排隊等待，這就是所謂的"粗粒度鎖"問題。
解決方案是使用更細粒度的鎖設計，或者直接使用Java并發包中專門設計的并發集合：
public class ImprovedCache<K, V> {
// 使用支持并發的集合
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);
}
// 對于需要原子性的復合操作
public V putIfAbsent(K key, V value) {
return cache.putIfAbsent(key, value);
}
}這樣的改進就像是將超市改造成多個入口，顧客可以直接進入自己想去的區域。ConcurrentHashMap內部實現了分段鎖機制，不同的鍵可能映射到不同的鎖，大大提高了并發處理能力。
在實際項目中，這種優化可能會將系統的并發吞吐量提升數倍甚至數十倍。特別是在微服務架構中，一個看似小的鎖優化可能會對整個系統的響應時間產生顯著影響。在高并發環境中，細粒度鎖往往是性能提升的關鍵。
三、多鎖導致的死鎖問題
在銀行系統中，用戶可以在不同賬戶之間轉移資金。一個直觀的實現可能是這樣的：
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;
}
}
}
}
}這段代碼看起來合理，先鎖住源賬戶確認余額充足，再鎖住目標賬戶完成轉賬。然而，在測試過程中，你可能會偶然發現系統有時會完全卡住，沒有任何錯誤日志，應用程序也沒有崩潰，但就是停止響應了。
這正是臭名昭著的死鎖問題。
想象兩個顧客A和B各自持有一把鑰匙，且都需要兩把鑰匙才能完成操作。如果A拿著鑰匙1等鑰匙2，而B拿著鑰匙2等鑰匙1，他們將永遠等待下去。在我們的代碼中，當兩個線程同時嘗試在兩個賬戶之間相互轉賬時：
- 線程1執行：accountA.transfer(accountB, 100)，鎖住了accountA，等待accountB的鎖
- 同時，線程2執行：accountB.transfer(accountA, 50)，鎖住了accountB，等待accountA的鎖
兩個線程都無法繼續執行，形成了死鎖，系統陷入了永久等待狀態。
解決這個問題需要一個巧妙的策略，讓所有線程以相同的順序獲取鎖：
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;
// 根據賬戶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;
}
}
}
}
}這種解決方案就像是制定了一個規則：不管誰先到，都必須按照賬戶ID的字典順序獲取鎖。這樣，所有線程都遵循相同的獲取鎖順序，從根本上避免了死鎖的可能性。
在實際項目中，這種鎖順序策略可以防止系統出現難以排查的死鎖問題，大大提高了系統的穩定性和可靠性。特別是在金融系統中，這種穩定性至關重要。值得注意的是，這種解決方案不僅保持了轉賬操作的原子性，還巧妙地避免了死鎖風險。
四、正確使用synchronized
1.鎖對象與資源的匹配問題
確保鎖對象與被保護資源有明確的對應關系，并且在所有線程間共享同一把鎖。就像一個房間只能用一把鑰匙控制進入一樣。
2.鎖粒度的選擇問題
根據性能需求選擇合適的鎖粒度。粗粒度鎖實現簡單但并發度低，細粒度鎖并發度高但復雜度增加。在高并發系統中，恰當的鎖粒度設計常常是性能優化的關鍵。
3.建立一致的鎖獲取順序
當系統中需要多個鎖時，制定明確的鎖獲取規則，所有線程按照相同的順序獲取鎖，從根本上避免死鎖風險。
4.根據系統需求選擇合適的鎖粒度
在保證線程安全的前提下，盡可能使用細粒度鎖來提高系統并發性能。在高并發場景下，考慮使用ConcurrentHashMap等并發集合類來替代簡單的synchronized塊。
五、總結
本文深入探討了Java開發中使用synchronized可能遇到的三個典型問題及其解決方案。
在Java并發編程中，正確使用synchronized可以保證線程安全，但使用不當則會引發各種問題。開發者需要確保鎖對象與資源的正確對應、選擇合適的鎖粒度、制定一致的鎖獲取順序，才能構建既安全又高效的多線程應用。這些看似簡單的原則，卻是解決多線程編程中大多數復雜問題的基礎。
