如何线程安全的使用HashMap
在周二面試時(我轉的,當然不是我)，一面的面試官有問到HashMap是否是線程安全的，如何在線程安全的前提下使用HashMap,其實也就是HashMap，Hashtable，ConcurrentHashMap和synchronized Map的原理和區別。當時有些緊張只是簡單說了下HashMap不是線程安全的；Hashtable線程安全，但效率低，因為是Hashtable是使用synchronized的，所有線程競爭同一把鎖；而ConcurrentHashMap不僅線程安全而且效率高，因為它包含一個segment數組，將數據分段存儲，給每一段數據配一把鎖，也就是所謂的鎖分段技術。當時忘記了synchronized Map和解釋一下HashMap為什么線程不安全。面試結束后問了下面試官哪里有些不足，面試官說上面這個問題的回答算過關，但可以在深入一些或者自己動手嘗試一下。so~~~雖然拿到了offer，但還是再整理一下，不能得過且過啊。
為什么HashMap是線程不安全的
總說HashMap是線程不安全的，不安全的，不安全的，那么到底為什么它是線程不安全的呢？要回答這個問題就要先來簡單了解一下HashMap源碼中的使用的存儲結構(這里引用的是Java 8的源碼，與7是不一樣的)和它的擴容機制。
HashMap的內部存儲結構
下面是HashMap使用的存儲結構:
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會存儲到同一個鏈表里
需要注意的是，在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
例子：
//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方法：
public synchronized V get(Object key) {// 省略實現}public synchronized V put(K key, V value) {// 省略實現}
ConcurrentHashMap所以當一個線程訪問HashTable的同步方法時，其他線程如果也要訪問同步方法，會被阻塞住。舉個例子，當一個線程使用put方法時，另一個線程不但不可以使用put方法，連get方法都不可以，好霸道啊！！！so~~，效率很低，現在基本不會選擇它了。
ConcurrentHashMap(以下簡稱CHM)是JUC包中的一個類，Spring的源碼中有很多使用CHM的地方。之前已經翻譯過一篇關于ConcurrentHashMap的博客，如何在java中使用ConcurrentHashMap，里面介紹了CHM在Java中的實現，CHM的一些重要特性和什么情況下應該使用CHM。需要注意的是，上面博客是基于Java 7的，和8有區別,在8中CHM摒棄了Segment（鎖段）的概念，而是啟用了一種全新的方式實現,利用CAS算法，有時間會重新總結一下。
SynchronizedMap
看了一下源碼，SynchronizedMap的實現還是很簡單的。
// 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 Mapfinal Object????? mutex;??????? // Object on which to synchronizeSynchronizedMap(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花費的時間比前兩個的一半還少，哈哈，以后再有人問就可以甩數據了。
?
原文鏈接:https://yemengying.com/2016/05/07/threadsafe-hashmap/
《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀總結
以上是生活随笔為你收集整理的如何线程安全的使用HashMap的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Android技能树 — LayoutI
- 下一篇： Toast弹不出来之谜