原文连接:http://www.javashuo.com/article/p-reoakzpc-hu.htmljava
Map 这样的 Key Value
在软件开发中是很是经典的结构,经常使用于在内存中存放数据。node
本篇主要想讨论 ConcurrentHashMap 这样一个并发容器,在正式开始以前我以为有必要谈谈 HashMap,没有它就不会有后面的 ConcurrentHashMap。git
众所周知 HashMap 底层是基于 数组 + 链表
组成的,不过在 jdk1.7 和 1.8 中具体实现稍有不一样。github
1.7 中的数据结构图:面试
先来看看 1.7 中的实现。segmentfault
这是 HashMap 中比较核心的几个成员变量;看看分别是什么意思?数组
table
真正存放数据的数组。Map
存放数量的大小。重点解释下负载因子:安全
因为给定的 HashMap 的容量大小是固定的,好比默认初始化:数据结构
1 public HashMap() { 2 this(DEFAULT_INITIAL_CAPACITY, DEFAULT_LOAD_FACTOR); 3 } 4 5 public HashMap(int initialCapacity, float loadFactor) { 6 if (initialCapacity < 0) 7 throw new IllegalArgumentException("Illegal initial capacity: " + 8 initialCapacity); 9 if (initialCapacity > MAXIMUM_CAPACITY) 10 initialCapacity = MAXIMUM_CAPACITY; 11 if (loadFactor <= 0 || Float.isNaN(loadFactor)) 12 throw new IllegalArgumentException("Illegal load factor: " + 13 loadFactor); 14 15 this.loadFactor = loadFactor; 16 threshold = initialCapacity; 17 init(); 18 }
给定的默认容量为 16,负载因子为 0.75。Map 在使用过程当中不断的往里面存放数据,当数量达到了 16 * 0.75 = 12
就须要将当前 16 的容量进行扩容,而扩容这个过程涉及到 rehash、复制数据等操做,因此很是消耗性能。并发
所以一般建议能提早预估 HashMap 的大小最好,尽可能的减小扩容带来的性能损耗。
根据代码能够看到其实真正存放数据的是
transient Entry<K,V>[] table = (Entry<K,V>[]) EMPTY_TABLE;
这个数组,那么它又是如何定义的呢?
Entry 是 HashMap 中的一个内部类,从他的成员变量很容易看出:
知晓了基本结构,那来看看其中重要的写入、获取函数:
public V put(K key, V value) { if (table == EMPTY_TABLE) { inflateTable(threshold); } if (key == null) return putForNullKey(value); int hash = hash(key); int i = indexFor(hash, table.length); for (Entry<K,V> e = table[i]; e != null; e = e.next) { Object k; if (e.hash == hash && ((k = e.key) == key || key.equals(k))) { V oldValue = e.value; e.value = value; e.recordAccess(this); return oldValue; } } modCount++; addEntry(hash, key, value, i); return null; }
void addEntry(int hash, K key, V value, int bucketIndex) { if ((size >= threshold) && (null != table[bucketIndex])) { resize(2 * table.length); hash = (null != key) ? hash(key) : 0; bucketIndex = indexFor(hash, table.length); } createEntry(hash, key, value, bucketIndex); } void createEntry(int hash, K key, V value, int bucketIndex) { Entry<K,V> e = table[bucketIndex]; table[bucketIndex] = new Entry<>(hash, key, value, e); size++; }
当调用 addEntry 写入 Entry 时须要判断是否须要扩容。
若是须要就进行两倍扩充,并将当前的 key 从新 hash 并定位。
而在 createEntry
中会将当前位置的桶传入到新建的桶中,若是当前桶有值就会在位置造成链表。
再来看看 get 函数:
public V get(Object key) { if (key == null) return getForNullKey(); Entry<K,V> entry = getEntry(key); return null == entry ? null : entry.getValue(); } final Entry<K,V> getEntry(Object key) { if (size == 0) { return null; } int hash = (key == null) ? 0 : hash(key); for (Entry<K,V> e = table[indexFor(hash, table.length)]; e != null; e = e.next) { Object k; if (e.hash == hash && ((k = e.key) == key || (key != null && key.equals(k)))) return e; } return null; }
key、key 的 hashcode
是否相等来返回值。不知道 1.7 的实现你们看出须要优化的点没有?
其实一个很明显的地方就是:
当 Hash 冲突严重时,在桶上造成的链表会变的愈来愈长,这样在查询时的效率就会愈来愈低;时间复杂度为
O(N)
。
所以 1.8 中重点优化了这个查询效率。
1.8 HashMap 结构图:
先来看看几个核心的成员变量:
1 static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16 2 3 /** 4 * The maximum capacity, used if a higher value is implicitly specified 5 * by either of the constructors with arguments. 6 * MUST be a power of two <= 1<<30. 7 */ 8 static final int MAXIMUM_CAPACITY = 1 << 30; 9 10 /** 11 * The load factor used when none specified in constructor. 12 */ 13 static final float DEFAULT_LOAD_FACTOR = 0.75f; 14 15 static final int TREEIFY_THRESHOLD = 8; 16 17 transient Node<K,V>[] table; 18 19 /** 20 * Holds cached entrySet(). Note that AbstractMap fields are used 21 * for keySet() and values(). 22 */ 23 transient Set<Map.Entry<K,V>> entrySet; 24 25 /** 26 * The number of key-value mappings contained in this map. 27 */ 28 transient int size;
和 1.7 大致上都差很少,仍是有几个重要的区别:
TREEIFY_THRESHOLD
用于判断是否须要将链表转换为红黑树的阈值。Node 的核心组成其实也是和 1.7 中的 HashEntry 同样,存放的都是 key value hashcode next
等数据。
再来看看核心方法。
看似要比 1.7 的复杂,咱们一步步拆解:
key、key 的 hashcode
与写入的 key 是否相等,相等就赋值给 e
,在第 8 步的时候会统一进行赋值及返回。e != null
就至关于存在相同的 key,那就须要将值覆盖。1 public V get(Object key) { 2 Node<K,V> e; 3 return (e = getNode(hash(key), key)) == null ? null : e.value; 4 } 5 6 final Node<K,V> getNode(int hash, Object key) { 7 Node<K,V>[] tab; Node<K,V> first, e; int n; K k; 8 if ((tab = table) != null && (n = tab.length) > 0 && 9 (first = tab[(n - 1) & hash]) != null) { 10 if (first.hash == hash && // always check first node 11 ((k = first.key) == key || (key != null && key.equals(k)))) 12 return first; 13 if ((e = first.next) != null) { 14 if (first instanceof TreeNode) 15 return ((TreeNode<K,V>)first).getTreeNode(hash, key); 16 do { 17 if (e.hash == hash && 18 ((k = e.key) == key || (key != null && key.equals(k)))) 19 return e; 20 } while ((e = e.next) != null); 21 } 22 } 23 return null; 24 }
get 方法看起来就要简单许多了。
从这两个核心方法(get/put)能够看出 1.8 中对大链表作了优化,修改成红黑树以后查询效率直接提升到了 O(logn)
。
可是 HashMap 原有的问题也都存在,好比在并发场景下使用时容易出现死循环。
1 final HashMap<String, String> map = new HashMap<String, String>(); 2 for (int i = 0; i < 1000; i++) { 3 new Thread(new Runnable() { 4 @Override 5 public void run() { 6 map.put(UUID.randomUUID().toString(), ""); 7 } 8 }).start(); 9 }
可是为何呢?简单分析下。
看过上文的还记得在 HashMap 扩容的时候会调用 resize()
方法,就是这里的并发操做容易在一个桶上造成环形链表;这样当获取一个不存在的 key 时,计算出的 index 正好是环形链表的下标就会出现死循环。
以下图:
还有一个值得注意的是 HashMap 的遍历方式,一般有如下几种:
1 Iterator<Map.Entry<String, Integer>> entryIterator = map.entrySet().iterator(); 2 while (entryIterator.hasNext()) { 3 Map.Entry<String, Integer> next = entryIterator.next(); 4 System.out.println("key=" + next.getKey() + " value=" + next.getValue()); 5 } 6 7 Iterator<String> iterator = map.keySet().iterator(); 8 while (iterator.hasNext()){ 9 String key = iterator.next(); 10 System.out.println("key=" + key + " value=" + map.get(key)); 11 12 }
强烈建议
使用第一种 EntrySet 进行遍历。
第一种能够把 key value 同时取出,第二种还得须要经过 key 取一次 value,效率较低。
简单总结下 HashMap:不管是 1.7 仍是 1.8 其实都能看出 JDK 没有对它作任何的同步操做,因此并发会出问题,甚至出现死循环致使系统不可用。
所以 JDK 推出了专项专用的 ConcurrentHashMap ,该类位于 java.util.concurrent
包下,专门用于解决并发问题。
坚持看到这里的朋友算是已经把 ConcurrentHashMap 的基础已经打牢了,下面正式开始分析。
ConcurrentHashMap 一样也分为 1.7 、1.8 版,二者在实现上略有不一样。
先来看看 1.7 的实现,下面是他的结构图:
如图所示,是由 Segment 数组、HashEntry 组成,和 HashMap 同样,仍然是数组加链表。
它的核心成员变量:
1 /** 2 * Segment 数组,存放数据时首先须要定位到具体的 Segment 中。 3 */ 4 final Segment<K,V>[] segments; 5 6 transient Set<K> keySet; 7 transient Set<Map.Entry<K,V>> entrySet;
Segment 是 ConcurrentHashMap 的一个内部类,主要的组成以下:
1 static final class Segment<K,V> extends ReentrantLock implements Serializable { 2 3 private static final long serialVersionUID = 2249069246763182397L; 4 5 // 和 HashMap 中的 HashEntry 做用同样,真正存放数据的桶 6 transient volatile HashEntry<K,V>[] table; 7 8 transient int count; 9 10 transient int modCount; 11 12 transient int threshold; 13 14 final float loadFactor; 15 16 }
看看其中 HashEntry 的组成:
和 HashMap 很是相似,惟一的区别就是其中的核心数据如 value ,以及链表都是 volatile 修饰的,保证了获取时的可见性。
原理上来讲:ConcurrentHashMap 采用了分段锁技术,其中 Segment 继承于 ReentrantLock。不会像 HashTable 那样不论是 put 仍是 get 操做都须要作同步处理,理论上 ConcurrentHashMap 支持 CurrencyLevel (Segment 数组数量)的线程并发。每当一个线程占用锁访问一个 Segment 时,不会影响到其余的 Segment。
下面也来看看核心的 put get
方法。
1 public V put(K key, V value) { 2 Segment<K,V> s; 3 if (value == null) 4 throw new NullPointerException(); 5 int hash = hash(key); 6 int j = (hash >>> segmentShift) & segmentMask; 7 if ((s = (Segment<K,V>)UNSAFE.getObject // nonvolatile; recheck 8 (segments, (j << SSHIFT) + SBASE)) == null) // in ensureSegment 9 s = ensureSegment(j); 10 return s.put(key, hash, value, false); 11 }
首先是经过 key 定位到 Segment,以后在对应的 Segment 中进行具体的 put。
1 final V put(K key, int hash, V value, boolean onlyIfAbsent) { 2 HashEntry<K,V> node = tryLock() ? null : 3 scanAndLockForPut(key, hash, value); 4 V oldValue; 5 try { 6 HashEntry<K,V>[] tab = table; 7 int index = (tab.length - 1) & hash; 8 HashEntry<K,V> first = entryAt(tab, index); 9 for (HashEntry<K,V> e = first;;) { 10 if (e != null) { 11 K k; 12 if ((k = e.key) == key || 13 (e.hash == hash && key.equals(k))) { 14 oldValue = e.value; 15 if (!onlyIfAbsent) { 16 e.value = value; 17 ++modCount; 18 } 19 break; 20 } 21 e = e.next; 22 } 23 else { 24 if (node != null) 25 node.setNext(first); 26 else 27 node = new HashEntry<K,V>(hash, key, value, first); 28 int c = count + 1; 29 if (c > threshold && tab.length < MAXIMUM_CAPACITY) 30 rehash(node); 31 else 32 setEntryAt(tab, index, node); 33 ++modCount; 34 count = c; 35 oldValue = null; 36 break; 37 } 38 } 39 } finally { 40 unlock(); 41 } 42 return oldValue; 43 }
虽然 HashEntry 中的 value 是用 volatile 关键词修饰的,可是并不能保证并发的原子性,因此 put 操做时仍然须要加锁处理。
首先第一步的时候会尝试获取锁,若是获取失败确定就有其余线程存在竞争,则利用 scanAndLockForPut()
自旋获取锁。
MAX_SCAN_RETRIES
则改成阻塞锁获取,保证能获取成功。再结合图看看 put 的流程。
1 public V get(Object key) { 2 Segment<K,V> s; // manually integrate access methods to reduce overhead 3 HashEntry<K,V>[] tab; 4 int h = hash(key); 5 long u = (((h >>> segmentShift) & segmentMask) << SSHIFT) + SBASE; 6 if ((s = (Segment<K,V>)UNSAFE.getObjectVolatile(segments, u)) != null && 7 (tab = s.table) != null) { 8 for (HashEntry<K,V> e = (HashEntry<K,V>) UNSAFE.getObjectVolatile 9 (tab, ((long)(((tab.length - 1) & h)) << TSHIFT) + TBASE); 10 e != null; e = e.next) { 11 K k; 12 if ((k = e.key) == key || (e.hash == h && key.equals(k))) 13 return e.value; 14 } 15 } 16 return null; 17 }
get 逻辑比较简单:
只须要将 Key 经过 Hash 以后定位到具体的 Segment ,再经过一次 Hash 定位到具体的元素上。
因为 HashEntry 中的 value 属性是用 volatile 关键词修饰的,保证了内存可见性,因此每次获取时都是最新值。
ConcurrentHashMap 的 get 方法是很是高效的,由于整个过程都不须要加锁。
1.7 已经解决了并发问题,而且能支持 N 个 Segment 这么屡次数的并发,但依然存在 HashMap 在 1.7 版本中的问题。
那就是查询遍历链表效率过低。
所以 1.8 作了一些数据结构上的调整。
首先来看下底层的组成结构:
看起来是否是和 1.8 HashMap 结构相似?
其中抛弃了原有的 Segment 分段锁,而采用了 CAS + synchronized
来保证并发安全性。
也将 1.7 中存放数据的 HashEntry 改成 Node,但做用都是相同的。
其中的 val next
都用了 volatile 修饰,保证了可见性。
重点来看看 put 函数:
f
即为当前 key 定位出的 Node,若是为空表示当前位置能够写入数据,利用 CAS 尝试写入,失败则自旋保证成功。hashcode == MOVED == -1
,则须要进行扩容。TREEIFY_THRESHOLD
则要转换为红黑树。
1.8 在 1.7 的数据结构上作了大的改动,采用红黑树以后能够保证查询效率(
O(logn)
),甚至取消了 ReentrantLock 改成了 synchronized,这样能够看出在新版的 JDK 中对 synchronized 优化是很到位的。
看完了整个 HashMap 和 ConcurrentHashMap 在 1.7 和 1.8 中不一样的实现方式相信你们对他们的理解应该会更加到位。
其实这块也是面试的重点内容,一般的套路是:
这一串问题相信你们仔细看完都能怼回面试官。
除了面试会问到以外平时的应用其实也蛮多,像以前谈到的 Guava 中 Cache 的实现就是利用 ConcurrentHashMap 的思想。
同时也能学习 JDK 做者大牛们的优化思路以及并发解决方案。
最近在总结一些 Java 相关的知识点,感兴趣的朋友能够一块儿维护。
地址: https://github.com/crossoverJie/Java-Interview