Hashtable 渐渐被人们遗忘了，只有面试官还记得，感动
🎓 尽人事，听天命。博主东南大学硕士在读，热爱健身和篮球，乐于分享技术相关的所见所得，关注公众号 @ 飞天小牛肉，第一时间获取文章更新，成长的路上我们一起进步
🎁 本文已收录于 「CS-Wiki」Gitee 官方推荐项目，现已累计 1.5k+ star，致力打造完善的后端知识体系，在技术的路上少走弯路，欢迎各位小伙伴前来交流学习
🍉 如果各位小伙伴春招秋招没有拿得出手的项目的话，可以参考我写的一个项目「开源社区系统 Echo」Gitee 官方推荐项目，目前已累计 600+ star，基于 SpringBoot + MyBatis + MySQL + Redis + Kafka + Elasticsearch + Spring Security + ... 并提供详细的开发文档和配套教程。公众号后台回复 Echo 可以获取配套教程，目前尚在更新中
本来准备这篇文章一口气写完 Hashtable 和 ConcurrentHashMap 的，后来发现 Hashtable 就已经很多了，考虑各位的阅读体验，所以 ConcurrentHashMap 就放在下篇文章吧。
OK，继续上篇文章 HashMap 这套八股，不得背个十来遍？ 最后提出的问题来讲：
1. 如何保证 HashMap 线程安全？
一般有三种方式来代替原生的线程不安全的 HashMap：
1）使用 java.util.Collections 类的 synchronizedMap 方法包装一下 HashMap，得到线程安全的 HashMap，其原理就是对所有的修改操作都加上 synchronized。方法如下：
public static <K,V> Map<K,V> synchronizedMap(Map<K,V> m)
2）使用线程安全的 Hashtable 类代替，该类在对数据操作的时候都会上锁，也就是加上 synchronized
3）使用线程安全的 ConcurrentHashMap 类代替，该类在 JDK 1.7 和 JDK 1.8 的底层原理有所不同，JDK 1.7 采用数组 + 链表存储数据，使用分段锁 Segment 保证线程安全；JDK 1.8 采用数组 + 链表/红黑树存储数据，使用 CAS + synchronized 保证线程安全。
不过前两者的线程并发度并不高，容易发生大规模阻塞，所以一般使用的都是 ConcurrentHashMap，他的性能和效率明显高于前两者。
2. synchronizedMap 具体是怎么实现线程安全的？
这个问题应该很容易被大家漏掉吧，面经中也确实不常出现，也没啥好问的。不过为了保证知识的完整性，这里还是解释一下吧。
一般我们会这样使用 synchronizedMap 方法来创建一个线程安全的 Map：
Map m = Collections.synchronizedMap(new HashMap(...));
Collections 中的这个静态方法 synchronizedMap 其实是创建了一个内部类的对象，这个内部类就是 SynchronizedMap。在其内部维护了一个普通的 Map 对象以及互斥锁 mutex，如下图所示：
可以看到 SynchronizedMap 有两个构造函数，如果你传入了互斥锁 mutex 参数，就使用我们自己传入的互斥锁。如果没有传入，则将互斥锁赋值为 this，也就是将调用了该构造函数的对象作为互斥锁，即我们上面所说的 Map。
创建出 SynchronizedMap 对象之后，通过源码可以看到对于这个对象的所有操作全部都是上了悲观锁 synchronized 的：
由于多个线程都共享同一把互斥锁，导致同一时刻只能有一个线程进行读写操作，而其他线程只能等待，所以虽然它支持高并发，但是并发度太低，多线程情况下性能比较低下。
而且，大多数情况下，业务场景都是读多写少，多个线程之间的读操作本身其实并不冲突，所以SynchronizedMap 极大的限制了读的性能。
所以多线程并发场景我们很少使用 SynchronizedMap 。
3. 那 Hashtable 呢？
和 SynchronizedMap 一样，Hashtable 也是非常粗暴的给每个方法都加上了悲观锁 synchronized，我们随便找几个方法看看：
4. 除了这个之外 Hashtable 和 HashMap 还有什么不同之处吗？
Hashtable 是不允许 key 或 value 为 null 的，HashMap 的 key 和 value 都可以为 null ！！！
先解释一下 Hashtable 不支持 null key 和 null value 的原理：
如果我们 put 了一个 value 为 null 进入 Map，Hashtable 会直接抛空指针异常：
2）如果我们 put 了一个 key 为 null 进入 Map，当程序执行到下图框出来的那行代码时就会抛出空指针异常，因为 key 为 null，我们拿了一个 null 值去调用方法：
OK，讲完了 Hashtable，再来解释一下 HashMap 支持 null key 和 null value 的原理：
1）HashMap 相比 Hashtable 做了一个特殊的处理，如果我们 put 进来的 key 是 null，HashMap 在计算这个 key 的 hash 值时，会直接返回 0：
也就是说 HashMap 中 key为 null 的键值对的 hash 为 0。因此一个 HashMap 对象中只会存储一个 key 为 null 的键值对，因为它们的 hash 值都相同。
2）如果我们 put 进来的 value 是 null，由于 HashMap 的 put 方法不会对 value 是否为 null 进行校验，因此一个 HashMap 对象可以存储多个 value 为 null 的键值对：
不过，这里有个小坑需要注意，我们来看看 HashMap 的 get 方法：
如果 Map 中没有查询到这个 key 的键值对，那么 get 方法就会返回 null 对象。但是我们上面刚刚说了，HashMap 里面可以存在多个 value 为 null 的键值对，也就是说，通过 get(key) 方法返回的结果为 null 有两种可能：
HashMap中不存在这个 key 对应的键值对HashMap中这个 key 对应的 value 为 null
因此，一般来说我们不能使用 get 方法来判断 HashMap 中是否存在某个 key，而应该使用 containsKey 方法。
5. 那到底为什么 Hashtable 不允许 key 和 value 为 null 呢？为什么这么设计呢？
不止是 Hashtable 不允许 key 为 null 或者 value 为 null，ConcurrentHashMap 也是不允许的。作为支持并发的容器，如果它们像 HashMap 一样，允许 null key 和 null value 的话，在多线程环境下会出现问题。
假设它们允许 null key 和 null value，我们来看看会出现什么问题：当你通过 get(key) 获取到对应的 value 时，如果返回的结果是 null 时，你无法判断这个 key 是否真的存在。为此，我们需要调用 containsKey 方法来判断这个 key 到底是 value = null 还是它根本就不存在，如果 containsKey 方法返回的结果是 true，OK，那我们就可以调用 map.get(key) 获取 value。
上面这段逻辑对于单线程的 HashMap 当然没有任何问题。在单线程中，当我们得到的 value 是 null 的时候，可以用 map.containsKey(key) 方法来区分二义性。
但是！由于 Hashtable 和 ConcurrentHashMap 是支持多线程的容器，在调用 map.get(key) 的这个时候 map 对象可能已经不同了。
我们假设此时某个线程 A 调用了 map.get(key) 方法，它返回为 value = null 的真实情况就是因为这个 key 不能存在。当然，线程 A 还是会按部就班的继续用 map.containsKey(key)，我们期望的结果是返回 false。
但是，在线程 A 调用 map.get(key) 方法之后，map.containsKey 方法之前，另一个线程 B 执行了 map.put(key,null) 的操作。那么线程 A 调用的 map.containsKey 方法返回的就是 true 了。这就与我们的假设的真实情况不符合了。
所以，出于并发安全性的考虑，Hashtable 和 ConcurrentHashMap 不允许 key 和 value 为 null。
6. Hashtable 和 HashMap 的不同点说完了吗？
除了 Hashtable 不允许 null key 和 null value 而 HashMap 允许以外，它俩还有以下几点不同：
1）初始化容量不同：HashMap 的初始容量为 16，Hashtable 初始容量为 11。两者的负载因子默认都是 0.75；
2）扩容机制不同：当现有容量大于总容量 * 负载因子时，HashMap 扩容规则为当前容量翻倍，Hashtable 扩容规则为当前容量翻倍 + 1；
3）迭代器不同：首先，Hashtable 和 HashMap 有一个相同的迭代器 Iterator，用法：
Iterator iterator = map.keySet().iterator();
HashMap 的 Iterator 是 快速失败 fail-fast 的，那自然 Hashtable 的 Iterator 也是 fail-fast 的。Hashtable 是 fail-fast 机制这点很明确，JDK 1.8 的官方文档就是这么写的：
但是！！！Hashtable 还有另外一个迭代器 Enumeration，这个迭代器是 失败安全 fail-safe 的。网络上很多博客提到 Hashtable 就说它是 fail-safe 的，这是不正确的、是存在歧义的！
7. 介绍下 fail-safe 和 fail-fast 机制
fail-safe 和 fail-fast 是一种思想，一种机制，属于系统设计范畴，并非 Java 集合所特有，各位如果熟悉 Dubbo 的话，一定记得 Dubbo 的集群容错策略中也有这俩。
当然，这两种机制在 Java 集合和 Dubbo 中的具体表现肯定是不一样的，本文我们就只说在 Java 集合中，这两种机制的具体表现。
1）快速失败 fail-fast：一种快速发现系统故障的机制。一旦发生异常，立即停止当前的操作，并上报给上层的系统来处理这些故障。
举一个最简单的 fail-fast 的例子：
这样做的好处就是可以预先识别出一些错误情况，一方面可以避免执行复杂的其他代码，另外一方面，这种异常情况被识别之后也可以针对性的做一些单独处理。
java.util 包下的集合类都是 fail-fast 的，比如 HashMap 和 HashTable，官方文档是这样解释 fail-fast 的：
The iterators returned by all of this class's "collection view methods" are fail-fast: if the map is structurally modified at any time after the iterator is created, in any way except through the iterator's own
removemethod, the iterator will throw aConcurrentModificationException. Thus, in the face of concurrent modification, the iterator fails quickly and cleanly, rather than risking arbitrary, non-deterministic behavior at an undetermined time in the future.
大体意思就是说当 Iterator 这个迭代器被创建后，除了迭代器本身的方法 remove 可以改变集合的结构外，其他的因素如若改变了集合的结构，都将会抛出 ConcurrentModificationException 异常。
所谓结构上的改变，集合中元素的插入和删除就是结构上的改变，但是对集合中修改某个元素并不是结构上的改变。我们以 Hashtable 来演示下 fail-fast 机制抛出异常的实例：
分析下这段代码：第一次循环遍历的时候，我们删除了集合 key = "a" 的元素，集合的结构被改变了，所以第二次遍历迭代器的时候，就会抛出异常。
另外，这里多提一嘴，使用 for-each 增强循环也会抛出异常，for-each 本质上依赖了 Iterator。
OK，我们接着往下看官方文档：
Note that the fail-fast behavior of an iterator cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. Fail-fast iterators throw
ConcurrentModificationExceptionon a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness: the fail-fast behavior of iterators should be used only to detect bugs.
意思就是说：迭代器的 fail-fast 行为是不一定能够得到 100% 得到保证的。但是 fail-fast 迭代器会做出最大的努力来抛出 ConcurrentModificationException。因此，程序员编写依赖于此异常的程序的做法是不正确的。迭代器的 fail-fast 行为应该仅用于检测程序中的 Bug。
2）失败安全 fail-safe：在故障发生之后会维持系统继续运行。
顾名思义，和 fail-fast 恰恰相反，当我们对集合的结构做出改变的时候，fail-safe 机制不会抛出异常。
java.util.concurrent 包下的容器都是 fail-safe 的，比如 ConcurrentHashMap，可以在多线程下并发使用，并发修改。同时也可以在 for-each 增强循环中进行 add/remove。
不过有个例外，那就是 java.util.Hashtable，上面我们说到 Hashtable 还有另外一个迭代器 Enumeration，这个迭代器是 fail-safe 的。
HashTable 中有一个 keys 方法可以返回 Enumeration 迭代器：
至于为什么 fail-safe 不会抛出异常呢，这是因为，当集合的结构被改变的时候，fail-safe 机制会复制一份原集合的数据，然后在复制的那份数据上进行遍历。因此，虽然 fail-safe 不会抛出异常，但存在以下缺点：
- 不能保证遍历的是最新内容。也就是说迭代器遍历的是开始遍历那一刻拿到的集合拷贝，在遍历期间原集合发生的修改迭代器是不知道的；
- 复制时需要额外的空间和时间上的开销。
8. 讲讲 fail-fast 的原理是什么
从源码我们可以发现，迭代器在执行 next() 等方法的时候，都会调用 checkForComodification 这个方法，查看 modCount 和 expectedModCount 是否相等，如果不相等则抛出异常终止遍历，如果相等就返回遍历。
expectedModcount 这个值在对象被创建的时候就被赋予了一个固定的值即 modCount，也就是说 expectedModcount 是不变的，但是 modCount 在我们对集合的元素的个数做出改变（删除、插入）的时候会被改变（修改操作不会）。那如果在迭代器下次遍历元素的时候，发现 modCount 这个值发生了改变，那么走到这个判断语句时就会抛出异常。
🎉 关注公众号 | 飞天小牛肉，即时获取更新
- 博主东南大学硕士在读，利用课余时间运营一个公众号『 飞天小牛肉 』，2020/12/29 日开通，专注分享计算机基础（数据结构 + 算法 + 计算机网络 + 数据库 + 操作系统 + Linux）、Java 基础和面试指南的相关原创技术好文。本公众号的目的就是让大家可以快速掌握重点知识，有的放矢。希望大家多多支持哦，和小牛肉一起成长 😃
- 并推荐个人维护的开源教程类项目： CS-Wiki（Gitee 推荐项目，现已累计 1.5k+ star）, 致力打造完善的后端知识体系，在技术的路上少走弯路，欢迎各位小伙伴前来交流学习 ~ 😊
- 如果各位小伙伴春招秋招没有拿得出手的项目的话，可以参考我写的一个项目「开源社区系统 Echo」Gitee 官方推荐项目，目前已累计 600+ star，基于 SpringBoot + MyBatis + MySQL + Redis + Kafka + Elasticsearch + Spring Security + ... 并提供详细的开发文档和配套教程。公众号后台回复 Echo 可以获取配套教程，目前尚在更新中。
