Java集合专题总结（1）：HashMap 和 HashTable 源码学习和面试总结

2017年的秋招完全结束了，感受Java上面的最多见的集合相关的问题就是hash……系列和一些经常使用并发集合和队列，堆等结合算法一块儿考察，不彻底统计，本人经历：前后百度、惟品会、58同城、新浪微博、趣分期、美团点评等都在一、2……面的时候被问过无数次，都问吐了&_&，其余公司笔试的时候，但凡是有Java的题，都有集合相关考点，尤为hash表……如今总结下。

• 2016-12-15 更新：Java 8 对 HashMap 的改进
• 2016-12-12 整理jdk 1.8以前的HashMap实现

 

2016-12-15 更新：Java 8 对 HashMap 的改进

若是说Java的hashmap是数组+链表，那么JDK 8以后就是数组+链表+红黑树组成了hashmap。以前的实现机制和原理在下面12-12期整理过，此次只说下新加的红黑树机制。

在以前谈过，若是hash算法很差，会使得hash表蜕化为顺序查找，即便负载因子和hash算法优化再多，也没法避免出现链表过长的情景（这个概论虽然很低），因而在JDK1.8中，对hashmap作了优化，引入红黑树。具体原理就是当hash表中每一个桶附带的链表长度默认超过8时，链表就转换为红黑树结构，提升HashMap的性能，由于红黑树的增删改是O(logn)，而不是O(n)。

红黑树的具体原理和实现之后再总结。

主要看put方法实现

    public V put(K key, V value) {
        return putVal(hash(key), key, value, false, true);
    }

put方法

封装了一个final方法，里面用到一个常量，具体用处看源码：

static final int TREEIFY_THRESHOLD = 8;

下面是具体源代码注释:

 1     final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
 2                    boolean evict) {
 3         Node<K,V>[] tab; Node<K,V> p; int n, i;
 4         if ((tab = table) == null || (n = tab.length) == 0) // 首先判断hash表是不是空的，若是空，则resize扩容
 5             n = (tab = resize()).length;
 6         if ((p = tab[i = (n - 1) & hash]) == null) // 经过key计算获得hash表下标，若是下标处为null，就新建链表头结点，在方法最后插入便可
 7             tab[i] = newNode(hash, key, value, null);
 8         else { // 若是下标处已经存在节点，则进入到这里
 9             Node<K,V> e; K k;
10             if (p.hash == hash &&
11                 ((k = p.key) == key || (key != null && key.equals(k)))) // 先看hash表该处的头结点是否和key同样（hashcode和equals比较），同样就更新
12                 e = p;
13             else if (p instanceof TreeNode) // hash表头结点和key不同，则判断节点是否是红黑树，是红黑树就按照红黑树处理
14                 e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
15             else { // 若是不是红黑树，则按照以前的hashmap原理处理
16                 for (int binCount = 0; ; ++binCount) { // 遍历链表
17                     if ((e = p.next) == null) {
18                         p.next = newNode(hash, key, value, null);
19                         if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st (原jdk注释) 显然当链表长度大于等于7的时候，也就是说大于8的话，就转化为红黑树结构，针对红黑树进行插入（logn复杂度）
20                             treeifyBin(tab, hash);
21                         break;
22                     }
23                     if (e.hash == hash &&
24                         ((k = e.key) == key || (key != null && key.equals(k)))) 
25                         break;
26                     p = e;
27                 }
28             }
29             if (e != null) { // existing mapping for key
30                 V oldValue = e.value;
31                 if (!onlyIfAbsent || oldValue == null)
32                     e.value = value;
33                 afterNodeAccess(e);
34                 return oldValue;
35             }
36         }
37         ++modCount;
38         if (++size > threshold) // 若是超过容量，即扩容
39             resize();
40         afterNodeInsertion(evict);
41         return null;
42     }

View Code

resize是新的扩容方法，以前谈过，扩容原理是使用新的（2倍旧长度）的数组代替，把旧数组的内容放到新数组，须要从新计算hash和计算hash表的位置，很是耗时，可是自从 JDK 1.8 对hashmap 引入了红黑树，它和以前的扩容方法有了改进。

扩容方法的改进

 1     final Node<K,V>[] resize() {
 2         Node<K,V>[] oldTab = table;
 3         int oldCap = (oldTab == null) ? 0 : oldTab.length;
 4         int oldThr = threshold;
 5         int newCap, newThr = 0;
 6         if (oldCap > 0) {
 7             if (oldCap >= MAXIMUM_CAPACITY) {
 8                 threshold = Integer.MAX_VALUE;
 9                 return oldTab;
10             }
11             else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY && 
12                      oldCap >= DEFAULT_INITIAL_CAPACITY) // 若是长度没有超过最大值，则扩容为2倍的关系
13                 newThr = oldThr << 1; // double threshold
14         }
15         else if (oldThr > 0) // initial capacity was placed in threshold
16             newCap = oldThr;
17         else {               // zero initial threshold signifies using defaults
18             newCap = DEFAULT_INITIAL_CAPACITY;
19             newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
20         }
21         if (newThr == 0) {
22             float ft = (float)newCap * loadFactor;
23             newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
24                       (int)ft : Integer.MAX_VALUE);
25         }
26         threshold = newThr;
27         @SuppressWarnings({"rawtypes","unchecked"})
28             Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
29         table = newTab;
30         if (oldTab != null) { // 进行新旧元素的转移过程
31             for (int j = 0; j < oldCap; ++j) {
32                 Node<K,V> e;
33                 if ((e = oldTab[j]) != null) {
34                     oldTab[j] = null;
35                     if (e.next == null)
36                         newTab[e.hash & (newCap - 1)] = e;
37                     else if (e instanceof TreeNode) 
38                         ((TreeNode<K,V>)e).split(this, newTab, j, oldCap);
39                     else { // preserve order（原注释） 若是不是红黑树的状况这里改进了，没有rehash的过程，以下分别记录链表的头尾
40                         Node<K,V> loHead = null, loTail = null;
41                         Node<K,V> hiHead = null, hiTail = null;
42                         Node<K,V> next;
43                         do {
44                             next = e.next;
45                             if ((e.hash & oldCap) == 0) {
46                                 if (loTail == null)
47                                     loHead = e;
48                                 else
49                                     loTail.next = e;
50                                 loTail = e;
51                             }
52                             else {
53                                 if (hiTail == null)
54                                     hiHead = e;
55                                 else
56                                     hiTail.next = e;
57                                 hiTail = e;
58                             }
59                         } while ((e = next) != null);
60                         if (loTail != null) {
61                             loTail.next = null;
62                             newTab[j] = loHead;
63                         }
64                         if (hiTail != null) {
65                             hiTail.next = null;
66                             newTab[j + oldCap] = hiHead;
67                         }
68                     }
69                 }
70             }
71         }
72         return newTab;
73     }

View Code

由于有这样一个特色：好比hash表的长度是16，那么15对应二进制是：

0000 0000， 0000 0000， 0000 0000， 0000 1111 = 15

扩容以前有两个key，分别是k1和k2：

k1的hash：

0000 0000， 0000 0000， 0000 0000， 0000 1111 = 15

k2的hash：

0000 0000， 0000 0000， 0000 0000， 0001 1111 = 15

hash值和15模获得：

k1：0000 0000， 0000 0000， 0000 0000， 0000 1111 = 15

k2：0000 0000， 0000 0000， 0000 0000， 0000 1111 = 15

扩容以后表长对应为32，则31二进制：

0000 0000， 0000 0000， 0000 0000， 0001 1111 = 31

从新hash以后获得：

k1：0000 0000， 0000 0000， 0000 0000， 0000 1111 = 15

k2：0000 0000， 0000 0000， 0000 0000， 0001 1111 = 31 = 15 + 16

观察发现：若是扩容后新增的位是0，那么rehash索引不变，不然才会改变，而且变为原来的索引+旧hash表的长度，故咱们只需看原hash表长新增的bit是1仍是0，若是是0，索引不变，若是是1，索引变成原索引+旧表长，根本不用像JDK 7 那样rehash，省去了从新计算hash值的时间，并且新增的bit是0仍是1能够认为是随机的，所以resize的过程，还能均匀的把以前的冲突节点分散。 

故JDK 8对HashMap的优化是很是到位的。

 

以下是以前整理的旧hash的实现机制和原理，并和jdk古老的hashtable作了比较。

---

 

2016-12-12 整理jdk 1.8以前的HashMap实现：

• Java集合概述
• HashMap介绍
• HashMap源码学习
• 关于HashMap的几个经典问题
• HashTable介绍和源码学习
• HashMap 和 HashTable 比较

---

 

先上图

Set和List接口是Collection接口的子接口，分别表明无序集合和有序集合，Queue是Java提供的队列实现。

 

Map用于保存具备key-value映射关系的数据

Java 中有四种常见的Map实现——HashMap, TreeMap, Hashtable和LinkedHashMap：

• HashMap就是一张hash表，键和值都没有排序。
• TreeMap以红黑树结构为基础，键值能够设置按某种顺序排列。
• LinkedHashMap保存了插入时的顺序。
• Hashtable是同步的(而HashMap是不一样步的)。因此若是在线程安全的环境下应该多使用HashMap，而不是Hashtable，由于Hashtable对同步有额外的开销，不过JDK 5以后的版本可使用conncurrentHashMao代替HashTable。

本文重点总结HashMap，HashMap是基于哈希表实现的，每个元素是一个key-value对，其内部经过单链表解决冲突问题，容量不足（超过了阀值）时，一样会自动增加。

HashMap是非线程安全的，只用于单线程环境下，多线程环境下能够采用concurrent并发包下的concurrentHashMap。

HashMap 实现了Serializable接口，所以它支持序列化。

HashMap还实现了Cloneable接口，故能被克隆。

 

关于hashmap的用法，这里就再也不赘述了，只说原理和一些注意点。

HashMap的存储结构

紫色部分即表明哈希表自己（实际上是一个数组），数组的每一个元素都是一个单链表的头节点，链表是用来解决hash地址冲突的，若是不一样的key映射到了数组的同一位置处，就将其放入单链表中保存。

 

HashMap有四个构造方法，方法中有两个很重要的参数：初始容量和加载因子

这两个参数是影响HashMap性能的重要参数，其中容量表示哈希表中槽的数量（即哈希数组的长度），初始容量是建立哈希表时的容量（默认为16），加载因子是哈希表当前key的数量和容量的比值，当哈希表中的条目数超出了加载因子与当前容量的乘积时，则要对该哈希表提早进行 resize 操做（即扩容）。若是加载因子越大，对空间的利用更充分，可是查找效率会下降（链表长度会愈来愈长）；若是加载因子过小，那么表中的数据将过于稀疏（不少空间还没用，就开始扩容了），严重浪费。

JDK开发者规定的默认加载因子为0.75，由于这是一个比较理想的值。另外，不管指定初始容量为多少，构造方法都会将实际容量设为不小于指定容量的2的幂次方，且最大值不能超过2的30次方。

 

重点分析HashMap中用的最多的两个方法put和get的源码

 1     // 获取key对应的value
 2     public V get(Object key) {
 3         if (key == null)
 4             return getForNullKey();
 5         // 获取key的hash值
 6         int hash = hash(key.hashCode());
 7         // 在“该hash值对应的链表”上查找“键值等于key”的元素
 8         for (Entry<K, V> e = table[indexFor(hash, table.length)]; e != null; e = e.next) {
 9             Object k;
10             // 判断key是否相同
11             if (e.hash == hash && ((k = e.key) == key || key.equals(k)))
12                 return e.value;
13         }
14         // 没找到则返回null
15         return null;
16     }
17 
18     // 获取“key为null”的元素的值，HashMap将“key为null”的元素存储在table[0]位置，但不必定是该链表的第一个位置！
20     private V getForNullKey() {
21         for (Entry<K, V> e = table[0]; e != null; e = e.next) {
22             if (e.key == null)
23                 return e.value;
24         }
25         return null;
26     }

get方法源码

首先，若是key为null，则直接从哈希表的第一个位置table[0]对应的链表上查找。记住，key为null的键值对永远都放在以table[0]为头结点的链表中，固然不必定是存放在头结点table[0]中。若是key不为null，则先求的key的hash值，根据hash值找到在table中的索引，在该索引对应的单链表中查找是否有键值对的key与目标key相等，有就返回对应的value，没有则返回null。

 1     // 将“key-value”添加到HashMap中
 2     public V put(K key, V value) {
 3         // 若“key为null”，则将该键值对添加到table[0]中。
 4         if (key == null)
 5             return putForNullKey(value);
 6         // 若“key不为null”，则计算该key的哈希值，而后将其添加到该哈希值对应的链表中。
 7         int hash = hash(key.hashCode());
 8         int i = indexFor(hash, table.length);
 9         for (Entry<K, V> e = table[i]; e != null; e = e.next) {
10             Object k;
11             // 若“该key”对应的键值对已经存在，则用新的value取代旧的value。而后退出！
12             if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
13                 V oldValue = e.value;
14                 e.value = value;
15                 e.recordAccess(this);
16                 return oldValue;
17             }
18         }
19 
20         // 若“该key”对应的键值对不存在，则将“key-value”添加到table中
21         modCount++;
22         // 将key-value添加到table[i]处
23         addEntry(hash, key, value, i);
24         return null;
25     }

put方法源码

若是key为null，则将其添加到table[0]对应的链表中，若是key不为null，则一样先求出key的hash值，根据hash值得出在table中的索引，然后遍历对应的单链表，若是单链表中存在与目标key相等的键值对，则将新的value覆盖旧的value，且将旧的value返回，若是找不到与目标key相等的键值对，或者该单链表为空，则将该键值对插入到单链表的头结点位置（每次新插入的节点都是放在头结点的位置），该操做是有addEntry方法实现的，它的源码以下：

    // 新增Entry。将“key-value”插入指定位置，bucketIndex是位置索引。
    void addEntry(int hash, K key, V value, int bucketIndex) {
        // 保存“bucketIndex”位置的值到“e”中
        Entry<K, V> e = table[bucketIndex];
        // 设置“bucketIndex”位置的元素为“新Entry”，
        // 设置“e”为“新Entry的下一个节点”
        table[bucketIndex] = new Entry<K, V>(hash, key, value, e);
        // 若HashMap的实际大小 不小于 “阈值”，则调整HashMap的大小
        if (size++ >= threshold)
            resize(2 * table.length);
    }

View Code

注意这里倒数第三行的构造方法，将key-value键值对赋给table[bucketIndex]，并将其next指向元素e，这便将key-value放到了头结点中，并将以前的头结点接在了它的后面。该方法也说明，每次put键值对的时候，老是将新的该键值对放在table[bucketIndex]处（即头结点处）。两外注意最后两行代码，每次加入键值对时，都要判断当前已用的槽的数目是否大于等于阀值（容量*加载因子），若是大于等于，则进行扩容，将容量扩为原来容量的2倍。

 

重点来分析下求hash值和索引值的方法，这两个方法即是HashMap设计的最为核心的部分，两者结合能保证哈希表中的元素尽量均匀地散列。

由hash值找到对应索引的方法以下

    static int indexFor(int h, int length) {
        return h & (length-1);
     }

由于容量初始仍是设定都会转化为2的幂次。故可使用高效的位与运算替代模运算。下面会解释缘由。

 

计算hash值的方法以下

    
    static int hash(int h) {
            h ^= (h >>> 20) ^ (h >>> 12);
            return h ^ (h >>> 7) ^ (h >>> 4);
        }

JDK 的 HashMap 使用了一个 hash 方法对hash值使用位的操做，使hash值的计算效率很高。为何这样作？主要是由于若是直接使用hashcode值，那么这是一个int值（8个16进制数，共32位），int值的范围正负21亿多，可是hash表没有那么长，通常好比初始16，天然散列地址须要对hash表长度取模运算，获得的余数才是地址下标。假设某个key的hashcode是0AAA0000，hash数组长默认16，若是不通过hash函数处理，该键值对会被存放在hash数组中下标为0处，由于0AAA0000 & (16-1) = 0。过了一下子又存储另一个键值对，其key的hashcode是0BBB0000，获得数组下标依然是0，这就说明这是个实现得不好的hash算法，由于hashcode的1位全集中在前16位了，致使算出来的数组下标一直是0。因而明明key相差很大的键值对，却存放在了同一个链表里，致使之后查询起来比较慢（蜕化为了顺序查找）。故JDK的设计者使用hash函数的若干次的移位、异或操做，把hashcode的“1位”变得“松散”，很是巧妙。

 

下面是几个常见的面试题

说下hashmap的 扩容机制？

前面说了，hashmap的构造器里指明了两个对于理解HashMap比较重要的两个参数 int initialCapacity, float loadFactor,这两个参数会影响HashMap效率，HashMap底层采用的散列数组实现，利用initialCapacity这个参数咱们能够设置这个数组的大小，也就是散列桶的数量，可是若是须要Map的数据过多，在不断的add以后，这些桶可能都会被占满，这是有两种策略，一种是不改变Capacity，由于即便桶占满了，咱们仍是能够利用每一个桶附带的链表增长元素。可是这有个缺点，此时HaspMap就退化成为了LinkedList，使get和put方法的时间开销上升，这是就要采用另外一种方法：增长Hash桶的数量，这样get和put的时间开销又回退到近于常数复杂度上。Hashmap就是采用的该方法。

关于扩容。看hashmap的扩容方法，resize方法，它的源码以下

 1     // 从新调整HashMap的大小，newCapacity是调整后的单位
 2     void resize(int newCapacity) {
 3         Entry[] oldTable = table;
 4         int oldCapacity = oldTable.length;
 5         if (oldCapacity == MAXIMUM_CAPACITY) {
 6             threshold = Integer.MAX_VALUE;
 7             return;
 8         }
 9 
10         // 新建一个HashMap，将“旧HashMap”的所有元素添加到“新HashMap”中，
11         // 而后，将“新HashMap”赋值给“旧HashMap”。
12         Entry[] newTable = new Entry[newCapacity];
13         transfer(newTable);
14         table = newTable;
15         threshold = (int) (newCapacity * loadFactor);
16     }

扩容的resize方法

很明显，是重新建了一个HashMap的底层数组，长度为原来的两倍，然后调用transfer方法，将旧HashMap的所有元素添加到新的HashMap中（要从新计算元素在新的数组中的索引位置）。transfer方法的源码以下：

 1     // 将HashMap中的所有元素都添加到newTable中
 2     void transfer(Entry[] newTable) {
 3         Entry[] src = table;
 4         int newCapacity = newTable.length;
 5         for (int j = 0; j < src.length; j++) {
 6             Entry<K, V> e = src[j];
 7             if (e != null) {
 8                 src[j] = null;
 9                 do {
10                     Entry<K, V> next = e.next;
11                     int i = indexFor(e.hash, newCapacity);
12                     e.next = newTable[i];
13                     newTable[i] = e;
14                     e = next;
15                 } while (e != null);
16             }
17         }
18     }

transfer方法源码

很明显，扩容是一个至关耗时的操做，由于它须要从新计算这些元素在新的数组中的位置并进行复制处理。所以，咱们在用HashMap时，最好能提早预估下HashMap中元素的个数，这样有助于提升HashMap的性能。

 

hashmap何时须要增长容量呢？

由于效率问题，JDK采用预处理法，这时前面说的loadFactor就派上了用场，当size > initialCapacity * loadFactor，hashmap内部resize方法就被调用，使得从新扩充hash桶的数量，在目前的实现中，是增长一倍，这样就保证当你真正想put新的元素时效率不会明显降低。因此通常状况下HashMap并不存在键值放满的状况。固然并不排除极端状况，好比设置的JVM内存用完了，或者这个HashMap的Capacity已经达到了MAXIMUM_CAPACITY（目前的实现是2^30）。

 

initialCapacity和loadFactor参数设什么样的值好呢？

initialCapacity的默认值是16，有些人可能会想若是内存足够，是否是能够将initialCapacity设大一些，即便用不了这么大，就可避免扩容致使的效率的降低，反正不管initialCapacity大小，咱们使用的get和put方法都是常数复杂度的。这么说没什么不对，可是可能会忽略一点，实际的程序可能不只仅使用get和put方法，也有可能使用迭代器，如initialCapacity容量较大，那么会使迭代器效率下降。因此理想的状况仍是在使用HashMap前估计一下数据量。

加载因子默认值是0.75，是JDK权衡时间和空间效率以后获得的一个相对优良的数值。若是这个值过大，虽然空间利用率是高了，可是对于HashMap中的一些方法的效率就降低了，包括get和put方法，会致使每一个hash桶所附加的链表增加，影响存取效率。若是比较小，除了致使空间利用率较低外没有什么坏处，只要有的是内存，毕竟如今大多数人把时间看的比空间重要。可是实际中仍是不多有人会将这个值设置的低于0.5。

 

HashMap的key和value都能为null么？若是k能为null，那么它是怎么样查找值的？

若是key为null，则直接从哈希表的第一个位置table[0]对应的链表上查找。记住，key为null的键值对永远都放在以table[0]为头结点的链表中。

 

HashMap中put值的时候若是发生了冲突，是怎么处理的？

JDK使用了链地址法，hash表的每一个元素又分别连接着一个单链表，元素为头结点，若是不一样的key映射到了相同的下标，那么就使用头插法，插入到该元素对应的链表。

 

HashMap的key是如何散列到hash表的？相比较HashTable有什么改进？

咱们通常对哈希表的散列很天然地会想到用hash值对length取模（即除留余数法），HashTable就是这样实现的，这种方法基本能保证元素在哈希表中散列的比较均匀，但取模会用到除法运算，效率很低，且hashtable直接使用了hashcode值，没有从新计算。

HashMap中则经过 h&(length-1) 的方法来代替取模，其中h是key的hash值，一样实现了均匀的散列，但效率要高不少，这也是HashMap对Hashtable的一个改进。

接下来，咱们分析下为何哈希表的容量必定要是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值发生碰撞的几率较小，这样就能使元素在哈希表中均匀地散列。

 

做为对比，在讨论一下Hashtable

HashTable一样是基于哈希表实现的，其实相似HashMap，只不过有些区别，HashTable一样每一个元素是一个key-value对，其内部也是经过单链表解决冲突问题，容量不足（超过了阀值）时，一样会自动增加。

HashTable比较古老， 是JDK1.0就引入的类，而HashMap 是 1.2 引进的 Map 的一个实现。

HashTable 是线程安全的，能用于多线程环境中。Hashtable一样也实现了Serializable接口，支持序列化，也实现了Cloneable接口，能被克隆。

Hashtable继承于Dictionary类，实现了Map接口。Dictionary是声明了操做"键值对"函数接口的抽象类。 有一点注意，HashTable除了线程安全以外（实际上是直接在方法上增长了synchronized关键字，比较古老，落后，低效的同步方式），还有就是它的key、value都不为null。另外Hashtable 也有 初始容量 和 加载因子。

    public Hashtable() {
        this(11, 0.75f);
    }

默认加载因子也是 0.75，HashTable在不指定容量的状况下的默认容量为11，而HashMap为16，Hashtable不要求底层数组的容量必定要为2的整数次幂，而HashMap则要求必定为2的整数次幂。由于HashTable是直接使用除留余数法定位地址。且Hashtable计算hash值，直接用key的hashCode()。

还要注意：前面说了Hashtable中key和value都不容许为null，而HashMap中key和value都容许为null（key只能有一个为null，而value则能够有多个为null）。但如在Hashtable中有相似put(null,null)的操做，编译一样能够经过，由于key和value都是Object类型，但运行时会抛出NullPointerException异常，这是JDK的规范规定的。

最后针对扩容：Hashtable扩容时，将容量变为原来的2倍加1，而HashMap扩容时，将容量变为原来的2倍。

 

下面是几个常见的笔试，面试题

HashTable和HashMap的区别有哪些？

HashMap和Hashtable都实现了Map接口，但决定用哪个以前先要弄清楚它们之间的分别。主要的区别有：线程安全性，同步(synchronization)，以及速度。

理解HashMap是Hashtable的轻量级实现（非线程安全的实现，hashtable是非轻量级，线程安全的），都实现Map接口，主要区别在于：

一、因为HashMap非线程安全，在只有一个线程访问的状况下，效率要高于HashTable

二、HashMap容许将null做为一个entry的key或者value，而Hashtable不容许。

三、HashMap把Hashtable的contains方法去掉了，改为containsValue和containsKey。由于contains方法容易让人引发误解。

四、Hashtable继承自陈旧的Dictionary类，而HashMap是Java1.2引进的Map 的一个实现。

五、Hashtable和HashMap扩容的方法不同，HashTable中hash数组默认大小11，扩容方式是 old*2+1。HashMap中hash数组的默认大小是16，并且必定是2的指数，增长为原来的2倍，没有加1。

六、二者经过hash值散列到hash表的算法不同，HashTbale是古老的除留余数法，直接使用hashcode，然后者是强制容量为2的幂，从新根据hashcode计算hash值，在使用hash  位与  （hash表长度 – 1），也等价取膜，但更加高效，取得的位置更加分散，偶数，奇数保证了都会分散到。前者就不能保证。

七、另外一个区别是HashMap的迭代器(Iterator)是fail-fast迭代器，而Hashtable的enumerator迭代器不是fail-fast的。因此当有其它线程改变了HashMap的结构（增长或者移除元素），将会抛出ConcurrentModificationException，但迭代器自己的remove()方法移除元素则不会抛出ConcurrentModificationException异常。但这并非一个必定发生的行为，要看JVM。这条一样也是Enumeration和Iterator的区别。

• fail-fast和iterator迭代器相关。若是某个集合对象建立了Iterator或者ListIterator，而后其它的线程试图“结构上”更改集合对象，将会抛出ConcurrentModificationException异常。但其它线程能够经过set()方法更改集合对象是容许的，由于这并无从“结构上”更改集合。可是假如已经从结构上进行了更改，再调用set()方法，将会抛出IllegalArgumentException异常。 
• 结构上的更改指的是删除或者插入一个元素，这样会影响到map的结构。
• 该条说白了就是在使用迭代器的过程当中有其余线程在结构上修改了map，那么将抛出ConcurrentModificationException，这就是所谓fail-fast策略。

 

为何HashMap是线程不安全的，实际会如何体现？

第一，若是多个线程同时使用put方法添加元素

假设正好存在两个put的key发生了碰撞(hash值同样)，那么根据HashMap的实现，这两个key会添加到数组的同一个位置，这样最终就会发生其中一个线程的put的数据被覆盖。

第二，若是多个线程同时检测到元素个数超过数组大小*loadFactor

这样会发生多个线程同时对hash数组进行扩容，都在从新计算元素位置以及复制数据，可是最终只有一个线程扩容后的数组会赋给table，也就是说其余线程的都会丢失，而且各自线程put的数据也丢失。且会引发死循环的错误。

具体细节上的缘由，能够参考：不正当使用HashMap致使cpu 100%的问题追究

 

可否让HashMap实现线程安全，如何作？

一、直接使用Hashtable，可是当一个线程访问HashTable的同步方法时，其余线程若是也要访问同步方法，会被阻塞住。举个例子，当一个线程使用put方法时，另外一个线程不但不可使用put方法，连get方法都不能够，效率很低，如今基本不会选择它了。

二、HashMap能够经过下面的语句进行同步：

Collections.synchronizeMap(hashMap);

三、直接使用JDK 5 以后的 ConcurrentHashMap，若是使用Java 5或以上的话，请使用ConcurrentHashMap。

 

Collections.synchronizeMap(hashMap);又是如何保证了HashMap线程安全？

直接分析源码吧

 1 // synchronizedMap方法
 2 public static <K,V> Map<K,V> synchronizedMap(Map<K,V> m) {
 3        return new SynchronizedMap<>(m);
 4    }
 5 // SynchronizedMap类
 6 private static class SynchronizedMap<K,V>
 7        implements Map<K,V>, Serializable {
 8        private static final long serialVersionUID = 1978198479659022715L;
 9  
10        private final Map<K,V> m;     // Backing Map
11        final Object      mutex;        // Object on which to synchronize
12  
13        SynchronizedMap(Map<K,V> m) {
14            this.m = Objects.requireNonNull(m);
15            mutex = this;
16        }
17  
18        SynchronizedMap(Map<K,V> m, Object mutex) {
19            this.m = m;
20            this.mutex = mutex;
21        }
22  
23        public int size() {
24            synchronized (mutex) {return m.size();}
25        }
26        public boolean isEmpty() {
27            synchronized (mutex) {return m.isEmpty();}
28        }
29        public boolean containsKey(Object key) {
30            synchronized (mutex) {return m.containsKey(key);}
31        }
32        public boolean containsValue(Object value) {
33            synchronized (mutex) {return m.containsValue(value);}
34        }
35        public V get(Object key) {
36            synchronized (mutex) {return m.get(key);}
37        }
38  
39        public V put(K key, V value) {
40            synchronized (mutex) {return m.put(key, value);}
41        }
42        public V remove(Object key) {
43            synchronized (mutex) {return m.remove(key);}
44        }
45        // 省略其余方法
46    }

View Code

从源码中看出 synchronizedMap()方法返回一个SynchronizedMap类的对象，而在SynchronizedMap类中使用了synchronized来保证对Map的操做是线程安全的，故效率其实也不高。

 

为何HashTable的默认大小和HashMap不同？

前面分析了，Hashtable 的扩容方法是乘2再+1，不是简单的乘2，故hashtable保证了容量永远是奇数，结合以前分析hashmap的重算hash值的逻辑，就明白了，由于在数据分布在等差数据集合(如偶数)上时，若是公差与桶容量有公约数 n，则至少有(n-1)/n 数量的桶是利用不到的，故以前的hashmap 会在取模（使用位与运算代替）哈希前先作一次哈希运算，调整hash值。这里hashtable比较古老，直接使用了除留余数法，那么就须要设置容量起码不是偶数（除（近似）质数求余的分散效果好）。而JDK开发者选了11。

 

JDK 8对HashMap有了什么改进？说说你对红黑树的理解？

参考更新的jdk 8对hashmap的的改进部分整理，而且还能引伸出高级数据结构——红黑树，这又能引出不少问题……学无止境啊！

 

临时小结：感受针对Java的hashmap和hashtable面试，或者理解，到这里就能够了，具体就是多写代码实践。