ConcurrentHashMap一般只被看作併發效率更高的Map,用來替換其餘線程安全的Map容器,好比Hashtable和Collections.synchronizedMap。實際上,線程安全的容器,特別是Map,應用場景沒有想象中的多,不少狀況下一個業務會涉及容器的多個操做,即複合操做,併發執行時,線程安全的容器只能保證自身的數據不被破壞,但沒法保證業務的行爲是否正確。 java
舉個例子:統計文本中單詞出現的次數,把單詞出現的次數記錄到一個Map中,代碼以下: 緩存
private final Map<String, Long> wordCounts = new ConcurrentHashMap<>(); public long increase(String word) { Long oldValue = wordCounts.get(word); Long newValue = (oldValue == null) ? 1L : oldValue + 1; wordCounts.put(word, newValue); return newValue; }若是多個線程併發調用這個increase()方法,increase()的實現就是錯誤的,由於多個線程用相同的word調用時,極可能會覆蓋相互的結果,形成記錄的次數比實際出現的次數少。
除了用鎖解決這個問題,另一個選擇是使用ConcurrentMap接口定義的方法: 安全
public interface ConcurrentMap<K, V> extends Map<K, V> { V putIfAbsent(K key, V value); boolean remove(Object key, Object value); boolean replace(K key, V oldValue, V newValue); V replace(K key, V value); }這是個被不少人忽略的接口,也常常見有人錯誤地使用這個接口。ConcurrentMap接口定義了幾個基於 CAS(Compare and Set)操做,很簡單,但很是有用,下面的代碼用ConcurrentMap解決上面問題:
private final ConcurrentMap<String, Long> wordCounts = new ConcurrentHashMap<>(); public long increase(String word) { Long oldValue, newValue; while (true) { oldValue = wordCounts.get(word); if (oldValue == null) { // Add the word firstly, initial the value as 1 newValue = 1L; if (wordCounts.putIfAbsent(word, newValue) == null) { break; } } else { newValue = oldValue + 1; if (wordCounts.replace(word, oldValue, newValue)) { break; } } } return newValue; }代碼有點複雜,主要由於ConcurrentMap中不能保存value爲null的值,因此得同時處理word不存在和已存在兩種狀況。
上面的實現每次調用都會涉及Long對象的拆箱和裝箱操做,很明顯,更好的實現方式是採用AtomicLong,下面是採用AtomicLong後的代碼: 併發
private final ConcurrentMap<String, AtomicLong> wordCounts = new ConcurrentHashMap<>(); public long increase(String word) { AtomicLong number = wordCounts.get(word); if (number == null) { AtomicLong newNumber = new AtomicLong(0); number = wordCounts.putIfAbsent(word, newNumber); if (number == null) { number = newNumber; } } return number.incrementAndGet(); }這個實現仍然有一處須要說明的地方,若是多個線程同時增長一個目前還不存在的詞,那麼極可能會產生多個newNumber對象,但最終只有一個newNumber有用,其餘的都會被扔掉。對於這個應用,這不算問題,建立AtomicLong的成本不高,並且只在添加不存在詞是出現。但換個場景,好比緩存,那麼這極可能就是問題了,由於緩存中的對象獲取成本通常都比較高,並且一般緩存都會常常失效,那麼避免重複建立對象就有價值了。下面的代碼演示了怎麼處理這種狀況:
private final ConcurrentMap<String, Future<ExpensiveObj>> cache = new ConcurrentHashMap<>(); public ExpensiveObj get(final String key) { Future<ExpensiveObj> future = cache.get(key); if (future == null) { Callable<ExpensiveObj> callable = new Callable<ExpensiveObj>() { @Override public ExpensiveObj call() throws Exception { return new ExpensiveObj(key); } }; FutureTask<ExpensiveObj> task = new FutureTask<>(callable); future = cache.putIfAbsent(key, task); if (future == null) { future = task; task.run(); } } try { return future.get(); } catch (Exception e) { cache.remove(key); throw new RuntimeException(e); } }解決方法其實就是用一個Proxy對象來包裝真正的對象,跟常見的lazy load原理相似;使用FutureTask主要是爲了保證同步,避免一個Proxy建立多個對象。注意,上面代碼裏的異常處理是不許確的。
最後再補充一下,若是真要實現前面說的統計單詞次數功能,最合適的方法是Guava包中AtomicLongMap;通常使用ConcurrentHashMap,也儘可能使用Guava中的MapMaker或cache實現。
ide