HashMap对象的key、value值均可为null。HahTable对象的key、value值均不可为null。且两者的的key值均不能重复，若添加key相同的键值对，后面的value会自动覆盖前面的value，但不会报错。因为HashMap是应用在单线程场景下，在源码中，当判断key为空时，会把value存入table[0]处。当value为空时，可以通过**containsKey(key)**来判断是否有key，若有，则说明返回的null是空value，若没有这个key，则说明返回的null是没有这个key的空。当存入key和value的都为空时，containskey(key)也会返回true，以为table中有Node节点（Node中的key和value属性都为null）

1结构区别：HashMap1.8的底层数据结构是数组+链表+红黑树。HashMap1.7的底层数据结构是数组加链表。2扩容的区别：Jdk1.7：头插法，添加前先判断扩容，当前准备插入的位置不为空并且容量大于等于阈值才进行扩容，是两个条件！扩容后可能会重新计算hash值。Jdk1.8：尾插法，初始化时,添加节点结束之后和判断树化的时候都会去判断扩容。我们添加节点结束之后只要size大于阈值，就一定会扩容，是一个条件。由于hash是final修饰，通过e.hash&oldCap==0来判断新插入的位置是否为原位置。

JDK1.7中，由于多线程对HashMap进行扩容，调用了HashMap#transfer()，具体原因：某个线程执行过程中，被挂起，其他线程已经完成数据迁移，等CPU资源释放后被挂起的线程重新执行之前的逻辑，数据已经被改变，造成死循环、数据丢失。JDK1.8中，由于多线程对HashMap进行put操作，调用了HashMap#putVal()，具体原因：假设两个线程A、B都在进行put操作，并且hash函数计算出的插入下标是相同的，当线程A执行完第六行代码后由于时间片耗尽导致被挂起，而线程B得到时间片后在该下标处插入了元素，完成了正常的插入，然后线程A获得时间片，由于之前已经进行了hash碰撞的判断，所有此时不会再进行判断，而是直接进行插入，这就导致了线程B插入的数据被线程A覆盖了，从而线程不安全。

首先根据key的值计算hash值，找到该元素在数组中存储的下标；如果数组是空的，则调用resize进行初始化；如果没有哈希冲突直接放在对应的数组下标里；如果冲突了，且key已经存在，就覆盖掉value；如果冲突后，发现该节点是红黑树，就将这个节点挂在树上；如果冲突后是链表，判断该链表是否大于8，如果大于8并且数组容量小于64，就进行扩容；如果链表节点大于8并且数组的容量大于64，则将这个结构转换为红黑树；否则，链表插入键值对，若key存在，就覆盖掉value。

Node[]table的初始化长度length(默认值是16)，Loadfactor为负载因子(默认值是0.75)，threshold是HashMap所能容纳键值对的最大值。threshold=length*Loadfactor。也就是说，在数组定义好长度之后，负载因子越大，所能容纳的键值对个数越多。默认的loadFactor是0.75，0.75是对空间和时间效率的一个平衡选择，一般不要修改，除非在时间和空间比较特殊的情况下：如果内存空间很多而又对时间效率要求很高，可以降低负载因子Loadfactor的值。相反，如果内存空间紧张而对时间效率要求不高，可以增加负载因子loadFactor的值，这个值可以大于1。

因为红黑树需要进行左旋，右旋，变色这些操作来保持平衡，而单链表不需要。当元素小于8个的时候，此时做查询操作，链表结构已经能保证查询性能。当元素大于8个的时候，红黑树搜索时间复杂度是O(logn)，而链表是O(n)，此时需要红黑树来加快查询速度，但是新增节点的效率变慢了。因此，如果一开始就用红黑树结构，元素太少，新增效率又比较慢，无疑这是浪费性能的。

在JDK1.7和JDK1.8中有所差别：在JDK1.7中，由“数组+链表”组成，数组是HashMap的主体，链表则是主要为了解决哈希冲突而存在的。在JDK1.8中，由“数组+链表+红黑树”组成。当链表过长，则会严重影响HashMap的性能，红黑树搜索时间复杂度是O(logn)，而链表是糟糕的O(n)。因此，JDK1.8对数据结构做了进一步的优化，引入了红黑树，链表和红黑树在达到一定条件会进行转换：当链表超过8且数据总量超过64才会转红黑树。将链表转换成红黑树前会判断，如果当前数组的长度小于64，那么会选择先进行数组扩容，而不是转换为红黑树，以减少搜索时间。

1、JDK1.7用的是头插法，而JDK1.8及之后使用的都是尾插法JDK1.7是用单链表进行的纵向延伸，当采用头插法时会容易出现逆序且环形链表死循环问题。但是在JDK1.8之后使用尾插法，能够避免出现逆序且链表死循环的问题2、扩容后数据存储位置的计算方式不一样在JDK1.7的时候是直接用hash值和需要扩容的二进制数进行&运算JDK1.8是扩容前的原始位置+扩容的大小值=JDK1.8的计算方式，而不再是JDK1.7中异或的方法。扩容后长度为原hash表的2倍，于是把hash表分为两半，分为低位和高位，原链表的键值对一半放在低位，一半放在高位，而且是通过e.hash&oldCap==0来判断3、hash计算规则不一样在计算hash值的时候，JDK1.7用了9次扰动处理=4次位运算+5次异或而JDK1.8只用了2次扰动处理=1次位运算+1次异或4、底层数据结构不一样JDK1.7使用的是数组+单链表的数据结构。但是在JDK1.8及之后时，使用的是数组+链表+红黑树的数据结构（当阈值是默认阈值0.75，链表的深度大于等于8，扩容的时候会把链表转成红黑树，时间复杂度从O（n）变成O（logN））