关于HashMap
菜鸟登场有什么错误欢迎大家指出，加油！！！
数组结构：数组 + 链表/红黑树
HashMap允许空键空值吗：HashMap最多只允许一个键为Null(多条会覆盖)，但允许多个值为Null
影响HashMap性能的重要参数
初始容量：创建哈希表(数组)时桶的数量，默认为 16
负载因子：哈希表在其容量自动增加之前可以达到多满的一种尺度，默认扩容因子为 0.75，容器的75%，扩容后容量是原来的2倍。
扩容因子为什么是0.75？？
hash函数是理想的，数据会通过hash函数均匀的映射到数组上。一个数据映射到每一个桶（bucket）的概率是相等的。那么在任意的数组容量下，put一个数据发生碰撞的概率=
。而数组的扩容门槛threshold = capacity * loadFactorloadFactor。也就是说扩容因子就是HashMap在扩容门槛的状态下，put操作发生碰撞的概率。
扩容因子=0.75。当使用量接近数组容量的75%的时候，数组中还有25%的剩余空间。平均来看，就是每4个桶（bucket）中还有一个是空的，当我们向map中put数据的时候，发生碰撞的概率是75%。而当扩容因子=0.95的时候，平均来看，就是每20个桶（bucket）中才有一个是空的，此时数组中几乎没有空闲的桶（bucket），当我们put数据的时候，碰撞的概率是95%，几乎可以认为会发生碰撞。
碰撞的概率越大，put的元素就越多，平均到每个桶中的元素的数量也越多。一旦发生碰撞，需要付出更大的代价。所以，如果扩容因子越大，碰撞的概率也就越大，发生碰撞后的代价也更大，结果导致效率大打折扣。
想了解更多HashMap可以参考以下两篇文章：
害怕面试被问HashMap？这一篇就搞定了！小白都能看懂的HashMap面试问题
HashMap线程安全方面会出现什么问题？？
为什么在jdk1.7中，在多线程环境下，扩容时会造成环形链死循环或节点数据丢失？
从堆栈信息中可以看到出现死循环的位置，根源在transfer函数中，当采用头插法就是能够提高插入的效率，但是也会容易出现逆序且环形链表死循环问题。但是在JDK1.8之后是因为加入了红黑树使用尾插法，能够避免出现逆序且减少出现链表死循环的问题。
void addEntry(int hash, K key, V value, int bucketIndex) {
//多个线程操作数组的同一个位置
Entry<K,V> e = table[bucketIndex];
table[bucketIndex] = new Entry<K,V>(hash, key, value, e);
if (size++ >= threshold)
resize(2 * table.length);
}多线程下put操作时，执行addEntry(hash, key, value, i)，如果有产生哈希碰撞，导致两个线程得到同样的bucketIndex去存储，就可能会出现覆盖丢失的情况。
在jdk1.8中，在多线程环境下，会发生数据覆盖的情况：
在jdk1.8中对HashMap进行了优化，在发生hash碰撞，不再采用头插法方式，而是直接插入链表尾部，因此不会出现环形链表的情况，但是在多线程的情况下仍然不安全，这里我们看jdk1.8中HashMap的put操作源码：
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) // 如果没有hash碰撞则直接插入元素
tab[i] = newNode(hash, key, value, null);
else {
Node<K,V> e; K k;
if (p.hash == hash &&
((k = p.key) == key || (key != null && key.equals(k))))
e = p;
else if (p instanceof TreeNode)
e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
else {
for (int binCount = 0; ; ++binCount) {
if ((e = p.next) == null) {
p.next = newNode(hash, key, value, null);
if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
treeifyBin(tab, hash);
break;
}
if (e.hash == hash &&
((k = e.key) == key || (key != null && key.equals(k))))
break;
p = e;
}
}
if (e != null) { // existing mapping for key
V oldValue = e.value;
if (!onlyIfAbsent || oldValue == null)
e.value = value;
afterNodeAccess(e);
return oldValue;
}
}
++modCount;
if (++size > threshold)
resize();
afterNodeInsertion(evict);
return null;
} jdk1.8中HashMap中put操作的主函数， 注意第6行代码，如果没有hash碰撞则会直接插入元素。如果线程A和线程B同时进行put操作，刚好这两条不同的数据hash值一样，并且该位置数据为null，所以这线程A、B都会进入第6行代码中。假设一种情况，线程A进入后还未进行数据插入时挂起，而线程B正常执行，从而正常插入数据，然后线程A获取CPU时间片，此时线程A不用再进行hash判断了，问题出现：线程A会把线程B插入的数据给覆盖，发生线程不安全。
红黑树
红黑树虽然本质上是一棵二叉查找树，但它在二叉查找树的基础上增加了着色和相关的性质使得红黑树相对平衡，从而保证了红黑树的查找、插入、删除的时间复杂度最坏为O(log n)。加快检索速率。当链表长度为8时会将链表转换为红黑树，为6时又会转换成链表.
为什么1.8改用红黑树
比如某些人通过找到你的hash碰撞值，来让你的HashMap不断地产生碰撞，那么相同key位置的链表就会不断增长，当你需要对这个HashMap的相应位置进行查询的时候，就会去循环遍历这个超级大的链表，性能及其地下。java8使用红黑树来替代超过8个节点数的链表后，查询方式性能得到了很好的提升，从原来的是O(n)到O(logn),也可以防止哈希碰撞攻击。
想了解更多HashMap为什么会不安全可以参考：HashMap线程不安全的体现
