如何线程安全的使用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线程可使用原来老的数据，而写线程也能够并发的完成改变。