HashMap与ConcurrentHashMap

HashMap

1. HashMap的数据结构

哈希表结构（数组+链表），在jdk1.8之后当链表超过8时转为红黑树结构，当链表少于6时，转回链表

2. HashMap的工作原理

HashMap的底层由hash数据和单项链表实现，数组的每个元素都是链表，由Node内部类实现，通过put/get存储和获取数据

3. HashMap的put过程

1. 计算key的hash值，并计算下标，得出元素的存储位置
2. 如果没有hash冲突，则插入
3. 如果hash冲突，则进行equals比较，相同则覆盖，不同则在尾部插入
4. 调整数组大小(当容器中的元素个数大于 容量*载入因子 时，容器会进行扩容resize 为 2n)
   

4.获取hash值的方法如下，为何这样做

static final int hash(Object key) {
        int h;
        // 通过key hashCode() 的高 16位异或低16位实现
        return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
    }

主要是从速度，功效和质量来考虑的，减少系统的开销，也不会造成因为高位没有参与下标的计算，从而增大碰撞概率。

5. 为什么HashMap数组的长度是2的幂次方？

为了提高获取插入元素位置的效率（i = (n - 1) &hash）如果被除数是2的幂次方，那么这对数组长度取余的方法就等价于对数组长度减一的值进行按位与操作。在计算机中，位运算的效率远高于取模运算。

6. 拉链法导致的链表过深问题为什么不用二叉查找树代替，而选择红黑树？为什么不一直使用红黑树？

红黑树是为了解决二叉查找树的缺陷，二叉查找树在特殊情况下会变成一条线性结构（这就跟原来使用链表结构一样了，造成树过高问题），遍历查找会非常慢。

9. 为什么要把链表转为红黑树，阈值为什么是8？

当key的哈希码分布均匀时，数组同一个位置上的元素数量是成泊松分布的，同一个位置上出现8个元素的概率已经接近千分之一了，这侧面说明如果链表的长度达到了8，key的hashCode()肯定是出了大问题，这个时候需要红黑树来保证性能，所以选择8作为阈值。

10. 加载因子默认为0.75，如果改为0.4会怎样？0.95呢？

1. 提高空间利用率和减少查询成本的折中，主要是泊松分布，0.75的话碰撞最小，
2. 加载因子过高，虽然减少了空间开销，提高了空间利用率，但增加了查询时间成本；
3. 加载因子过低，可以减少查询时间成本，但是空间利用率降低，同时提高了rehash的次数。

11. 为何说HashMap不安全？

在多线程下，①JDK1.7采用头插发，可能导致死循环；② JDK8采用尾插发，解决了该问题，但值可能会被覆盖；③ size++ 计算是统计不准确

LinkedHashMap的有序与TreeMap的有序有何不同？

1. LinkedHashMap 内部维护了一个单链表，有头尾节点，同时 LinkedHashMap 节点 Entry 内部除了继承 HashMap 的 Node 属性，还有 before 和 after 用于标识前置节点和后置节点。可以实现按插入的顺序或访问顺序排序。
2. TreeMap 是按照 Key 的自然顺序或者 Comprator 的顺序进行排序，内部是通过红黑树来实现。所以要么 key 所属的类实现 Comparable 接口，或者自定义一个实现了 Comparator 接口的比较器，传给 TreeMap 用户 key 的比较。

ConcurrentHashMap

1. JDK 1.7ConcurrentHashMap类

JDK 1.7中，采用分段锁的机制，实现并发的更新操作，当多个线程put时，只要被加入的数据不在同一个segment中,就可以并行。底层采用数组+链表的存储结构，包括两个核心静态内部类Segment 和 HashEntry。 Segment 继承 ReentrantLock（重入锁） 用来充当锁的角色，每个 Segment对象守护每个散列映射表的若干个桶； HashEntry 用来封装映射表的键-值对；每个桶是由若干个 HashEntry 对象链接起来的链表

2 JDK 8ConcurrentHashMap类

在JDK1.8之后摒弃了segment这种臃肿的设计，底层用的也是数组加链表/红黑树。 在新实现中，在put方法里使用了CAS + synchronized进行同步。 如果插入元素的位置为空，则使用CAS进行插入。如果插入的位置不为空，则对当前位置的对象进行加锁，也就是对链表或红黑树的头节点加锁后再进行后续的插入操作。
这样设计的好处是：

1. CAS是十分轻量的加锁操作，如果能够直接插入，用CAS能够大幅度节省加锁的开销。
2. 如果发生冲突，只用锁住当前位置的头结点，理论上数组的长度有多大，并发操作的线程数就能有多少，比原来只能有16个线程效率更高。

3. ConcurrentHashMap 在 JDK 8中，为什么要使用内置锁 synchronized 来代替重入锁 ReentrantLock？

1. synchronized在JDK1.6之后做了大量的优化，使锁粒度降低了，并且 JVM 开发团队没有放弃 synchronized，而且基于 JVM 的 synchronized 优化空间更大，更加自然。
2. 在大量的数据操作下，对于 JVM 的内存压力，基于 API 的 ReentrantLock 会开销更多的内存。

4.ConcurrentHashMap 存储对象时（put() 方法）：

1. 计算key的hash值
2. 如果没有初始化，就调用 initTable() 方法来进行初始化；
3. 如果没有 hash 冲突就直接 CAS 无锁插入；
4. 如果存在 hash 冲突，就加锁来保证线程安全，两种情况：一种是链表形式就直接遍历到尾端插入，一种是红黑树就按照红黑树结构插入；
5. 判断需要帮助扩容；=
6. 如果该链表的数量大于阀值 8，就要先转换成红黑树的结构，break 再一次进入循环
7. 如果添加成功就调用 addCount() 方法统计 size，并且检查是否需要扩容。

扩容方法:

transfer()：默认容量为 16，扩容时，容量变为原来的两倍。
helpTransfer()：调用多个工作线程一起帮助进行扩容，这样的效率就会更高。

5. 获取对象时（get()方法）：

1. 计算 hash 值，定位到该 table 索引位置，如果是首结点符合就返回；
2. 如果遇到扩容时，会调用标记正在扩容结点 ForwardingNode.find()方法，查找该结点，匹配就返回；
3. 以上都不符合的话，就往下遍历结点，匹配就返回，否则最后就返回 null。

6.ConcurrentHashMap 的并发度是什么？

程序运行时能够同时更新 ConccurentHashMap 且不产生锁竞争的最大线程数。默认为16，且可以在构造函数中设置。当用户设置并发度时，ConcurrentHashMap会使用大于等于该值的最小2幂指数作为实际并发度（假如用户设置并发度为17，实际并发度则为32）