作者 | 許光明

杏仁後端工程師。少青年程式設計師，關注服務端技術和農藥。

前言

JAVA 語言提供了大量豐富的集合, 比如 List, Set, Map 等。其中 Map 是一個常用的一個數據結構，HashMap 是基於 Hash 演算法實現 Map 介面而被廣泛使用的集類。HashMap 裡面是一個數組，然後陣列中每個元素是一個單向連結串列。但是 HashMap 並不是執行緒安全的, 在多執行緒場景下使用存在併發和死迴圈問題。HashMap 結構如圖所示：

執行緒安全的解決方案

執行緒安全的 Map 的實現有 HashTable 和 ConcurrentHashMap 等。HashTable 對集合讀寫操作通過 Synchronized 同步保障執行緒安全, 整個集合只有一把鎖, 對集合的操作只能序列執行，效能不高。ConcurrentHashMap 是另一個執行緒安全的 Map, 通常來說他的效能優於 HashTable。 ConcurrentHashMap 的實現在 JDK1.7 和 JDK 1.8 有所不同。

在 JDK1.7 版本中，ConcurrentHashMap 的資料結構是由一個 Segment 陣列和多個 HashEntry 組成。簡單理解就是ConcurrentHashMap 是一個 Segment 陣列，Segment 通過繼承 ReentrantLock 來進行加鎖，所以每次需要加鎖的操作鎖住的是一個 Segment，這樣只要保證每個 Segment 是執行緒安全的，也就實現了全域性的執行緒安全。

JDK1.8 的實現已經摒棄了 Segment 的概念，而是直接用 Node 陣列 + 連結串列 + 紅黑樹的資料結構來實現，併發控制使用 Synchronized 和 CAS 來操作，整個看起來就像是優化過且執行緒安全的 HashMap，雖然在 JDK1.8 中還能看到 Segment 的資料結構，但是已經簡化了屬性，只是為了相容舊版本。 通過 HashMap 查詢的時候，根據 hash 值能夠快速定位到陣列的具體下標，如果發生 Hash 碰撞，需要順著連結串列一個個比較下去才能找到我們需要的，時間複雜度取決於連結串列的長度，為 O(n)。為了降低這部分的開銷，在 Java8 中，當連結串列中的元素超過了 8 個以後，會將連結串列轉換為紅黑樹，在這些位置進行查詢的時候可以降低時間複雜度為 O(logN)。

如何計算 ConcurrentHashMap Size

由上面分析可知，ConcurrentHashMap 更適合作為執行緒安全的 Map。在實際的專案過程中，我們通常需要獲取集合類的長度， 那麼計算 ConcurrentHashMap 的元素大小就是一個有趣的問題，因為他是併發操作的，就是在你計算 size 的時候，它還在併發的插入資料，可能會導致你計算出來的 size 和你實際的 size 有差距。本文主要分析下 JDK1.8 的實現。 關於 JDK1.7 簡單提一下。

在 JDK1.7 中，第一種方案他會使用不加鎖的模式去嘗試多次計算 ConcurrentHashMap 的 size，最多三次，比較前後兩次計算的結果，結果一致就認為當前沒有元素加入，計算的結果是準確的。 第二種方案是如果第一種方案不符合，他就會給每個 Segment 加上鎖，然後計算 ConcurrentHashMap 的 size 返回。其原始碼實現:

public int size() {
  final Segment<K,V>[] segments = this.segments;
  int size;
  boolean overflow; // true if size overflows 32 bits
  long sum;         // sum of modCounts
  long last = 0L;   // previous sum
  int retries = -1; // first iteration isn't retry
  try {
    for (;;) {
      if (retries++ == RETRIES_BEFORE_LOCK) {
        for (int j = 0; j < segments.length; ++j)
          ensureSegment(j).lock(); // force creation
      }
      sum = 0L;
      size = 0;
      overflow = false;
      for (int j = 0; j < segments.length; ++j) {
        Segment<K,V> seg = segmentAt(segments, j);
        if (seg != null) {
          sum += seg.modCount;
          int c = seg.count;
          if (c < 0 || (size += c) < 0)
            overflow = true;
        }
      }
      if (sum == last)
        break;
      last = sum;
    }
  } finally {
    if (retries > RETRIES_BEFORE_LOCK) {
      for (int j = 0; j < segments.length; ++j)
        segmentAt(segments, j).unlock();
    }
  }
  return overflow ? Integer.MAX_VALUE : size;
}

JDK1.8 實現相比 JDK 1.7 簡單很多，只有一種方案，我們直接看 size()程式碼：

public int size() {
    long n = sumCount();
    return ((n < 0L) ? 0 :
           (n > (long)Integer.MAX_VALUE) ? Integer.MAX_VALUE : (int)n);
}

最大值是 Integer 型別的最大值，但是 Map 的 size 可能超過 MAX_VALUE， 所以還有一個方法 mappingCount()，JDK 的建議使用mappingCount()而不是size()。mappingCount()的程式碼如下：

public long mappingCount() {
    long n = sumCount();
    return (n < 0L) ? 0L : n; // ignore transient negative values
}

以上可以看出，無論是 size()還是mappingCount(), 計算大小的核心方法都是sumCount()。sumCount()的程式碼如下:

final long sumCount() {
    CounterCell[] as = counterCells; CounterCell a;
    long sum = baseCount;
    if (as != null) {
       for (int i = 0; i < as.length; ++i) {
           if ((a = as[i]) != null)
               sum += a.value;
           }
       }
    return sum;
}

分析一下 sumCount()程式碼。ConcurrentHashMap 提供了 baseCount、counterCells 兩個輔助變數和一個 CounterCell 輔助內部類。sumCount()就是迭代 counterCells 來統計 sum 的過程。 put 操作時，肯定會影響size()，在put()方法最後會呼叫addCount()方法。

addCount() 程式碼如下：

• 如果 counterCells == null, 則對 baseCount 做 CAS 自增操作。

• 如果併發導致 baseCount CAS 失敗了使用 counterCells。

• 如果counterCells CAS 失敗了，在 fullAddCount 方法中，會繼續死迴圈操作，直到成功。

然後，CounterCell 這個類到底是什麼？我們會發現它使用了 @sun.misc.Contended 標記的類，內部包含一個 volatile 變數。@sun.misc.Contended 這個註解標識著這個類防止需要防止 "偽共享"。那麼，什麼又是偽共享呢？

快取系統中是以快取行（cache line）為單位儲存的。快取行是2的整數冪個連續位元組，一般為32-256個位元組。最常見的快取行大小是64個位元組。當多執行緒修改互相獨立的變數時，如果這些變數共享同一個快取行，就會無意中影響彼此的效能，這就是偽共享。

CounterCell 程式碼如下：

@sun.misc.Contended static final class CounterCell {
    volatile long value;
    CounterCell(long x) { value = x; }
}    

總結

• JDK1.7 和 JDK1.8 對 size 的計算是不一樣的。 1.7 中是先不加鎖計算三次，如果三次結果不一樣在加鎖。

• JDK1.8 size 是通過對 baseCount 和 counterCell 進行 CAS 計算，最終通過 baseCount 和 遍歷 CounterCell 陣列得出 size。

• JDK 8 推薦使用mappingCount 方法，因為這個方法的返回值是 long 型別，不會因為 size 方法是 int 型別限制最大值。

全文完

以下文章您可能也會感興趣：

我們正在招聘 Java 工程師，歡迎有興趣的同學投遞簡歷到 [email protected] 。

杏仁技術站

長按左側二維碼關注我們，這裡有一群熱血青年期待著與您相會。