如何線程安全的使用HashMap

原文出處：  Giraffe

如何在線程安全的前提下使用HashMap,其實也就是HashMap，Hashtable，ConcurrentHashMap和synchronized Map的原理和區別。

HashMap是不是線程安全的：在擴容時可能發生死循環，可能丟失數據 

Hashtable ：線程安全，但效率低，由於是Hashtable是使用synchronized的，全部線程競爭同一把鎖；

ConcurrentHashMap：不只線程安全並且效率高，由於它包含一個segment數組，將數據分段存儲，給每一段數據配一把鎖，也就是所謂的鎖分段技術。

synchronized Map：不必定線程安全，在某些時候會出現一些意想不到的結果

 

 

爲何HashMap是線程不安全的

總說HashMap是線程不安全的，不安全的，不安全的，那麼到底爲何它是線程不安全的呢？要回答這個問題就要先來簡單瞭解一下HashMap源碼中的使用的存儲結構(這裏引用的是Java 8的源碼，與7是不同的)和它的擴容機制。

HashMap的內部存儲結構

下面是HashMap使用的存儲結構:

1 2 3 4 5 6 7 8

transient Node<K,V>[] table;   static class Node<K,V> implements Map.Entry<K,V> {          final int hash;          final K key;          V value;          Node<K,V> next; }

能夠看到HashMap內部存儲使用了一個Node數組(默認大小是16)，而Node類包含一個類型爲Node的next的變量，也就是至關於一個鏈表，全部hash值相同(即產生了衝突)的key會存儲到同一個鏈表裏，大概就是下面圖的樣子(順便推薦個在線畫圖的網站Creately)。
HashMap內部存儲結果

須要注意的是，在Java 8中若是hash值相同的key數量大於指定值(默認是8)時使用平衡樹來代替鏈表，這會將get()方法的性能從O(n)提升到O(logn)。具體的能夠看個人另外一篇博客Java 8中HashMap和LinkedHashMap如何解決衝突。

HashMap的自動擴容機制

HashMap內部的Node數組默認的大小是16，假設有100萬個元素，那麼最好的狀況下每一個hash桶裏都有62500個元素，這時get(),put(),remove()等方法效率都會下降。爲了解決這個問題，HashMap提供了自動擴容機制，當元素個數達到數組大小loadFactor後會擴大數組的大小，在默認狀況下，數組大小爲16，loadFactor爲0.75，也就是說當HashMap中的元素超過16\0.75=12時，會把數組大小擴展爲2*16=32，而且從新計算每一個元素在新數組中的位置。以下圖所示(圖片來源，權侵刪)。

自動擴容

從圖中能夠看到沒擴容前，獲取EntryE須要遍歷5個元素，擴容以後只須要2次。

爲何線程不安全

我的以爲HashMap在併發時可能出現的問題主要是兩方面,首先若是多個線程同時使用put方法添加元素，並且假設正好存在兩個put的key發生了碰撞(hash值同樣)，那麼根據HashMap的實現，這兩個key會添加到數組的同一個位置，這樣最終就會發生其中一個線程的put的數據被覆蓋。第二就是若是多個線程同時檢測到元素個數超過數組大小*loadFactor，這樣就會發生多個線程同時對Node數組進行擴容，都在從新計算元素位置以及複製數據，可是最終只有一個線程擴容後的數組會賦給table，也就是說其餘線程的都會丟失，而且各自線程put的數據也丟失。
關於HashMap線程不安全這一點，《Java併發編程的藝術》一書中是這樣說的：

HashMap在併發執行put操做時會引發死循環，致使CPU利用率接近100%。由於多線程會致使HashMap的Node鏈表造成環形數據結構，一旦造成環形數據結構，Node的next節點永遠不爲空，就會在獲取Node時產生死循環。

哇塞，聽上去si不si好神奇，竟然會產生死循環。。。。google了一下，才知道死循環並非發生在put操做時，而是發生在擴容時。詳細的解釋能夠看下面幾篇博客：

• 酷殼-Java HashMap的死循環
• HashMap在java併發中如何發生死循環
• How does a HashMap work in JAVA

如何線程安全的使用HashMap

瞭解了HashMap爲何線程不安全，那如今看看如何線程安全的使用HashMap。這個無非就是如下三種方式：

• Hashtable
• ConcurrentHashMap
• Synchronized Map

例子：

1 2 3 4 5 6 7 8

//Hashtable Map<String, String> hashtable = new Hashtable<>();   //synchronizedMap Map<String, String> synchronizedHashMap = Collections.synchronizedMap( new HashMap<String, String>());   //ConcurrentHashMap Map<String, String> concurrentHashMap = new ConcurrentHashMap<>();

依次來看看。

Hashtable

先稍微吐槽一下，爲啥命名不是HashTable啊，看着好難受，無論了就裝做它叫HashTable吧。這貨已經不經常使用了，就簡單說說吧。HashTable源碼中是使用synchronized來保證線程安全的，好比下面的get方法和put方法：

1 2 3 4 5 6

public synchronized V get(Object key) {         // 省略實現      } public synchronized V put(K key, V value) {      // 省略實現      }

因此當一個線程訪問HashTable的同步方法時，其餘線程若是也要訪問同步方法，會被阻塞住。舉個例子，當一個線程使用put方法時，另外一個線程不但不可使用put方法，連get方法都不能夠，好霸道啊！！！so~~，效率很低，如今基本不會選擇它了。

ConcurrentHashMap

ConcurrentHashMap(如下簡稱CHM)是JUC包中的一個類，Spring的源碼中有不少使用CHM的地方。以前已經翻譯過一篇關於ConcurrentHashMap的博客，如何在java中使用ConcurrentHashMap，裏面介紹了CHM在Java中的實現，CHM的一些重要特性和什麼狀況下應該使用CHM。須要注意的是，上面博客是基於Java 7的，和8有區別,在8中CHM摒棄了Segment（鎖段）的概念，而是啓用了一種全新的方式實現,利用CAS算法，有時間會從新總結一下。

SynchronizedMap

看了一下源碼，SynchronizedMap的實現仍是很簡單的。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

// synchronizedMap方法 public static <K,V> Map<K,V> synchronizedMap(Map<K,V> m) {         return new SynchronizedMap<>(m);     } // SynchronizedMap類 private static class SynchronizedMap<K,V>         implements Map<K,V>, Serializable {         private static final long serialVersionUID = 1978198479659022715L;           private final Map<K,V> m;     // Backing Map         final Object      mutex;        // Object on which to synchronize           SynchronizedMap(Map<K,V> m) {             this .m = Objects.requireNonNull(m);             mutex = this ;         }           SynchronizedMap(Map<K,V> m, Object mutex) {             this .m = m;             this .mutex = mutex;         }           public int size() {             synchronized (mutex) { return m.size();}         }         public boolean isEmpty() {             synchronized (mutex) { return m.isEmpty();}         }         public boolean containsKey(Object key) {             synchronized (mutex) { return m.containsKey(key);}         }         public boolean containsValue(Object value) {             synchronized (mutex) { return m.containsValue(value);}         }         public V get(Object key) {             synchronized (mutex) { return m.get(key);}         }           public V put(K key, V value) {             synchronized (mutex) { return m.put(key, value);}         }         public V remove(Object key) {             synchronized (mutex) { return m.remove(key);}         }         // 省略其餘方法     }

從源碼中能夠看出調用synchronizedMap()方法後會返回一個SynchronizedMap類的對象，而在SynchronizedMap類中使用了synchronized同步關鍵字來保證對Map的操做是線程安全的。

性能對比

這是要靠數聽說話的時代，因此不能只靠嘴說CHM快，它就快了。寫個測試用例，實際的比較一下這三種方式的效率(源碼來源)，下面的代碼分別經過三種方式建立Map對象，使用ExecutorService來併發運行5個線程，每一個線程添加/獲取500K個元素。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66

public class CrunchifyConcurrentHashMapVsSynchronizedMap {        public final static int THREAD_POOL_SIZE = 5 ;        public static Map<String, Integer> crunchifyHashTableObject = null ;      public static Map<String, Integer> crunchifySynchronizedMapObject = null ;      public static Map<String, Integer> crunchifyConcurrentHashMapObject = null ;        public static void main(String[] args) throws InterruptedException {            // Test with Hashtable Object          crunchifyHashTableObject = new Hashtable<>();          crunchifyPerformTest(crunchifyHashTableObject);            // Test with synchronizedMap Object          crunchifySynchronizedMapObject = Collections.synchronizedMap( new HashMap<String, Integer>());          crunchifyPerformTest(crunchifySynchronizedMapObject);            // Test with ConcurrentHashMap Object          crunchifyConcurrentHashMapObject = new ConcurrentHashMap<>();          crunchifyPerformTest(crunchifyConcurrentHashMapObject);        }        public static void crunchifyPerformTest( final Map<String, Integer> crunchifyThreads) throws InterruptedException {            System.out.println( "Test started for: " + crunchifyThreads.getClass());          long averageTime = 0 ;          for ( int i = 0 ; i < 5 ; i++) {                long startTime = System.nanoTime();              ExecutorService crunchifyExServer = Executors.newFixedThreadPool(THREAD_POOL_SIZE);                for ( int j = 0 ; j < THREAD_POOL_SIZE; j++) {                  crunchifyExServer.execute( new Runnable() {                      @SuppressWarnings ( "unused" )                      @Override                      public void run() {                            for ( int i = 0 ; i < 500000 ; i++) {                              Integer crunchifyRandomNumber = ( int ) Math.ceil(Math.random() * 550000 );                                // Retrieve value. We are not using it anywhere                              Integer crunchifyValue = crunchifyThreads.get(String.valueOf(crunchifyRandomNumber));                                // Put value                              crunchifyThreads.put(String.valueOf(crunchifyRandomNumber), crunchifyRandomNumber);                          }                      }                  });              }                // Make sure executor stops              crunchifyExServer.shutdown();                // Blocks until all tasks have completed execution after a shutdown request              crunchifyExServer.awaitTermination(Long.MAX_VALUE, TimeUnit.DAYS);                long entTime = System.nanoTime();              long totalTime = (entTime - startTime) / 1000000L;              averageTime += totalTime;              System.out.println( "2500K entried added/retrieved in " + totalTime + " ms" );          }          System.out.println( "For " + crunchifyThreads.getClass() + " the average time is " + averageTime / 5 + " ms\n" );      } }

測試結果：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Test started for : class java.util.Hashtable 2500K entried added/retrieved in 2018 ms 2500K entried added/retrieved in 1746 ms 2500K entried added/retrieved in 1806 ms 2500K entried added/retrieved in 1801 ms 2500K entried added/retrieved in 1804 ms For class java.util.Hashtable the average time is 1835 ms   Test started for : class java.util.Collections$SynchronizedMap 2500K entried added/retrieved in 3041 ms 2500K entried added/retrieved in 1690 ms 2500K entried added/retrieved in 1740 ms 2500K entried added/retrieved in 1649 ms 2500K entried added/retrieved in 1696 ms For class java.util.Collections$SynchronizedMap the average time is 1963 ms   Test started for : class java.util.concurrent.ConcurrentHashMap 2500K entried added/retrieved in 738 ms 2500K entried added/retrieved in 696 ms 2500K entried added/retrieved in 548 ms 2500K entried added/retrieved in 1447 ms 2500K entried added/retrieved in 531 ms For class java.util.concurrent.ConcurrentHashMap the average time is 792 ms

這個就不用廢話了，CHM性能是明顯優於Hashtable和SynchronizedMap的,CHM花費的時間比前兩個的一半還少，哈哈，之後再有人問就能夠甩數據了。

 

 SynchronizedMap

Collections爲HashMap提供了一個併發版本SynchronizedMap。這個版本中的方法都進行了同步，可是這並不等於這個類就必定是線程安全的。在某些時候會出現一些意想不到的結果。

以下面這段代碼：

Java代碼

1. // shm是SynchronizedMap的一個實例  
2. if(shm.containsKey('key')){  
3.         shm.remove(key);  
4. }  

// shm是SynchronizedMap的一個實例 if(shm.containsKey('key')){         shm.remove(key); } 

 這段代碼用於從map中刪除一個元素以前判斷是否存在這個元素。這裏的containsKey和reomve方法都是同步的，可是整段代碼卻不是。考慮這麼一個使用場景：線程A執行了containsKey方法返回true，準備執行remove操做；這時另外一個線程B開始執行，一樣執行了containsKey方法返回true，並接着執行了remove操做；而後線程A接着執行remove操做時發現此時已經沒有這個元素了。要保證這段代碼按咱們的意願工做，一個辦法就是對這段代碼進行同步控制，可是這麼作付出的代價太大。

 

 

 

3. 併發狀況下更好的選擇：ConcurrentHashMap

效率低下的HashTable容器

HashTable容器使用synchronized來保證線程安全，但在線程競爭激烈的狀況下HashTable的效率很是低下。由於當一個線程訪問HashTable的同步方法時，其餘線程訪問HashTable的同步方法時，可能會進入阻塞或輪詢狀態。如線程1使用put進行添加元素，線程2不但不能使用put方法添加元素，而且也不能使用get方法來獲取元素，因此競爭越激烈效率越低。

鎖分段技術

HashTable容器在競爭激烈的併發環境下表現出效率低下的緣由是全部訪問HashTable的線程都必須競爭同一把鎖，那假如容器裏有多把鎖，每一把鎖用於鎖容器其中一部分數據，那麼當多線程訪問容器裏不一樣數據段的數據時，線程間就不會存在鎖競爭，從而能夠有效的提升併發訪問效率，這就是ConcurrentHashMap所使用的鎖分段技術，首先將數據分紅一段一段的存儲，而後給每一段數據配一把鎖，當一個線程佔用鎖訪問其中一個段數據的時候，其餘段的數據也能被其餘線程訪問。

 

java5中新增了ConcurrentMap接口和它的一個實現類ConcurrentHashMap。ConcurrentHashMap提供了和Hashtable以及SynchronizedMap中所不一樣的鎖機制。Hashtable中採用的鎖機制是一次鎖住整個hash表，從而同一時刻只能由一個線程對其進行操做；而ConcurrentHashMap中則是一次鎖住一個桶。ConcurrentHashMap默認將hash表分爲16個桶，諸如get,put,remove等經常使用操做只鎖當前須要用到的桶。這樣，原來只能一個線程進入，如今卻能同時有16個寫線程執行，併發性能的提高是顯而易見的。

 

上面說到的16個線程指的是寫線程，而讀操做大部分時候都不須要用到鎖。只有在size等操做時才須要鎖住整個hash表。

 

在迭代方面，ConcurrentHashMap使用了一種不一樣的迭代方式。在這種迭代方式中，當iterator被建立後集合再發生改變就再也不是拋出ConcurrentModificationException，取而代之的是在改變時new新的數據從而不影響原有的數據，iterator完成後再將頭指針替換爲新的數據，這樣iterator線程可使用原來老的數據，而寫線程也能夠併發的完成改變。