bigdecimal计算开n次方_随笔：HashMap中容量为什么是2的次方数？

注：本文基于JDK1.8

HashMap知识点较多，一次性讲解篇幅较大，不便于记忆，我决定使用定点突破的方式进行讲解。

读完本篇文章你将了解到：

HashMap中的位运算
HasMap的构造函数
HashMap中容量为什么是2的次方数

HashMap中的位运算

位运算计算效率高，Jdk开发人员在HashMap源码中使用了大量的位运算。

static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16static final int MAXIMUM_CAPACITY = 1 << 30;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;    }

在进行分析之前我们来对位运算进行简单复习。

【与】运算 & ：特点 -->遇0得0 (相乘)

例：3&5

3: 0000 0011

5: 0000 0101

结果 0000 0001
【或】运算 | ：特点 -->遇1得1(相加)

例：3|5

3: 0000 0011

5: 0000 0101

0000 0111
【异或】运算 ^ ：特点 -->相同为0 ，不同为1”(相减)

例：3^5

3: 0000 0011

5: 0000 0101

0000 0110
【非】运算 ~ ：特点 -->各位取反

HashMap中的构造函数

在讲解HashMap构造函数之前，我们先快速浏览一遍HashMap比较重要的几个属性。

static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // 默认的数组初始化容量

static final int MAXIMUM_CAPACITY = 1 << 30; //默认的数组最大容量

static final float DEFAULT_LOAD_FACTOR = 0.75f; //默认负载因子

static final int TREEIFY_THRESHOLD = 8;  //链表树化阈值

static final int UNTREEIFY_THRESHOLD = 6; //树转链表阈值 <6

static final int MIN_TREEIFY_CAPACITY = 64; //最小树形化容量阈值 当哈希表中的容量 > 该值时，才允许树形化链表  否则进行数组的扩容

HashMap的有参构造函数

我们进行无参构造时，使用的是其默认的容量及负载因子

public HashMap(int initialCapacity, float loadFactor) {    if (initialCapacity < 0)        throw new IllegalArgumentException("Illegal initial capacity: " +                                           initialCapacity);    if (initialCapacity > MAXIMUM_CAPACITY)        initialCapacity = MAXIMUM_CAPACITY;    if (loadFactor <= 0 || Float.isNaN(loadFactor))        throw new IllegalArgumentException("Illegal load factor: " +                                           loadFactor);    //上面都是一些合法性检查      this.loadFactor = loadFactor;    //这里threshold 是通过 tableSizeFor()来获取一个>= initialCapacity的二进制数    //其作为扩容阈值的作用会在resize() 方法中重新赋值    this.threshold = tableSizeFor(initialCapacity);}

我们看到在HashMap的构造函数中并没有进行数组的初始化，它是懒加载的在第一次put数据的时候进行初始化。

以下为putVal()方法部分代码

if ((tab = table) == null || (n = tab.length) == 0)            n = (tab = resize()).length;  //进行初始化

tableSizeFor(initialCapacity)方法

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;}

这个方法会返回一个大于等于入参的一个2的次方数，比如 5->8 10->16 16->16。

而为什么需要数组长度是一个2的次方数，我们先留个疑问稍后解答。

我们看到他先将入参cap进行减1 再进行无符号右移(高位全补0) 或运算他这是再干嘛？？我们来运算试一下。

假设 8

第一次 |运算

n : 00... 0000 1*** (32位)

右移 1 位 n1 : 00... 0000 0111

r: 00... 0000 11**

第二次 |运算

n1 : 00... 0000 11**

右移 2 位 n2 : 00... 0000 0011

r: 00... 0000 1111

发现了没有，经过右移或运算不断把第一个1 后面的值都变为1

return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1;

最后判断如果 n>=0 返回 n+1 那么将会变成 0001 0000 -->16 。妙啊！

至于开始的n = cap - 1 是为了边界值如输入cap = 16 如果不进行-1 最终结果将是32 。

为什么数组长度是2的次方数

我们先看put方法中的一个小代码片段，是当计算出的数组下表中还没有数据存储，直接将node存储到数组的下标位置。

if ((p = tab[i = (n - 1) & hash]) == null)            tab[i] = newNode(hash, key, value, null);

n为数组长度。

那么计算value存储在哪个数组下标是一个关键。我们通常可以使用 hash%n 来得出具体位置，，但HashMap中不是这么做的，她是通过过【 i = (n - 1) & hash 】，通过hash值和n-1 进行&运算，这种方式效率高，那么为什么将hash值与n-1就能确定他的位置呢？

假设 n = 16

n-1: 00... 0000 1111

h : 01... 1010 0101

res: 00... 0000 0101

n-1: 00... 0000 1111

h : 01... 1010 0111

res: 00... 0000 0111

n-1: 00... 0000 1111

h : 01... 1010 1111

res: 00... 0000 1111

我们看到在进行了&操作后，hash值得高位都被丢弃掉了，而&操作后的取值范围是 0000 --> 1111也就是 0- >15 。妙啊！

这样就确定了一个hash值在数组中的位置，完事了?

NO NO 相信有人已经想到了，那这不就是只要hash的低位吗，高位有差异也被直接丢弃了，这不行啊，hash碰撞的几率更高了！

这一点JDK开发人员早就想到了，在进行数组下标计算之前，对原有hashcode进行了再次加工，将hash值和 hash右移16位后的新值进行 ^ 操作。

return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);

通过这种方式，使得原有hashcode的高16位也参与到计算中来，这样可以大大降低hash碰撞的几率。

说回到上面的问题，为什么数组的长度要保证是2的次方呢，这就是为了高效计算数组下标！

如果n不是2的次方数。

n-1: 00... 0001 0000

h : 01... 1010 0111

res: 00... 0000 0000 高位低位怎么变化都是0 0000 或 1 0000 这肯定是不行的。

这里是有规律的，只有拿2的次方数 -1 的得的值(0011 1111)进行位运算，取值范围才是正确的，才能得到与 hash%n 一样的效果。

关于HashMap的其他知识点，将在后面推出，敬请期待。