对于HashMap问题的一些解答

Posted 2020-10-04

1.当发生冲突时，为什么把最新值放在链表的头而不是表尾？

　答：原因是为了提高效率，放在头部就不需要遍历整个链表了，放在尾部必须得遍历整个链表再进行插入操作。

2.为什么哈希表的容量一定要是2的整数次幂？

　答：先看一下存储数据时如何得到数组的索引：

1     static int indexFor(int h, int length) { //根据hash值和数组长度算出索引值
2         return h & (length-1);  //这里不能随便算取，用hash&(length-1)是有原因的，这样可以确保算出来的索引是在数组大小范围内，不会超出
3     }

说一下，这里h&(length-1)作用其实和hashcode对对数组大小进行取模的值是一样的，而且取模的效率很低，这样处理后，不仅使元素均匀散列，还极大的提高了效率。

那么为什么哈希表的容量一定要是2的整数次幂呢。首先，length为2的整数次幂的话，h&(length-1)就相当于对length取模，这样便保证了散列的均匀，同时也提升了效率；其次，length为2的整数次幂的话，为偶数，这样length-1为奇数，奇数的最后一位是1，这样便保证了h&(length-1)的最后一位可能为0，也可能为1（这取决于h的值），即与后的结果可能为偶数，也可能为奇数，这样便可以保证散列的均匀性，而如果length为奇数的话，很明显length-1为偶数，它的最后一位是0，这样h&(length-1)的最后一位肯定为0，即只能为偶数，这样任何hash值都只会被散列到数组的偶数下标位置上，这便浪费了近一半的空间，因此，length取2的整数次幂，是为了使不同hash值发生碰撞的概率较小，这样就能使元素在哈希表中均匀地散列。相对的，查询的时候就不用遍历某个位置上的链表，这样查询效率也就较高了。

3.简述一下HashMap的实现原理

答：HashMap的底层是用数组加链表实现的，HashMap的实现采用了除留余数法形式的哈希函数和链地址法解决哈希地址冲突的方案。数组的索引就是对应的哈希地址，存放        的是链表的头结点即插入链表中的最后一个元素，链表存放的是哈希地址冲突的不同记录。链表的结点设计如下：

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

next作为引用指向下一个记录。在HashMap中设计了一个Entry类型的数组用来存放Entry的实例即链表结点。

当我们往HashMap中put元素的时候，先根据key的hashCode重新计算hash值，根据hash值得到这个元素在数组中的位置（即下标），如果数组该位置上已经存放有其他元素了，那么在这个位置上的元素将以链表的形式存放，新加入的放在链头，最先加入的放在链尾，数组中存储的是最后插入的元素 。如果数组该位置上没有元素，就直接将该元素放到此数组中的该位置上。

4.如果两个键的hashcode相同，你如何获取值对象 

HashMap在链表中存储的是键值对，找到哈希地址位置之后，会调用keys.equals()方法去找到链表中正确的节点，最终找到要找的值对象

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)];//根据数组下标返回一个Entry数组，然后循环判断key的值
             e != null;
             e = e.next) {
            Object k;
            if (e.hash == hash &&
                ((k = e.key) == key || (key != null && key.equals(k))))
                return e;
        }
        return null;
    }

5.如果HashMap的大小超过了负载因子(load factor)定义的容量，怎么办 ？

HashMap默认的负载因子大小为0.75，也就是说，当一个map填满了75%的空间的时候，便会进行扩容：

//扩容的方法
void resize(int newCapacity) {
        Entry[] oldTable = table;
        int oldCapacity = oldTable.length;
        if (oldCapacity == MAXIMUM_CAPACITY) {
            threshold = Integer.MAX_VALUE;
            return;
        }

        Entry[] newTable = new Entry[newCapacity];//创建一个原来两倍的数组
        transfer(newTable, initHashSeedAsNeeded(newCapacity));// 把数组中所以元素再次进行hashcode计算，放入新的数组中
        table = newTable;
        threshold = (int)Math.min(newCapacity * loadFactor, MAXIMUM_CAPACITY + 1);
    }

//将当前table中的元素转移到新的table中
void transfer(Entry[] newTable, boolean rehash) {
        int newCapacity = newTable.length;
        for (Entry<K,V> e : table) {
            while(null != e) {
                Entry<K,V> next = e.next;
                if (rehash) {
                    e.hash = null == e.key ? 0 : hash(e.key);
                }
                int i = indexFor(e.hash, newCapacity);
                e.next = newTable[i];
                newTable[i] = e;
                e = next;
            }
        }
    }

6.为什么String, Interger这样的wrapper类适合作为键？

String, Interger这样的wrapper类是final类型的，具有不可变性，而且已经重写了equals()和hashCode()方法了。其他的wrapper类也有这个特点。不可变性是必要的，因为为了要计算hashCode()，就要防止键值改变，如果键值在放入时和获取时返回不同的hashcode的话，那么就不能从HashMap中找到你想要的对象。 

7.ConcurrentHashMap和Hashtable的区别？

在迭代的过程中，ConcurrentHashMap仅仅锁定map的某个部分，而Hashtable则会锁定整个map。所以当Hashtable大小到一定程度时，性能急剧下载。

这里我想仔细说一下ConcurrentHashMap，因为它很重要！在Java1.7及以前，ConcurrentHashMap使用了锁分段机制。ConcurrentHashMap有一个Segment内部类，继承了ReentrantLock：

static final class Segment<K,V> extends ReentrantLock implements Serializable {
        private static final long serialVersionUID = 2249069246763182397L;

        static final int MAX_SCAN_RETRIES =
            Runtime.getRuntime().availableProcessors() > 1 ? 64 : 1;

        transient volatile HashEntry<K,V>[] table;

        transient int count;

        transient int modCount;

        transient int threshold;

        final float loadFactor;

        Segment(float lf, int threshold, HashEntry<K,V>[] tab) {
            this.loadFactor = lf;
            this.threshold = threshold;
            this.table = tab;
        }
        ......  
}    

　　public V put(K key, V value) {
        Segment<K,V> s;
        if (value == null)
            throw new NullPointerException();
        int hash = hash(key);
        int j = (hash >>> segmentShift) & segmentMask;
        if ((s = (Segment<K,V>)UNSAFE.getObject          // nonvolatile; recheck
             (segments, (j << SSHIFT) + SBASE)) == null) //  in ensureSegment
            s = ensureSegment(j);
        return s.put(key, hash, value, false);
    }

从ConcurrentHashMap的put的方法可以看出，它其实是把值存在了Segment类的HashEntry<K,V> 数组里面了。

ConcurrentHashMap中的HashEntry相对于HashMap中的Entry有一定的差异性：HashEntry中的value以及next都被volatile修饰，这样在多线程读写过程中能够保持它们的可见性，代码如下：

static final class HashEntry<K,V> {
        final int hash;
        final K key;
        volatile V value;
        volatile HashEntry<K,V> next;
　　　　 ......
}

接下来介绍一下ConcurrentHashMap的rehash：

相对于HashMap的resize，ConcurrentHashMap的rehash原理类似，但是Doug Lea为rehash做了一定的优化，避免让所有的节点都进行复制操作：由于扩容是基于2的幂指来操作，假设扩容前某HashEntry对应到Segment中数组的index为i，数组的容量为capacity，那么扩容后该HashEntry对应到新数组中的index只可能为i或者i+capacity，因此大多数HashEntry节点在扩容前后index可以保持不变。基于此，rehash方法中会定位第一个后续所有节点在扩容后index都保持不变的节点，然后将这个节点之前的所有节点重排即可。

private void rehash(HashEntry<K,V> node) {
            HashEntry<K,V>[] oldTable = table;
            int oldCapacity = oldTable.length;
            int newCapacity = oldCapacity << 1;
            threshold = (int)(newCapacity * loadFactor);
            HashEntry<K,V>[] newTable =
                (HashEntry<K,V>[]) new HashEntry[newCapacity];
            int sizeMask = newCapacity - 1;
            for (int i = 0; i < oldCapacity ; i++) {
                HashEntry<K,V> e = oldTable[i];
                if (e != null) {
                    HashEntry<K,V> next = e.next;
                    int idx = e.hash & sizeMask;
                    if (next == null)   //  Single node on list
                        newTable[idx] = e;
                    else { // Reuse consecutive sequence at same slot
                        HashEntry<K,V> lastRun = e;
                        int lastIdx = idx;
                        for (HashEntry<K,V> last = next;
                             last != null;
                             last = last.next) {
                            int k = last.hash & sizeMask;
                            if (k != lastIdx) {
                                lastIdx = k;
                                lastRun = last;
                            }
                        }
                        newTable[lastIdx] = lastRun;
                        // Clone remaining nodes
                        for (HashEntry<K,V> p = e; p != lastRun; p = p.next) {
                            V v = p.value;
                            int h = p.hash;
                            int k = h & sizeMask;
                            HashEntry<K,V> n = newTable[k];
                            newTable[k] = new HashEntry<K,V>(h, p.key, v, n);
                        }
                    }
                }
            }
            int nodeIndex = node.hash & sizeMask; // add the new node
            node.setNext(newTable[nodeIndex]);
            newTable[nodeIndex] = node;
            table = newTable;
        }

JDK8：

ConcurrentHashMap在JDK8中进行了巨大改动，它摒弃了Segment（锁段）的概念，而是启用了一种全新的方式实现,利用CAS算法。它沿用了与它同时期的HashMap版本的思想，底层依然由“数组”+链表+红黑树的方式思想。这里只做一点简单的介绍，详细说的话太多了。Java8中的实现也是锁分离思想，只是锁住的是一个Node，Node是最核心的内部类，它包装了key-value键值对，所有插入ConcurrentHashMap的数据都包装在这里面。

 static class Node<K,V> implements Map.Entry<K,V> {
        final int hash;
        final K key;
        volatile V val;
        volatile Node<K,V> next;
        ......
}    

在ConcurrentHashMap中，随处可以看到U, 大量使用了U.compareAndSwapXXX的方法，这个方法是利用一个CAS算法实现无锁化的修改值的操作，他可以大大降低锁代理的性能消耗。至于红黑树，当加入这个节点以后链表的长度达到了8并且容量达到64时，就将链表转为红黑树

if (binCount >= TREEIFY_THRESHOLD)  //TREEIFY_THRESHOLD = 8
 treeifyBin(tab, i);

private final void treeifyBin(Node<K,V>[] tab, int index) {
        Node<K,V> b; int n, sc;
        if (tab != null) {
            if ((n = tab.length) < MIN_TREEIFY_CAPACITY)
                tryPresize(n << 1);// 容量<64，则table两倍扩容，不转树了
　　　　　　　　　　else if ((b = tabAt(tab, index)) != null && b.hash >= 0) { 
                    synchronized (b) {
                         if (tabAt(tab, index) == b) {
                              ...... 
}

8.ConcurrentHashMap已经那么好了，是不是Hashtable就没有存在的理由呢？

在迭代时，ConcurrentHashMap使用了不同于传统集合的快速失败迭代器的另一种迭代方式，我们称为弱一致迭代器（在put完后不能立刻得到新的数据）。在这种迭代方式中，当iterator被创建后集合再发生改变就不再是抛出ConcurrentModificationException，取而代之的是在改变时new新的数据从而不影响原有的数据，iterator完成后再将头指针替换为新的数据，这样iterator线程可以使用原来老的数据，而写线程也可以并发的完成改变，更重要的，这保证了多个线程并发执行的连续性和扩展性，是性能提升的关键。然而弱一致性正是它不能取代Hashtable的原因：ConcurrentHashMap的get，iterator 都是弱一致性的。 Doug Lea 也将这个判断留给用户自己决定是否使用ConcurrentHashMap。以上就是理由啦。那么为啥get是弱一致性呢：因为get操作几乎所有时候都是一个无锁操作（get中有一个readValueUnderLock调用，不过这句执行到的几率极小），使得同一个Segment实例上的put和get可以同时进行，这就是get操作是弱一致的根本原因。

public V get(Object key) {
        Segment<K,V> s; // manually integrate access methods to reduce overhead
        HashEntry<K,V>[] tab;
        int h = hash(key);
        long u = (((h >>> segmentShift) & segmentMask) << SSHIFT) + SBASE;
        if ((s = (Segment<K,V>)UNSAFE.getObjectVolatile(segments, u)) != null &&
            (tab = s.table) != null) {
            for (HashEntry<K,V> e = (HashEntry<K,V>) UNSAFE.getObjectVolatile
                     (tab, ((long)(((tab.length - 1) & h)) << TSHIFT) + TBASE);
                 e != null; e = e.next) {
                K k;
                if ((k = e.key) == key || (e.hash == h && key.equals(k)))
                    return e.value;
            }
        }
        return null;
    }

9.HashMap使用那种遍历方式最优？

第一种:
　　Map map = new HashMap();
　　Iterator iter = map.entrySet().iterator();
　　while (iter.hasNext()) {
　　　　Map.Entry entry = (Map.Entry) iter.next();
　　　　Object key = entry.getKey();
　　　　Object val = entry.getValue();
　　}
　　效率高,以后一定要使用此种方式！
第二种:
　　Map map = new HashMap();
　　　　Iterator iter = map.keySet().iterator();
　　　　while (iter.hasNext()) {
　　　　Object key = iter.next();
　　　　Object val = map.get(key);
　　}

可是为什么第一种比第二种方法效率更高呢？

HashMap这两种遍历方法是分别对keyset及entryset来进行遍历，但是对于keySet其实是遍历了2次，一次是转为iterator，一次就从hashmap中取出key所对于的value。而entryset只是遍历了第一次，它把key和value都放到了entry中，即键值对，所以就快了。

参考文章：

http://www.cnblogs.com/ITtangtang/p/3948406.html

http://blog.csdn.net/song19890528/article/details/16891015

http://www.importnew.com/22007.html

https://my.oschina.net/hosee/blog/675423