前言
你问的为什么，我都想回答。大家好，我是ShadowJava，为你解答疑惑!
本文内容同步到我的微信公众号【JustKeepCoding】，喜欢的朋友点个订阅，我们一起努力进步！
这节依然是探讨Java中的常考的数据结构concurrenthashmap、hashtable,虽然常考但是你理解透了吗？让我们来探讨为什么吧！
1 回顾
上节详细分析了HashMap的源码知识，从JDK1.7的数组加链表 到 JDK1.8的数组加链表加红黑树的数据结构，让我们知道hashmap在1.8的重大改变。
1.2 那么作为在实际工作中我们为什么喜欢用concurrenthashmap代替hashmap呢？
众所周知，hashmap是线程不安全的，是因为hashmap在并发的环境下1.7同时插入会形成环形链表造成死循环，在1.8下插入会直接覆盖数据。
1.3 那覆盖数据和形成环形链表怎么会不安全呢？
线程安全：我们定义当多个线程访问时，采用了加锁机制，当一个线程访问一个类的数据时，进行保护，其他线程不能进行访问直到该线程读取完，其他线程才可以使用。不会出现数据不一致或者数据污染（脏读）。否则就是线程不安全。
其实就是类似于操作系统的互斥，一个人访问必须等待其他人访问完毕其他人才能访问，避免访问被修改，造成脏数据。
回到主题，1.8中的利用尾插法且多个put线程同时插入不同的数据，如果hash值相同时第一个线程插入成功，第二线程不用判断hash值直接将数据覆盖。导致put线程还没结束，就被另一个数据修改了，所以线程不安全。如果这段话不太懂可以查看我的上一篇博文：哈？还在聊hashmap？老知识点了！
来个黄图深入理解一下：
喜欢我写的文章就关注我吧，周三和周日都会更新文章。我也会尽量学习更多新的知识更大家，我的微信公众号【JustKeepCoding】也有Java的并发编程等书籍，喜欢的可以关注领取！
1.4 那么HashMap线程不安全，可以用那些数据结构优化替代呢？
可以使用Collections.synchronizedMap(map)、Hashtable和ConcurrentHashMap代替。那么首先这些是怎么工作的，又是怎样有效替代hashmap的，而ConcurrentHashMap为什么又是最好的选择呢？
2 Collections.synchronizedMap(map)的那些事儿
Collections.synchronizedMap是个比较老的API了,实用起来需要手动做一些事儿。但是相对于ConcurrentHashMap来说可以接收任何类型的map。
2.1 读Collections.synchronizedMap源码 学大佬编程
2.1.1 构造函数源码
SynchronizedMap(Map<K,V> m) {
this.m = Objects.requireNonNull(m);
mutex = this;
}
SynchronizedMap(Map<K,V> m, Object mutex) {
this.m = m;
this.mutex = mutex;
}
从上面可以看出SynchronizedMap包含两个构造函数，可以只传入一个map，或者传入两个参数。其中mutex是互斥锁，如果只传入一个map，则将互斥锁赋值给调用SynchronizedMap的对象。如果传入两个参数，则当前互斥锁为该参数对象mutex。创建出SynchronizedMap之后，再操作Map对象就会给对方上锁。
什么意思呢，相信学过操作系统互斥原理的看见mutex应该懂一大半了吧！上锁了，就只能允许当前线程操作完毕了，才允许另一个线程访问！
2.1.2 增删改查源码
public int size() {
synchronized (mutex) {return m.size();}
}
public boolean isEmpty() {
synchronized (mutex) {return m.isEmpty();}
}
public boolean containsKey(Object key) {
synchronized (mutex) {return m.containsKey(key);}
}
public boolean containsValue(Object value) {
synchronized (mutex) {return m.containsValue(value);}
}
public V get(Object key) {
synchronized (mutex) {return m.get(key);}
}
public V put(K key, V value) {
synchronized (mutex) {return m.put(key, value);}
}
public V remove(Object key) {
synchronized (mutex) {return m.remove(key);}
}
public void putAll(Map<? extends K, ? extends V> map) {
synchronized (mutex) {m.putAll(map);}
}
public void clear() {
synchronized (mutex) {m.clear();}
}
上面的方法都是该对象的增删改查方法，操作时就会加入synchronized关键字给对象上锁。那么synchronized关键字的作用是什么呢，这就得自己百度了，后面还有好多呢，或者可以先关注我，下集可能就出了！
3 关于Hashtable的茶话会
Hashtable也是跟HashMap一样基于散列表的实现
3.1 Hashtable源码
public class Hashtable<K,V>
extends Dictionary<K,V>
implements Map<K,V>, Cloneable, java.io.Serializable {}
private transient Entry<?,?>[] table;
private int threshold;//阈值
private float loadFactor;//负载因子
public synchronized int size() {
return count;
}
可以看出源码跟HashMap的1.7版本有些类似，是基于数组加链表实现。但是为什么效率低下，因为对数据操作时都会上锁。
3.2 Hashtable为什么会被弃用？
虽然Hashtable比HashMap出的早一些，但是基本上是被弃用了，首先因为继承的是被弃用的Dictionary类。HashMap已经成为广泛的数据结构，主要是因为Hashtable线程安全导致，每个方法都有synchronized同步锁。因为加入synchronized同步锁了，在并发度高的情况下，其他线程会被阻塞或者一直轮询。
3.3 Hashtable和HashMap的不同点
上一节认真看过的都知道，HashMap是可以允许KEY和VALUE为Null的,而HashTable是不允许为Null的，这是因为他们的迭代器不同。
3.3.1 从源码分析
从HashMap的hash源码看：
static final int hash(Object key) {
int h;
return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}
当我们向HashMap中插入Null时，会处理为0地址，所以是可以插入
Null值的。
从HashTable源码看：
public synchronized V put(K key, V value) {
// Make sure the value is not null
if (value == null) {
throw new NullPointerException();
}
}
当value为null是会抛出NullPointerException异常
HashMap使用的是Iterator 迭代器，而Hashtable 使用的是Enumerator 迭代器。
3.3.2 迭代器不同
迭代器不同会有什么影响呢，现在来讲讲Java中迭代器的两种模式吧：
- 快速失败（
fail—fast）
在用迭代器遍历一个集合对象时，如果遍历过程中对集合对象的内容进行了修改（增加、删除、修改），则会抛出Concurrent Modification Exception。（这个过程包括多线程下的修改，也包括单线程的修改）
原理：迭代器在遍历时直接访问集合中的内容，并且在遍历过程中使用一个modCount变量。集合在被遍历期间如果内容发生变化，就会改变modCount的值。每当迭代器使用hashNext()/next()遍历下一个元素之前，都会检测modCount变量是否为expectedmodCount值，是的话就返回遍历；否则抛出异常，终止遍历。
场景：java.util包下的集合类都是快速失败的，不能在多线程下发生并发修改（迭代过程中被修改）。 - 安全失败（
fail—safe）
采用安全失败机制的集合容器，在遍历时不是直接在集合内容上访问的，而是先复制原有集合内容，在拷贝的集合上进行遍历。
原理：由于迭代时是对原集合的拷贝进行遍历，所以在遍历过程中对原集合所作的修改并不能被迭代器检测到，所以不会触发Concurrent Modification Exception。
缺点：基于拷贝内容的优点是避免了Concurrent Modification Exception，但同样地，迭代器并不能访问到修改后的内容，即：迭代器遍历的是开始遍历那一刻拿到的集合拷贝，在遍历期间原集合发生的修改迭代器是不知道的。
场景：java.util.concurrent包下的容器都是安全失败，可以在多线程下并发使用，并发修改。
而 Iterator 迭代器是fail-fast的，而 Hashtable 的 Enumerator不是 fail-fast 的。
这样当其他增删改查线程改变了HashMap的结构数据将会抛出Concurrent Modification Exception异常，而Hashtable不会。
我摊牌了，我不装了，我是色批，来个色图总结一下！
4 concurrenthashmap的茶话会
4.1 为什么都推崇ConcurrentHashMap
因为ConcurrentHashMap并发度较高啊，因为好用啊，哈？这？【摸摸了摸头】
ConcurrentHashMap在1.7版本和1.8也有很大的不同，所以也需要从两个版本中分析才能得出结论。
1.7 源码分析：
static final class HashEntry<K,V> {
final K key; // 声明 key 为 final 型
final int hash; // 声明 hash 值为 final 型
volatile V value; // 声明 value 为 volatile 型
final HashEntry<K,V> next; // 声明 next 为 final 型
HashEntry(K key, int hash, HashEntry<K,V> next, V value) {
this.key = key;
this.hash = hash;
this.next = next;
this.value = value;
}
}
在1.7版本中，ConcurrentHashMap的数据结构是由一个Segment数组和多个HashEntry组成，本质跟HashMap一样是个数组加链表。ConcurrentHashMap采用了非常精妙的"分段锁"策略，它的主干是个Segment数组，而Segment继承了ReentrantLock。
static final class Segment<K,V> extends ReentrantLock implements Serializable {
transient volatile HashEntry<K,V>[] table;//table存放数据的桶
transient int modCount;//修改次数，就是fail—fast中机制使用的记录变量
transient int threshold;//阈值
final float loadFactor; // 负载因子
}
4.3 那么什么是ReentrantLock？
在ConcurrentHashMap，一个Segment就是一个子哈希表，Segment里维护了一个HashEntry数组，并发环境下，对于不同Segment的数据进行操作是不用考虑锁竞争的。