HashMap

讲HashMap之前应该知道红黑树是什么，因为它底层的数据结构是数组+链表或红黑树组成，数组和链表在前面的文章中已经讲过了。

红黑树其实是一种平衡的二叉搜索树，它可以避免极端的二叉搜索树产生的效率低的问题。

红黑树的特质
性质1:节点要么是红色,要么是黑色
性质2:根节点是黑色
性质3:叶子节点都是黑色的空节点
性质4:红黑树中红色节点的子节点都是黑色
性质5:从任一节点到叶子节点的所有路径都包含相同数目的黑色节点

为了保证平衡在添加或删除节点的时候，如果不符合这些性质会发生旋转，以达到所有的性质。

红黑树的复杂度
查找:
红黑树也是一棵BST(二叉搜索树)树，查找操作的时间复杂度为:0(log n)
添加:
添加先要从根节点开始找到元素添加的位置，时间复杂度O(log n)添加完成后涉及到复杂度为O(1)的旋转调整操作
故整体复杂度为:O(log n)
删除:
首先从根节点开始找到被删除元素的位置，时间复杂度O(log n)删除完成后涉及到复杂度为O(1)的旋转调整操作
故整体复杂度为:O(log n)

散列表(Hash Table)

将键(key)映射为数组下标的函数叫做散列函数。可以表示为:hashValue = hash(key)散列函数的基本要求:
散列函数计算得到的散列值必须是大于等于0的正整数，因为hashValue需要作为数组的下标如果key1==key2，那么经过hash后得到的哈希值也必相同即:hash(key1)== hash(key2)如果key1!=key2，那么经过hash后得到的哈希值也必不相同即:hash(key1)!= hash(key2)

散列冲突-链表法(拉链)
在散列表中，数组的每个下标位置我们可以称之为桶(bucket)或者槽(slot)，每个桶(槽)会对应一条链表，所有散列值相同的元素我们都放到相同槽位对应的链表中。

当链表中的元素个数大于8时候会把链表改造成红黑树，为了查找时效率更高

DDos 攻击:
分布式拒绝服务攻击(英文意思是Distributed DenialofService，简称DDoS)指处于不同位置的多个攻击者同时向一个或数个目标发动攻击，或者一个攻击者控制了位于不同位置的多台机器并利用这些机器对受害者同时实施攻击。由于攻击的发出点是分布在不同地方的，这类攻击称为分布式拒绝服务攻击，其中的攻击者可以有多个

HashMap的实现原理

这个也是高频的面试题

HashMap的数据结构:底层使用hash表数据结构，即数组和链表或红黑树1.当我们往HashMap中put元素时，利用key的hashCode重新hash计算出当前对象的元素在数组中的下标

2.存储时，如果出现hash值相同的key，此时有两种情况。
a.如果key相同，则覆盖原始值:
b.如果key不同(出现冲突)，则将当前的key-value放入链表或红黑树中

3.获取时，直接找到hash值对应的下标，在进一步判断key是否相同，从而找到对应值。

HashMap的jdk1.7和jdk1.8有什么区别

JDK1.8之前采用的是拉链法。拉链法:将链表和数组相结合。也就是说创建一个链表数组，数组中每一格就是一个链表。若遇到哈希冲突，则将冲突的值加到链表中即可。

jdk1.8在解决哈希冲突时有了较大的变化，当链表长度大于阈值(默认为8)时并且数组长度达到64时，将链表转化为红黑树，以减少搜索时间。扩容 resize()时，红黑树拆分成的树的结点数小于等于临界值6个，则退化成链表

HashMap的put方法的具体流程

这个也是高频的面试题而且不是很好回答，要去看源码

HashMap是懒惰加载，在创建对象时并没有初始化数组

在无参的构造函数中，设置了默认的加载因子是0.75

下面是添加数据的流程图

1.判断键值对数组table是否为空或为null，否则执行resize()进行扩容(初始化)
2.根据键值key计算hash值得到数组索引
3.判断table[i]==nul，条件成立，直接新建节点添加
4.如果table[i]==nul,不成立
4.1 判断table[i]的首个元素是否和key一样，如果相同直接覆盖value
4.2 判断table[] 是否为treeNode，即table[] 是否是红黑树，如果是红黑树则直接在树中插入键值对4.3 遍历table，链表的尾部插入数据，然后判断链表长度是否大于8，大于8的话把链表转换为红黑树，在红黑树中执行插入操作，遍历过程中若发现key已经存在直接覆盖value
5.插入成功后，判断实际存在的键值对数量size是否超多了最大容量threshold(数组长度*0.75)，如果超过，进行扩容。

HashMap的扩容机制

在添加元素或初始化的时候需要调用resize方法进行扩容，第一次添加数据初始化数组长度为16，以后每次每次扩容都是达到了扩容阈值(数组长度*0.75)
每次扩容的时候，都是扩容之前容量的2倍;
扩容之后，会新创建一个数组，需要把老数组中的数据挪动到新的数组中
没有hash冲突的节点，则直接使用 e.hash &(newCap-1)计算新数组的索引位置
如果是红黑树，走红黑树的添加
如果是链表，则需要遍历链表，可能需要拆分链表，判断(e.hash & oldCap)是否为0，该元素的位置要么停留在原始位置，要么移动到原始位置+增加的数组大小这个位置上

hashMap的寻址算法

计算对象的 hashCode（）
再进行调用 hash()方法进行二次哈希， hashcode值右移16位再异或运算，让哈希分布更为均匀
最后(capacity-1)& hash 得到索引

为何HashMap的数组长度一定是2的次幂?
计算索引时效率更高:如果是2的n次幂可以使用位与运算代替取模扩容时重新计算索引效率更高:hash & oldCap ==0的元素留在原来位置，否则新位置=日位置+oldCap

为什么JDK1.7时的hashmap在数组中进行扩容的时候会造成死循环问题

在jdk1.7的hashmap中在数组进行扩容的时候，因为链表是头插法，在进行数据迁移的过程中，有可能导致死循环
比如说，现在有两个线程
线程一:读取到当前的hashmap数据，数据中一个链表，在准备扩容时，线程二介入线程二:也读取hashmap，直接进行扩容。因为是头插法，链表的顺序会进行颠倒过来。比如原来的顺序是AB，扩容后的顺序是BA，线程二执行结束。
线程一:继续执行的时候就会出现死循环的问题。
线程一先将A移入新的链表，再将B插入到链头，由于另外一个线程的原因，B的next指向了A，所以B->A->B,形成循环,当然，JDK8将扩容算法做了调整，不再将元素加入链表头(而是保持与扩容前一样的顺序)，尾插法，就避免了idk7中死循环的问题。