HashMap ConcurrentHashMap 相关

---

HashMap

---

HashMap 底层是基于 数组 + 链表 组成的，不过在 jdk1.7 和 1.8 中具体实现稍有不同。
在1.7中只有数组与链表进行底层的构造,但是当hash冲突很多时,我们所冲突的链表也就越来越长,这样就要不可避免的花费O(N)的查找时间这是很大的损失
1.8后当一个hash的结点数目不小于8时候就会转为一个红黑树的结构这样时间复杂度只有O(logn);是对效率的一种提高

---

扩容问题

---

当HashMap的长度超出了加载因子与当前容量的乘积（默认16*0.75=12）时，通过调用resize方法重新创建一个原来HashMap大小的两倍的newTable数组，最大扩容到2^30+1，并将原先table的元素全部移到newTable里面，重新计算hash，然后再重新根据hash分配位置。这个过程叫作rehash，因为它调用hash方法找到新的bucket位置。

数组扩容之后，最消耗性能的点就出现了：原数组中的数据必须重新计算其在新数组中的位置，并放进去，这个操作是极其消耗性能的。所以如果我们已经预知HashMap中元素的个数，那么预设初始容量能够有效的提高HashMap的性能。

重新调整HashMap大小，当多线程的情况下可能产生条件竞争。因为如果两个线程都发现HashMap需要重新调整大小了，它们会同时试着调整大小。在调整大小的过程中，存储在链表中的元素的次序会反过来，因为移动到新的bucket位置的时候，HashMap并不会将元素放在链表的尾部，而是放在头部，这是为了避免尾部遍历(tail traversing)。如果条件竞争发生了，那么就死循环了。

---

线程安全的问题

---

首先确定的是HashMap是线程不安全的，在多线程情况下直接使用HashMap会出现一些莫名其妙不可预知的问题。在多线程下使用HashMap，有几种方案：

A.在外部包装HashMap，实现同步机制

B.使用Map m = Collections.synchronizedMap(new HashMap(…));实现同步（官方参考方案，但不建议使用，使用迭代器遍历的时候修改映射结构容易出错）

D.使用java.util.HashTable，效率最低（几乎被淘汰了）

E.使用java.util.concurrent.ConcurrentHashMap，相对安全，效率高（建议使用）

**

ConcurrentHashMap

**
和 HashMap 非常类似，唯一的区别就是其中的核心数据如 value ，以及链表都是 volatile 修饰的，保证了获取时的可见性。

原理上来说：ConcurrentHashMap 采用了分段锁技术，其中 Segment 继承于 ReentrantLock。不会像 HashTable 那样不管是 put 还是 get 操作都需要做同步处理，理论上 ConcurrentHashMap 支持 CurrencyLevel (Segment 数组数量)的线程并发。每当一个线程占用锁访问一个 Segment 时，不会影响到其他的 Segment。