关注微信公众号：程序猿的日常分享，定期更新分享。
HashMap是我们日常工作中使用非常多的容器，由于HashMap是线程不安全的，那么在多咸亨环境下ConcurrentHashMap则是替代HashMap的容器，这两个也是Map的最主要的实现类之一。本文将通过数据结构、线程安全的角度出发去了解这两个重要的集合类的原理。
一、数据结构
HashMap 和 ConcurrentHashMap 都有这样一个特点：最开始的 Map 是空的，因为里面没有任何元素，往里放元素时会计算key的hash 值，计算之后，第 1 个 key就会首先占用一个桶（也称为槽点）位置，后续如果经过计算发现需要落到同一个桶中，那么便会使用链表的形式往后延长，俗称“拉链法”。
在jdk1.8之后，当链表长度大于或等于阈值（默为 8）的时候，如果同时还满足容量大于或等于 MIN_TREEIFY_CAPACITY（默认为 64）的要求，就会把链表转换为红黑树。同样，后续如果由于删除或者其他原因调整了大小，当红黑树的节点小于或等于 6 个以后，又会恢复为链表形态。
那么为什么要转为红黑树，并且为什么这个阈值是8呢？
首先链表的时间复杂度是最好O(1)，最差O(n)那么它的平均时间复杂度是O(n)，而红黑树由于自身平衡的特点，它的的时间复杂度始终控制在O(log(n))，最开始链表不是很长的情况下，性能不会差很多，但是随着链表越来越长，那么这种新能差距就会体现出来，所以需要转换为红黑树的形式。那么为什么不一开始就使用红黑树呢，我们可以分别从空间复杂度和时间复杂度的维度来思考。
空间复杂度：
Because TreeNodes are about twice the size of regular nodes, we
use them only when bins contain enough nodes to warrant use
(see TREEIFY_THRESHOLD). And when they become too small (due to
removal or resizing) they are converted back to plain bins.
这段话的意思是：单个 TreeNode 需要占用的空间大约是普通 Node 的两倍，所以只有当包含足够多的 Nodes 时才会转成 TreeNodes，而是否足够多就是由 TREEIFY_THRESHOLD 的值决定的。而当桶中节点数由于移除或者 resize 变少后，又会变回普通的链表的形式，以便节省空间。
时间复杂度：
In usages with well-distributed user hashCodes, tree bins
are rarely used. Ideally, under random hashCodes, the
frequency of nodes in bins follows a Poisson distribution
(http://en.wikipedia.org/wiki/Poisson_distribution) with a
parameter of about 0.5 on average for the default resizing
threshold of 0.75, although with a large variance because
of resizing granularity. Ignoring variance, the expected
occurrences of list size k are (exp(-0.5) * pow(0.5, k) /
factorial(k)). The first values are:
0: 0.60653066
1: 0.30326533
2: 0.07581633
3: 0.01263606
4: 0.00157952
5: 0.00015795
6: 0.00001316
7: 0.00000094
8: 0.00000006
more: less than 1 in ten million
这段话的意思是，如果 hashCode 分布良好，也就是 hash 计算的结果离散好的话，那么红黑树这种形式是很少会被用到的，因为各个值都均匀分布，很少出现链表很长的情况。在理想情况下，链表长度符合泊松分布，各个长度的命中概率依次递减，当长度为 8 的时候，概率仅为 0.00000006。这是一个小于千万分之一的概率，通常我们的 Map 里面是不会存储这么多的数据的，所以通常情况下，并不会发生从链表向红黑树的转换。
既然当长度为8的概率这么小，那为什么还要设计红黑树呢？因为HashMap把对象放在哪个桶里是由对象的hashCode()方法决定的，而这个方法是允许用户重写的，如果我们的哈希算法实现的非常不均匀导致数据大多数都进入了一个桶，那么就会导致链表会越来越长。通过一个例子来看：
/**
* description:
*
* @author wangpeng
* @date 2020/12/12
*/
public class TestHashMap {
public static void main(String[] args) {
Map<TestHashMap, String> map = new HashMap<>();
for (int i = 0; i < 100; i++) {
map.put(new TestHashMap(), "");
}
System.out.println("结束");
}
@Override
public int hashCode() {
return 1;
}
}
此时所有的hashcode都是1，我们通过debug查看最终HashMap的数据结构：
所以，为了防止用户自己实现了一个比较差的哈希算法，从而导致查询效率降低，此时转为红黑树也是jdk为我们做了一个兜底的策略，用来保证极端情况下的查询效率。
二、线程安全
接下来我们再从线程安全的角度来分析HashMap和ConcurrentHashMap，首先我们先看一下put的源码，以下为jdk1.8版本：
final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
boolean evict) {
Node<K,V>[] tab; Node<K,V> p; int n, i;
if ((tab = table) == null || (n = tab.length) == 0)
n = (tab = resize()).length;
if ((p = tab[i = (n - 1) & hash]) == null)
tab[i] = newNode(hash, key, value, null);
else {
do something....
}
//重点：这里是一个复合操作
++modCount;
if (++size > threshold)
resize();
afterNodeInsertion(evict);
return null;
}
我们把目光聚焦到标记出来的 ++modCount 这一行代码中，进行了一个典型++i的操作，我们都知道++i和i++都是一种复合操作，表面看是一行代码，但实际上他并不是原子操作，他的执行分为3步，分别是是读取、增加和保存，那么在多线程的环境下，就很有可能会出现最终结果达不到预期值的情况，所以，从源码的角度，或者说从理论上来讲，这完全足以证明 HashMap 是线程非安全的了。因为如果有多个线程同时调用 putVal() 方法的话(jdk1.8的HashMap中put方法调用的是putVal方法)，它很有可能会把 modCount 的值计算错（上述的源码分析针对的是 Java 8 版本的源码，而在 Java 7 版本的 HashMap 的 put 方法里面同样有 modCount++ 语句，所以原理是一样的）。
那么这个modCount计算错误的话会有什么后果呢？
modCount用于记录HashMap的修改次数,在HashMap的put(),get(),remove(),Interator()等方法中,都使用了该属性。
由于HashMap不是线程安全的,所以在迭代的时候,会将modCount赋值到迭代器的expectedModCount属性中,然后进行迭代,如果在迭代的过程中HashMap被其他线程修改了,modCount的数值就会发生变化,这个时候expectedModCount和ModCount不相等,迭代器就会抛出ConcurrentModificationException()异常。
多线程同时 put 碰撞导致数据丢失
在多个线程同时put数据时，如果两个put的key正好hashcode是一样的，那么就是发生了碰撞，他们的bucket位置一样，并且如果两个线程同时发现链表的同一位置是空的，可以写入，那么这两个线程的两个不同的value变回添加到数组的同一个位置，这样最终只能保留一个数据，导致另外一个数据丢失。
可见性问题无法保证
我们都知道多线程最重要的3个特性原子性、可见性、有序性。可见性是多线程编程很重要的一个特性，那么当一个线程操作HashMap的时候，该操作的结果需要对另外的线程都可见，但是显然HashMap无法做到这一点，如果线程1给某个key放入了一个新值，那么线程2在获取该key的时候，可能看到新值，也可能看不到。
链表插入方法导致的线程安全问题
jdk1.7中采用的是头插法，这种方法在多线程环境下可能会造成环形链表，在执行get一个不存在的key时，由于在链表中无法找到该值，并且一直不等于null，所以程序会一直找下去直到找到为止，那么就会造成死循环，导致CPU100%，这种问题出现的关键原因：如果扩容前相邻的两个Entry在扩容后还是分配到相同的链表上，变可能形成环形链表，相当于 A 节点指向 B 节点，B 节点又指回到 A 节点。
jdk1.8采用的是尾插法并且引入了红黑树，尾插法解决了环链问题，原因是扩容转移后前后链表顺序不变，保持之前节点的引用关系。
下篇介绍ConcurrentHashMap
关注微信公众号：程序猿的日常分享，定期更新分享。
