HashMap源代码的简单分析

 前言：

    1.HashMap允许null的value和null的key。

    2.与HashTable相比，HashMap是没有synchronized。

    3.它的Iterator采用了Fail-Fast机制。

    

重要Fields：

表，默认大小（capacity）是16。表的大小总是2的幂。

负载，默认的是0.75。当表中entries个数超过16*0.75时，table将会扩容。

重要的方法或内部类

内部类：Holder

    这个类保证：当table的大小超过某个设定值时（useAltHashing会为true），会先取一个hashSeed（待会会看到）。这个值在环境变量"jdk.map.althashing.threshold"中设定。

静态内部类：Entry

table中的每一项都是一个Entry的实例，可以看出Entry是一个链表的结构。

当两个key相同时（即hash冲突时），以链表的形式保存。

方法：hash(Object k)

useAltHashing生效时，h会先赋值为hashSeed。

方法：indexFor(int, int)

优美的计算，根据hash值得到应该存放的index。保证范围在0~length-1

方法：Entry<K, V> getEntry(Object)

根据key算出hash，根据hash算出index，在index上的Entry链表上查询。

方法：put(K, V)

    key->hash->index，如果index上的Entry链表中有Key与K相同，则更新它的V，否则添加一个Entry。

方法：addEntry(int, K, V, int)

判断是否需要resize（扩容），新的length依旧为2的幂

方法：createEntry(int, K, V, int)

在链表头部插入一个新的Entry

方法：resize(int)

 

方法：transfer(newTable, rehash)

rehash是判断是否需要重新计算每个key的hash。

这个方法值得一提的是，在多线程环境下，这个方法有可能会造成死循环。
为什么会造成死循环？
    首先，得明白一个index下的Entry是以链表的形式保存的。假设原来是E1->E2->E3->E4->..->En->null。进行完transfer方法之后，会变为En->En-1->...->E1->null。

    

    现在两个线程同时进入了transfer操作，原来是E1->E2->null，线程1执行到了next = e.next（现在e为E1），切换到线程2，线程2执行完了整个方法，因此链表变为了E2->E1->null，切换回线程1。

    线程1将newTable[i] = e（此时e=E1），执行e=next（此时e=E2），回到next=e.next，看看会发生什么！next会变为E1，因此线程1就陷入了死循环。