前言

Hashtable是java一开始发布时就提供的键值映射的数据结构，而HashMap产生于JDK1.2。虽然Hashtable比HashMap出现的早一些， 但是现在Hashtable基本上已经被弃用了。而HashMap已经成为应用最为广泛的一种数据类型了。

一、联系

HashMap继承自AbstractMap类，而HashTable继承自Dictionary类。它们都同时实现了Map（图）、Cloneable（可克隆）、Serializable（可序列化）这三个接口。Dictionary类现已被弃用，父类已被弃用，自然没有人使用它的子类Hashtable。

二、区别

1. 初始容量和每次扩充的容量不同

HashMap 的初始容量为：16，Hashtable 初始容量为：11，两者的负载因子默认都是：0.75

• HashMap每次扩充，容量变为原来的2倍；
• HashTable每次扩充，容量会变为原来的2倍+1；

下面给出HashMap中的源码：

拓展：什么是负载因子？

负载因子loadFactor = 哈希表的有效元素个数/哈希表长度

• 这个值越大就说明冲突越严重一些
• 这个值越小说明冲突越小，数组利用率越低

扩容：采用整表扩容的方式什么时候需要对数组扩容？

扩容与否就根据负载因子来决定，当==数组长度 * 负载因子 <= 有效元素个数==就需要扩容

HashMap中的源码：

2. 对外提供的接口不同

Hashtable比HashMap多提供了elments() 和contains() 两个方法。（某博主写到HashMap没有重写toString 其实两者都重写了toString方法的额）

• elements() 方法继承自Hashtable的父类Dictionnary。elements() 方法用于返回此Hashtable中的value的枚举。
• contains()方法判断该Hashtable是否包含传入的value。它的作用与containsValue()一致。事实上，contansValue() 就只是调用了一下contains() 方法。

3. 底层数组结构不同

• jdk1.7底层都是数组+链表,但jdk1.8 HashMap加入了红黑树，当链表长度大于阈值（默认为8）时，将链表转化为红黑树，以减少搜索时间。
• Hashtable 没有这样的机制。

4. 对null值的支持不同

• Hashtable：key和value都不能为null。
• HashMap： key可以为null，但是这样的key只能有一个，因为必须保证key的唯一性；
  可以有多个key值对应的value为null。

5. 计算hash值的方法不同

为了得到元素的位置，首先需要根据元素的 KEY计算出一个hash值，然后再用这个hash值来计算得到最终的位置。

• Hashtable中hash的计算方法为：直接使用对象的hashCode()。
• HashMap中hash的计算方法为：key的 hash 值高16位不变，低16位与高16位==异或==作为key最终的hash值。（h>>>16，表示无符号右移16位，高位补0）

Hashtable：

HashMap:

拓展：什么是hashCode？

hashCode是JDK根据对象的地址或者字符串或者数字算出来的int类型的数值。

两者为啥hash算法不一样？

• Hashtable在计算元素的位置时使用除留余数法来获得存储的最终的位置，而除法运算是比较耗时的。
• HashMap为了提高计算效率，将哈希表的大小固定为了2的倍数，这样在取模运算时，不需要做除法，只需要做位运算（左移一位就是乘以2）。位运算比除法的效率要高很多。
• HashMap的效率虽然提高了，但是hash冲突却也增加了。因为它得出的hash值的低位相同的概率比较高。
• 为了解决这个问题，HashMap重新根据hashcode计算hash值后，又将hash值无符号右移16位，使得运算出来所取得的位置分散到高低位中，从而减少了hash冲突。HashMap中采取的这种简单位运算操作，不会把使用2的幂次方带来的效率提升给抵消掉。

6. 线程安全性与效率不同

• Hashtable是线程安全的，它的每个方法中都加入了Synchronize方法。在多线程并发的环境下，可以直接使用Hashtable，不需要我们为它的方法实现同步，所以在单线程环境下它的效率要比HashMap低。
• HashMap是线程不安全的，在多线程并发的环境下，可能会产生死锁等问题。使用HashMap时需要自己增加同步处理，不过其效率比Hashtable高的多。
• 在我们的日常使用当中，大部分是单线程操作的，推荐使用HashMap。当需要多线程操作的时候可以使用线程安全的ConcurrentHashMap。
• ConcurrentHashMap虽然也是线程安全的，但是它的效率比Hashtable要高好多倍。因为ConcurrentHashMap使用了分段锁，并不对整个数据进行锁定。

拓展：什么是分段锁？

• ConcurrentHashMap 中的分段锁称为 Segment，它的内部结构是维护一个 HashEntry 数组，同时 Segment 还继承了 ReentrantLock。
• 当需要 put 元素的时候，并不是对整个 ConcurrentHashMap 进行加锁，而是先通过 hashcode 来判断它放在哪一个分段中，然后对该分段进行加锁。所以当多线程 put 的时候，只要不是放在同一个分段中，就可以实现并行的插入。分段锁的设计目的就是为了细化锁的粒度，从而提高并发能力。
• jdk1.8 中的 ConcurrentHashMap 中废弃了 Segment 锁，直接使用了数组元素，数组中的每个元素都可以作为一个锁。在元素中没有值的情况下，可以直接通过 CAS 操作来设值，同时保证并发安全；如果元素里面已经存在值的话，那么就使用 synchronized 关键字对元素加锁，再进行之后的 hash 冲突处理。jdk1.8 的 ConcurrentHashMap 加锁粒度比 jdk1.7 里的 Segment 来加锁粒度更细，并发性能更好。

7. 迭代器内部实现不同

Hashtable、HashMap都使用了 Iterator。Hashtable还使用了Enumeration的方式 。

Hashtable中的 Enumerator类，实现了Enumeration接口和Iterator接口：

HashMap中的Iterator：

拓展：JDK8之后，HashMap和Hashtable的Iterator都有fast-fail机制。

当有其它线程修改了HashMap的结构时，将会抛出ConcurrentModificationException异常。

==注：结构修改是指改变HashMap中的映射数量或以其他方式修改其内部结构 (如，重新哈希，增加，删除，修改元素)。==

什么是fast-fail机制？

• 例如，通常不允许一个线程在另一个线程迭代Collection时修改它。
• 通常，迭代的结果在这些情况下是没有定义的。如果检测到此行为，一些Iterator实现(包括JRE提供的所有通用集合实现)可能会选择抛出此异常。这样做的迭代器被称为快速失败迭代器，因为它们快速而干净地失败，而不是冒着在未来不确定的时间发生任意、不确定行为的风险。
• 迭代器中的modCount变量，类似于并发编程中的CAS（Compare and Swap）技术。我们可以看到这个方法中，每次在发生增删改的时候都会出现modCount++的动作。

• 而modcount可以理解为是当前hashtable的状态。每发生一次操作，状态就向前走一步。设置这个状态，主要是由于hashtable等容器类在迭代时，判断数据是否过时时使用的。尽管hashtable采用了原生的同步锁来保护数据安全。但是在出现迭代数据的时候，则无法保证边迭代，边正确操作。于是使用这个值来标记状态。一旦在迭代的过程中状态发生了改变，则会快速抛出一个异常，终止迭代行为。

总结

关于迭代器具体是什么，多线程相关的线程安全问题，老铁们可以关注博主后续的更新，或者自行查找一下相关的文章，此篇文章是博主反复查阅HashMap和Hashtable的源码和借阅了部分文章总结出来的，希望各位老铁们可以多多支持~~点赞+关注，感谢！！！😁😁😁