书接上回，我们聊到 HashMap ，详情可看 https://www.toutiao.com/i6820316653801177613/
众所周知 HashMap 是线程不安全的，那体现在哪里呢？想一想？
HashMap 是线程不安全的，其主要体现：
① 在 jdk1.7 中，在多线程环境下，扩容时会造成环形链或数据丢失。
② 在 jdk1.8 中，在多线程环境下，会发生数据覆盖的情况。
面试官：
如果要保证 HashMap 线程安全，你会怎么处理呢？
要保证 HashMap 线程安全，有 3 种 实现方式
啥？你只知道 HashTable？！先回去等通知吧。
● 使用 Collections.synchronizedMap
① 使用方式
② 源码
在 SynchronizedMap 内部维护了一个普通对象 Map，还有排斥锁 mutex，mutex 可以通过构造函数自定义。
如何起到线程安全的呢？
我们可以从上图中看到，synchronized(mutex) 给方法加锁。
● Hashtable
不知各位老铁发现没，Hashtable 不符合驼峰命名，如果长时间没看，第一反应可能是 HashTable。
原来Hashtable 是在 Java 1.0 的时候创建的，而集合的统一规范命名是在后来的 Java 2 开始约定的，当时其他一部分集合类的发布构成了新的集合框架。
Hashtable 相对于 HashMap 线程安全，但是效率较低，不推荐使用，对数据操作方法上加了 synchronized 关键词。
从上图中的第 4 行和第 9 行可以看出，当 Hashtable 的 key 和 value 为 null 时，会报 NullPointerException，而 HashMap 最多只允许一条记录的键为 null, 允许多条记录的值为 null。
Java 8 中 HashMap 处理 key 为 null
我们可以看到 当 key 为 null 时，对应的 hash 值设置为 0
那 Hashtable 为什么不允许 key 和 value 为空？
① 不允许 key 为空， key 都会实现 hashCode 和 equals 方法。而 null 显然没有。由于 null 不是对象，因此不能在其上调用.equals（）或.hashCode（），因此 Hashtable 无法将其计算哈希值以用作键。
② 不允许 value 为空，当你通过 get (k) 获取对应的 value 时，如果获取到的是 null 时，你无法判断，它是 put（k,v）的时候 value 为 null，还是这个 key 从来没有做过映射。HashMap 是非并发的，可以通过 contains(key) 来做这个判断。而支持并发的 Map 在调用 m.contains（key）和 m.get(key)，m 可能已经不同了。
Hashtable 和 ConcurrentHashMap 都使用的是安全失败机制（fail-safe），采用安全失败机制的集合容器，在遍历时不是直接在集合内容上访问的，而是先复制原有集合内容，在拷贝的集合上进行遍历。这种机制会使你此次读到的数据不一定是最新的数据。
Hashtable 和 HashMap 的异同：
① 实现方式不同：
Hashtable 继承了 Dictionary 类，而 HashMap 继承的是 AbstractMap 类。
② 初始容量、扩容机制和 hash 算法不同：
Hashtable 初始容量是 11，HashMap 是 16，当指定容量时，hashtable 初始化指定容量，而 hashmap 是转换成最小的 2 的 幂次方，负载因子默认都是 0.75。当现有容量大于总容量 * 负载因子时，Hashtable 扩容规则为当前容量翻倍 + 1，HashMap 扩容规则为当前容量翻倍。hashtable 和 hashmap 都是采取的拉链法，只是算法不同。
为什么HashTable 的初始容量是 11？
Hashtable 的扩容方式是：old*2+1，初始容量 11，第一次扩容为 23，第二次扩容为 47，可以看到 Hashtable 的容量肯定是奇数，有一些更是为质数。到这里就涉及到了哈希算法相关的知识了，这里就不展开说哈希算法相关的内容了。Hashtable 之所以初始容量为 11 (质数) 和扩容方式保证为奇数，是为了散列得更均匀，也就是减少碰撞发生的几率。
③ 迭代器不同：
HashMap 中的 Iterator 迭代器是 fail-fast（在用迭代器遍历一个集合对象时，如果遍历过程中对集合对象的内容进行了修改（增加、删除、修改），则会抛出 Concurrent Modification Exception。） 的，而 Hashtable 的 Enumerator 不是 fail-fast 的。
● ConcurrentHashMap
① jdk 1.7 使用 Segment 分段锁
其中 Segment 继承于 ReentrantLock。每当一个线程占用锁访问一个 Segment 时，不会影响到其他的 Segment。
从上图可以看出，ConcurrentHashMap get 一个元素的过程需要进行两次 Hash 操作：
第一次 Hash 定位到 Segment，第二次 Hash 定位到元素所在的链表的头部。由于 HashEntry 中的 value 属性是用 volatile 关键词修饰的，保证了内存可见性，所以每次获取时都是最新值。ConcurrentHashMap 的 get 方法是非常高效的，因为整个过程都不需要加锁。
put 方法
首先第一步的时候会尝试获取锁，如果获取失败肯定就有其他线程存在竞争，则利用 scanAndLockForPut() 自旋获取锁。
① 尝试自旋获取锁。
② 如果重试的次数达到了 MAX_SCAN_RETRIES 则改为阻塞锁获取，保证能获取成功。
② jdk 1.8 使用 CAS + synchronized
JDK8 中的实现也是锁分离的思想，它首先使用无锁操作 CAS 插入头结点，如果插入失败，说明已经有别的线程插入头结点了，再次循环进行操作。如果头结点已经存在，则通过 synchronized 获得头结点锁，进行后续的操作。性能比 segment 分段锁又再次提升。另外加入了红黑树，和 jdk 1.8 的 hashmap 一样。
欢迎关注 @Python大星 ，一个会点 Python 的 Java 程序员。文章如有问题，你倒是说啊，喜欢的话，一键三连。
@Python大星 | 文