【Java】多线程下使用哈希表注意事项

多线程环境下使用哈希表

HashMap 在设计之初就不是线程安全的，在多线程环境下容易出bug。

在多线程环境下使用哈希表可以使用：

1.HashTable

2.ConcurrentHashMap

---

HashTable

HashTable 只是简单地把 HashMap 的 关键方法 加上了 synchronized，这相当于直接对哈希表本身加了锁，即对 HashTable 对象本身(this) 加了锁，如图：

这就导致如下问题：

1. 如果多个线程访问同一个哈希表，必定会发生锁竞争

如果尝试修改两个 “不同” 链表上的元素，其实是不涉及到线程安全问题的。如修改 1、3 处；
但如果尝试修改同一个链表上的元素，就可能涉及到线程安全问题。如修改1、2处。

很明显这里是可以进行优化的！

2. 哈希表长度size属性，也是通过 synchronized 来控制同步，导致对哈希表的修改效率极慢
3. 一旦触发扩容操作，就由触发扩容操作的线程完成整个扩容操作。这个过程会涉及到大量的元素拷贝，效率极慢！

为了解决上述问题，就设计出了 ConcurrentHashMap

---

ConcurrentHashMap

ConcurrentHashMap 把每一个链表都加了一把锁。
如图：

其优点如下：

1. 如果多个线程操作的是不同链表上的元素，是不会发生锁冲突的
2. 上述设定也不会产生更多的空间代价，因为在Java中一切对象都可以视为是一把锁，使用每个链表的 “头结点” 作为锁即可。
3. 充分利用了 CAS 原子操作，减少了加锁操作，提升效率
   比如对哈希表长度 size 的维护（原子性的 ++/-- 操作）
4. 对扩容操作的优化。

---

扩容策略

哈希表的负载因子如果达到阈值会出现以下两种情况：

1. 变成树（长度不平均）
2. 扩容

负载因子描述了每个桶上平均有多少个元素。
问：为什么认为哈希表的查找是O(1)？
答：因为哈希表里面的元素不应该太长，所以一般认为是 O(1)

HashTable 和 ConcurrentHashMap 的扩容策略：

HashTable 的扩容，是创建一个更大的哈希表，把旧的hash表里的元素全部搬运（插入/删除）到新的表上。如果hash表本身元素过多，那么扩容操作就会消耗很长的时间。

而这一点就会导致不稳定，试想一下：平时程序很快，但某一时刻，突然就卡住了，或者变得很慢，又过一会儿就好了。这是非常令人不爽的事情

而 ConcurrentHashMap 将扩容操作方案是：蚂蚁搬家
不是一股脑将所有元素都移到新表上，而是每次操作都只搬运一部分元素。