参数
DEFAULT_INITIAL_CAPACITY
MUST be a power of two.
默认值为1<<4，aka16。
MAXIMUM_CAPACITY
MUST be a power of two <= 1<<30.
- HashMap规定了其容量必须是2的n次方，所以用位运算
<<来控制HashMap的大小更方便，还提高了Java的处理速度。
- HashMap内部由Entry[]数组构成，而Java的数组下标是由Int表示的，所以HashMap最大的容量应该是不超过int最大值的一个2的指数幂，而最接近int最大值的2的指数幂用位运算符表示为
1 << 30。
ps. 一个4字节整数具有32位，其中数字部分由于有符号位而只能跨越31位，所以最大值是符号位为0，其余位为1的数，即
2
31
−
1
2^{31}-1
231−1。
loadFactor
即加载因子，默认0.75。
若填充比很大，说明利用的空间很多。
如果一直不进行扩容，链表就会越来越长，查找的效率就会很低。
扩容后，将原来链表数组的每一个链表分成奇偶两个子链表分别挂在新链表数组的散列位置，这就减少了每个链表的长度，增加查找效率。HashMap本来设计是以空间换时间，所以填充比没必要太大，但是填充比太小又会导致空间浪费，因此，若关注内存，填充比可以稍大，若关注查找性能，填充比可以稍小。
initialCapacity
即初始容量。
threshold
当map容量达到这个阈值时要进行resize。
方法
tableSizeFor
作用是返回大于输入参数且最近的2的整数次幂的数，比如输入10则返回16。
-
JDK1.8
/**
* Returns a power of two size for the given target capacity.
*/
static final int tableSizeFor(int cap) {
int n = cap - 1;
n |= n >>> 1;
n |= n >>> 2;
n |= n >>> 4;
n |= n >>> 8;
n |= n >>> 16;
return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1;
}
设cap=17，即二进制10001：
- int n = cap - 1;：n=16，即二进制10000
- n |= n >>> 1;：即n=10000|1000=11000
- n |= n >>> 2;：即n=11000|110=11110
- n |= n >>> 4;：即n=11110|1=11111
- n |= n >>> 8;：即n=11111|0=11111
- n |= n >>> 16;：即n=11111|0=11111
以上操作保证了n的最高非零位后的每一位都是1
-
JDK15
static final int tableSizeFor(int cap) {
int n = -1 >>> Integer.numberOfLeadingZeros(cap - 1);
return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1;
}
- Integer.numberOfLeadingZeros的作用是返回输入参数（int类型）的“最高非零位（包括符号位）前的0的个数”，使用了二分法。
-
cap - 1的原因：主要是因为n + 1。
若不减1，当cap为
2
4
=
16
2^4=16
24=16时，n为-1>>>27，即31，最后返回
2
5
=
32
2^5=32
25=32，但事实上，应该返回16。
hash
该方法叫扰动函数。
-
hashCode
Object类中有一个hashCode()方法，是一个native方法，意味着方法的实现和硬件平台有关，默认实现和虚拟机有关，对于有些JVM，hashCode()返回的就是对象的地址，大多时候，JVM根据一定的规则将与对象相关的信息（比如对象的存储地址、对象的字段等）映射成一个数值并返回，例如HotSpot JVM中生成hash实现：hotspot/src/share/vm/runtime/synchronizer.cpp
在Java中，hashCode()方法的主要作用是为了配合基于散列的集合（HashSet、HashMap）一起正常运行。当向集合中插入对象时，虽然可以调用equals()来逐个地进行比较，但该方法效率低下，因此，先比较hashCode再调用equals()会快很多。
- 背景
- 若hashMap的Entry数组长度为16，那么就是取hash的低4位作为Entry数组的下标。
- 由于覆盖equals()时需要覆盖hashCode()，所以hashCode()有时并不十分完美，比如只和高位有关等等。
-
问题
如果只是取最后几位的Hash值的话，那么那些低位相同但高位不同的Hash值就会碰撞了。
如果散列本身做得不好，分布上成等差数列的漏洞，恰好使最后几个低位呈现规律性重复，这就无比棘手。
-
解决
HashMap用了一种办法（ 扰动 ）：将Hash值的高16位右移（正好是32bit的一半）并与原Hash值取异或运算，这是为了混合原始哈希码的高位和低位，使得混合后的低位掺杂了高位的部分特征，这样高位的信息也被变相保留了下来。
之所以是异或运算，而不是与或非，是因为&和|都会使得结果偏向0或者偏向1。
- JDK1.7
static int hash(int h) {
// This function ensures that hashCodes that differ only by
// constant multiples at each bit position have a bounded
// number of collisions (approximately 8 at default load factor).
h ^= (h >>> 20) ^ (h >>> 12);
return h ^ (h >>> 7) ^ (h >>> 4);
}
这样设计保证了对象的hashCode的32位值只要有一位发生改变，整个hash()返回值就会改变，高位的变化会反应到低位里。
- JDK1.8
static final int hash(Object key) {
int h;
return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}
这样设计保证了对象的hashCode的高16位的变化能反应到低16位中，相比较而言减少了过多的位运算，是一种折中的设计。
