HashMap浅谈
HashMap作为集合框架的重点，面试常常被提到。但是，如果仅仅是记住定论的你，往往会最后很痛苦，典型的问题HashMap和HashTable有什么相同或不同?那么当然会知道HashMap是线程不安全的，然后HashTable是安全的。然后其实只回答到这里往往是不够的。为什么不安全呢?怎么导致不安全了?解决方案呢?所以今天就记录下个人认为比较重要的几个知识点吧。
1.HashMap的hash如何获取
hashCode是jdk根据对象的地址或者字符串或者数字算出来的int类型的数值 ,然后应该都知道hashmap的下标冲突（就是同一个数组下标通过链表存放的对象，但是不一定是该数组下标的对象hashcode都相同）,那么怎么样的对象会存放在同一个数组下标呢?
一般认为通过hashcode%数组长度，得到的数为存放的数组下标，但是这样子的问题是，我么你的计算机都是二进制的，取模算法的效率并不高，所以这时候我们可以利用位运算了。不了解位运算的话自己去科普科普吧。如何确定对象存放的数组下标呢?
1.获取对象hashcode，然后将其进行右移16位
2.将右移16位的结果和其本身进行或运算
3.将获取的hash与数组长度-1进行&运算。
tab[i]中的i就是数组下标，i=(n-1&hash)，就是数组长度和上一部获取到的hash进行与运算的值。以上代码截图均是JDK1.8版本。
那么就说说这个简单的获取数组下标的方法涉及的几个关键的问题吧。其实总体步骤就是下面这张图。
1.为什么要将hashcode右移16位的结果和其本身进行或运算
看看如果我们不讲hashcode进行右移，然后直接与数组长度-1进行&运算的结果。
调用hashCode: 1111 1111 1111 1111 1111 0000 1110 1010
数组长度16-1 : 0000 0000 0000 0000 0000 0000 0000 1111
我们会发现就是数组长度的大小都不会特别大，一开始都是默认16.那么hashcode与数组长度-1进行&运算的话。由于数组长度-1的值其高位几乎都为0，那么hashcode的高位与其进行&运算无论hashcode的高位取值是什么都会为0，也就是说由于数组长度的高位几乎都为0就导致与运算后的hash值高位也为0，那么就是hashcode的高位并没有参与运算。所以这时就会导致进行运算只有低位起作用，那么很大程度上我们就只是运用了低位进行了运算。
从上面两张图我们就发现，其实高位做的运算是无效的，因为不管hashcode的高位如何运算，最后由于进行了&运算，导致其实我们得出的结果和hashcode高位无效。
2.为什么数组的长度要是2的幂方呢？
首先我们知道计算机是二进制运算哈，然后%的运算效率是很低的，当然你感受不出来。
那么我们又要如何的变相去实现hash%数组长度呢?这时候就有个巧妙地数学运算。
当然只是我个人的试验。
所以数组的长度取2的幂次可以利用hash&length-1来代替hash%length，其结果一模一样。
二进制运算中决定奇数还是偶数是由其低位最后一个数字决定的，如果其为0则证明这个数是偶数，如果是1就代表是奇数。0&任何数都是0，则得出来的下标数组都是偶数，那么其空间浪费极大，下标碰撞概率极大。所以2的幂-1得出来的是奇数，那么他与任何hash进行&运算其结果分布较为均匀。
HashMap 的 key 和 value 都能为 null 么？如果 key 能为 null，那么它是怎么样查找值的？
这一个问题很有可能会问你，hashmap和hashtable中有什么区别，但是我们往往记得一个线程不安全，一个线程安全而已。
如果 key 为 null，则直接从哈希表的第一个位置 table[0] 对应的链表上查找,由 putForNullKey（）实现。记住，key 为 null 的键值对永远都放在以 table[0] 为头结点的链表中
HashMap为什么是线程不安全的呢?
1.put数据的时候由于没有加锁，所以允许两个线程同时进行写操作，那么必定线程不安全。
2.扩容机制没有加锁，有可能导致死循环。
扩容机制中，扩容中原来数组中的链表顺序将会逆过来（自己好好理解代码）。
我们假设有两个线程同时需要执行resize操作，我们原来的桶数量为2，记录数为3，需要resize桶到4，原来的记录分别为：[3,A],[7,B],[5,C]，在原来的map里面，我们发现这三个entry都落到了第二个桶里面。
假设线程thread1执行到了transfer方法的Entry next = e.next这一句，然后时间片用完了，此时的e = [3,A], next = [7,B]。线程thread2被调度执行并且顺利完成了resize操作，需要注意的是，此时的[7,B]的next为[3,A]。此时线程thread1重新被调度运行，此时的thread1持有的引用是已经被thread2 resize之后的结果。线程thread1首先将[3,A]迁移到新的数组上，然后再处理[7,B]，而[7,B]被链接到了[3,A]的后面，处理完[7,B]之后，就需要处理[7,B]的next了啊，而通过thread2的resize之后，[7,B]的next变为了[3,A]，此时，[3,A]和[7,B]形成了环形链表，在get的时候，如果get的key的桶索引和[3,A]和[7,B]一样，那么就会陷入死循环。
