怎樣提高 java 中鎖的性能

兩個月前向Plumbr公司引進線程死鎖的檢測之後，我們開始收到一些類似於這樣的詢問：「棒極了！現在我知道造成程式出現效能問題的原因了，但是接下來該怎麼做呢？ 、縮小鎖的作用範圍，這幾種技術可以使我們不使用任何工具來偵測死鎖。

鎖不是問題的根源，鎖之間的競爭才是

通常在多執行緒的程式碼中遇到效能方面的問題時，一般都會抱怨是鎖的問題。畢竟鎖會降低程式的運行速度和其較低的擴展性是眾所周知的。因此，如果帶著這種「常識」開始優化程式碼，其結果很有可能是在之後會出現討人喜歡的並發問題。

因此，明白競爭鎖和非競爭鎖的差異是非常重要的。當一個執行緒試圖進入 另一個執行緒正在執行的同步區塊或方法時會觸發鎖定競爭。該執行緒會被強制進入等待狀態，直到第一個執行緒執行完同步區塊並且已經釋放了監視器。當同一時間只有一個線 程嘗試執行同步的程式碼區域時，鎖定會保持非競爭的狀態。

事實上，在非競爭的情況下和大多數的應用中，JVM已經對同步進行了最佳化。非競爭鎖在執行過程中不會帶來任何額外的開銷。因此，你不應該因為性能問題抱怨鎖，應該抱怨的是鎖的競爭。當有了這個體認之後，讓我們來看看能做些什麼，以降低競爭的可能性或減少競爭的持續時間。

保護資料而非程式碼

解決執行緒安全問題的一個快速的方法是對整個方法的可訪問性加鎖。例如下面這個例子，試圖透過這個方法來建立一個線上撲克遊戲伺服器：

class GameServer {  
      public Map<<String, List<Player>> tables = new HashMap<String, List<Player>>();  
      public synchronized void join(Player player, Table table) {    
         if (player.getAccountBalance() > table.getLimit()) {
                List<Player> tablePlayers = tables.get(table.getId());      
                if (tablePlayers.size() < 9) {
                    tablePlayers.add(player);
                }
           }
      }  
  public synchronized void leave(Player player, Table table) {/*body skipped for brevity*/}  
  public synchronized void createTable() {/*body skipped for brevity*/}  
  public synchronized void destroyTable(Table table) {/*body skipped for brevity*/}
}

作者的意圖是好的——當一個新的玩家加入牌桌 時，必須確保牌桌上的玩家數量不會超過牌桌可容納的玩家總個數9。

但是這種解決辦法事實上無論何時都要對玩家進入牌桌進行控制——即使是在服務器的訪問量較小的時候也是這樣，那些等待鎖釋放的線程注定會頻繁的觸發系統的競爭事件。包含對帳戶餘額和牌桌限制檢查的鎖定區塊很可能大幅提高呼叫操作的開銷，而這無疑會增加競爭的可能性和持續 時間。

解決的第一步是確保我們保護的是數據，而不是從方法聲明移到方法體中的那段同步聲明。對上面那個簡單的例子來說，可能改變不大。但是我們要站在整個遊戲服務的介面之上來考慮，而不是單單的一個join()方法。

class GameServer {  
   public Map<String, List<Player>> tables = new HashMap<String, List<Player>>();  
     public void join(Player player, Table table) {    
        synchronized (tables) {      
           if (player.getAccountBalance() > table.getLimit()) {
           List<Player> tablePlayers = tables.get(table.getId());        
              if (tablePlayers.size() < 9) {
                 tablePlayers.add(player);
               }
        }
      }
    }  
  public void leave(Player player, Table table) {/* body skipped for brevity */}  
  public void createTable() {/* body skipped for brevity */}  
  public void destroyTable(Table table) {/* body skipped for brevity */}
}

原本可能只是一個小小的改變，影響的可是整個類別的行為方式。玩家無論何時加入牌桌，先前的同步方法都會對整個GameServer實例加鎖，進而與那些同時試圖離開牌桌的玩家產生競爭。將鎖從方法聲明移到方法體中會延遲鎖的加載，進而降低了鎖競爭的可能性。

縮小鎖的作用範圍

現在，當確信了需要保護的是資料而非程序後，我們應該確保我們只在必要的地方加鎖——例如當上面的程式碼被重構之後：

public class GameServer {  
   public Map<String, List<Player>> tables = new HashMap<String, List<Player>>();  
   public void join(Player player, Table table) {    
   if (player.getAccountBalance() > table.getLimit()) {      
      synchronized (tables) {
        List<Player> tablePlayers = tables.get(table.getId());        
          if (tablePlayers.size() < 9) {
            tablePlayers.add(player);
          }
      }
    }
  }  
  //other methods skipped for brevity
}

這樣那段包含對玩家帳號餘額偵測（可能引發IO操作）的可能引起費時操作的程式碼，被移到了鎖控制的範圍之外。注意，現在鎖僅被用來防止玩家人數超過桌子可容納的人數，對帳戶餘額的檢查不再是該保護措施的一部分了。

分離鎖

你可以從上面例子最後一行程式碼清楚的看到：整個資料結構是由相同的鎖保護著。考慮到在這一種資料結構中可能會有數以千計的牌桌，而我們必須保護任何一張牌桌的人數不超過容量，在這樣的情況下仍然會有很高的風險出現競爭事件。

關於這個有一個簡單的辦法，就是對每一張牌桌引入分離鎖，如下面這個例子所示：

public class GameServer {  
public Map<String, List<Player>> tables = new HashMap<String, List<Player>>();  
public void join(Player player, Table table) {    
if (player.getAccountBalance() > table.getLimit()) {
      List<Player> tablePlayers = tables.get(table.getId());      
        synchronized (tablePlayers) {        
        if (tablePlayers.size() < 9) {
          tablePlayers.add(player);
        }
      }
    }
  }  
  //other methods skipped for brevity
}

現在，我們只對單一牌桌的可訪問性進行同步而不是所有的牌桌，這樣就顯著降低了出現鎖競爭的可能性。舉一個具體的例子，現在在我們的資料結構中有100個牌桌的實例，那麼現在發生競爭的可能性就會比之前小100倍。

使用執行緒安全的資料結構

另一个可以改善的地方就是抛弃传统的单线程数据结构，改用被明确设计为线程安全的数据结构。例如，当采用ConcurrentHashMap来储存你的牌桌实例时，代码可能像下面这样：

public class GameServer {  
public Map<String, List<Player>> tables = new ConcurrentHashMap<String, List<Player>>();  
public synchronized void join(Player player, Table table) {/*Method body skipped for brevity*/}  
public synchronized void leave(Player player, Table table) {/*Method body skipped for brevity*/}  
public synchronized void createTable() {
    Table table = new Table();
    tables.put(table.getId(), table);
  }  
  public synchronized void destroyTable(Table table) {
    tables.remove(table.getId());
  }
}

在join()和leave()方法内部的同步块仍然和先前的例子一样，因为我们要保证单个牌桌数据的完整性。ConcurrentHashMap 在这点上并没有任何帮助。但我们仍然会在increateTable()和destoryTable()方法中使用ConcurrentHashMap创建和销毁新的牌桌，所有这些操作对于ConcurrentHashMap来说是完全同步的，其允许我们以并行的方式添加或减少牌桌的数量。

其他一些建议和技巧

降低锁的可见度。在上面的例子中，锁被声明为public（对外可见），这可能会使得一些别有用心的人通过在你精心设计的监视器上加锁来破坏你的工作。

通过查看java.util.concurrent.locks 的API来看一下 有没有其它已经实现的锁策略，使用其改进上面的解决方案。

使用原子操作。在上面正在使用的简单递增计数器实际上并不要求加锁。上面的例子中更适合使用 AtomicInteger代替Integer作为计数器。

最后一点，无论你是否正在使用Plumber的自动死锁检测解决方案，还是手动从线程转储获得解决办法的信息，都希望这篇文章可以为你解决锁竞争的问题带来帮助。