HashMap，Hashtable，ConcurrentHashMap 相关问题小结

HashMap和Hashtable的区别有哪些？

• HashMap没有考虑同步，是线程不安全的；Hashtable使用了synchronized关键字，是线程安全的
• HashMap允许null作为Key；Hashtable不允许null作为Key，Hashtable的value也不可以为null

HashMap是线程不安全的是吧？你可以举一个例子吗？

• HashMap线程不安全主要是考虑到了多线程环境下进行扩容可能会出现HashMap死循环
• Hashtable线程安全是由于其内部实现在put和remove等方法上使用synchronized进行了同步，所以对单个方法的使用是线程安全的。但是对多个方法进行复合操作时，线程安全性无法保证。 比如一个线程在进行get然后put更新的操作，这就是两个复合操作，在两个操作之间，可能别的线程已经对这个key做了改动，所以，你接下来的put操作可能会不符合预期

Java集合中的快速失败（fast-fail）机制？

快速失败是Java集合的一种错误检测机制，当多个线程对集合进行结构上的改变的操作时，有可能会产生fail-fast。

例如：

• 假设存在两个线程（线程1、线程2），线程1通过Iterator在遍历集合A中的元素，在某个时候线程2修改了集合A的结构（是结构上面的修改，而不是简单的修改集合元素的内容），那么这个时候程序就可能会抛出 ConcurrentModificationException异常，从而产生fast-fail快速失败

那么快速失败机制底层是怎么实现的呢？

迭代器在遍历时直接访问集合中的内容，并且在遍历过程中使用一个 modCount 变量。集合在被遍历期间如果内容发生变化，就会改变modCount的值。当迭代器使用hashNext()/next()遍历下一个元素之前，都会检测modCount变量是否为expectedModCount值，是的话就返回遍历；否则抛出异常，终止遍历。JDK源码中的判断大概是这样的：

• ConcurrentModificationException，JDK中是这么介绍该异常的：
  

• 当检测到一个并发的修改，就可能会抛出该异常，一些迭代器的实现会抛出该异常，以便可以快速失败。但是你不可以为了便捷而依赖该异常，而应该仅仅作为一个程序的侦测。

• 以往错误的认为快速机制就是HashMap线程不安全的表现。并且坚定的认为Hashtable和Vector等线程安全的集合不会存在并发修改时候的快速失败，这是大错特错。概念和原理理解的不清晰导致掉入了面试官的陷阱里了，大家可以打开JDK源码，会发现Hashtable也会在迭代的时候抛出该异常，可能发生快速失败

HashMap底层实现结构有了解吗？

个人之前的博客HashMap图解

HashMap的长度为什么是2的幂次方？

• 我们将一个键值对插入HashMap中，通过将Key的hash值与length-1进行&运算，实现了当前Key的定位，2的幂次方可以减少冲突（碰撞）的次数，提高HashMap查询效率
• 如果length为2的幂次方，则length-1 转化为二进制必定是11111……的形式，在与h的二进制与操作效率会非常的快，而且空间不浪费
• 如果length不是2的幂次方，比如length为15，则length-1为14，对应的二进制为1110，在与h与操作，最后一位都为0，而0001，0011，0101，1001，1011，0111，1101这几个位置永远都不能存放元素了，空间浪费相当大，更糟的是这种情况中，数组可以使用的位置比数组长度小了很多，这意味着进一步增加了碰撞的几率，减慢了查询的效率！这样就会造成空间的浪费

HasMap的扩容步骤？

HashMap里面默认的负载因子大小为0.75，也就是说，当Map中的元素个数**（包括数组，链表和红黑树中）超过了16*0.75=12之后开始扩容。将会创建原来HashMap大小的两倍的bucket数组，来重新调整map的大小，并将原来的对象放入新的bucket数组中。这个过程叫作rehashing**，因为它调用hash方法找到新的bucket位置。

当然了，上述的扩容机制是比较低效的。所以，我们伟大的JDK开发人员在1.8版本中做了一个扩容效率方面的优化。因为是2的N次幂扩容，所以一个元素要么在原位置不动，要么移动到当前位置+2的N次幂（也就是oldIndex+OldCap的位置）。
怎么实现呢？

• 就是通过新增的bit位置上是0还是1来判断。
• 0则是原位置，1则是oldIndex+OldCap位置。

这个设计确实非常的巧妙，既省去了重新计算hash值的时间，而且同时，由于新增的1bit是0还是1可以认为是随机的，因此resize的过程，均匀的把之前的冲突的节点分散到新的bucket了。

但是，需要注意的是在多线程环境下，HashMap扩容可能会导致死循环

解决Hash冲突的方法有哪些？

• 拉链法 （HashMap使用的方法）
• 线性探测再散列法
• 二次探测再散列法
• 伪随机探测再散列法

哪些类适合作为HashMap的键？

String和Interger这样的包装类很适合做为HashMap的键，因为他们是final类型的类，而且重写了equals和hashCode方法，避免了键值对改写，有效提高HashMap性能
为了计算hashCode()，就要防止键值改变，如果键值在放入时和获取时返回不同的hashCode的话，那么就不能从HashMap中找到你想要的对象

ConcurrentHashMap和Hashtable的区别？

ConcurrentHashMap结合了HashMap和Hashtable二者的优势 ,HashMap没有考虑同步，Hashtable考虑了同步的问题。但是Hashtable在每次同步执行时都要锁住整个结构

ConcurrentHashMap锁的方式是稍微细粒度的，ConcurrentHashMap将hash表分为16个桶（默认值），诸如get，put，remove等常用操作只锁上当前需要用到的桶

ConcurrentHashMap的具体实现方式(分段锁) (JDK1.7及之前)：

• 该类包含两个静态内部类MapEntry和Segment，前者用来封装映射表的键值对，后者用来充当锁的角色

• Segment是一种可重入的锁ReentrantLock，每个Segment守护一个HashEntry数组里的元素，当对HashEntry数组的数据进行修改时，必须首先获得对应的Segment锁。

---

HashMap的类图结构：

Hashtable的类图结构：

ConcurrentHashMap的类图结构：

---

推荐：

一致性哈希算法讲解

ConcurrentHashMap源码解析（JDK1.7及之前版本）

ConcurrentHashMap源码解析（jdk1.8）

谈谈ConcurrentHashMap1.7和1.8的不同实现

hashmap扩容时出现死循环问题

HashMap在jdk1.8也会出现死循环的问题（实测）