HashMap初始化容量

HashMap初始化容量

《阿里巴巴Java开发规约》中有提到:

【推荐】集合初始化时,指定集合初始值大小。
说明:HashMap使用如下构造方法进行初始化,如果暂时无法确定集合大小,那么指定默认值(16)即可:

public HashMap (int initialCapacity) {
    this(initialCapacity, DEFAULT_LOAD_FACTOR);
}

那么HashMap的初始化值到底应该是多少呢?想要得出这个问题答案,必须先了解一下HashMap的部分特征

HashMap的实例有两个参数影响其性能:初始容量和加载因子
容量是哈希表中桶的数量,初始容量只是哈希表在创建时的容量。HashMap的默认大小为16
加载因子是哈希表在其容量自动增加之前可以达到多满的一种尺度。HashMap默认的加载因子是0.75 .它在时间和空间成本上寻求了一种折中。
当哈希表中条目的数目超过 容量 * 加载因子 的时候,则要对该哈希表进行rehash操作,从而哈希表将具有大约两倍的桶数。

再回到正题,如果确定只装载100个元素,new HashMap()初始化容量多少是最佳的?

根据上文的推测,如果这个只装载100个元素的HashMap没有特殊的用途,那么为了在时间和空间上达到最佳性能,HashMap的初始容量可以设为 100/0.75 = 133.33。为了防止rehash,向上取整,为134。

但是还有另外一个问题,就是hash碰撞的问题。如果我们将HashMap的容量设置为134,那么如何保证其中的哈希碰撞会比较少呢?

除非重写hashcode()方法,否则,似乎没有办法保证。

HashMap在这也有一个解决方案就是选择下标方法:

static int indexFor(int h, int length) {
        return h & (length-1);
    }

其中h为key哈希后得到的值,length为哈希表的长度。

那么 length-1的二进制值的最后3位为101;
假设这100个装载的元素中他们的key在哈希后有得到两个值(h),他们的二进制值除了低3位之外都相同,而第一个值的低3位为011,第二个值的低3位为001;
这时候进行java的&预算,011 & 101 = 001 ;001 & 101 = 001;
他们的值相等了,那么这个时候就会发生哈希碰撞。

除此之外还有一个更加严重的问题,由于在101中第二位是0,那么,无论我们的key在哈希运算之后得到的值h是什么,那么在&运算之后,得到的结果的倒数第二位均为0;
因此,对于hash表所有下标的二进制的值而言,只要低位第二位的值为1,(例如0010,0011,0111,1111)那么这个下标所代表的桶将一直是空的,因为代码中的&运算的结果永远不会产生低位第二位为1的值。这就大大地浪费了空间,同时还增加了哈希碰撞的概率。这无疑会降低HashMap的效率。

那么如何才能减少这种浪费呢?最佳的方法当然是让length-1的二进制值全部位均为1.那么length的值是多少合适呢?
没错,length=2^n。
只要将hash表的长度设为2的N次方,那么,所有的哈希桶均有被使用的可能。

所以上面的答案应该为256

后话:
JDK并不会直接拿用户传进来的数字当做默认容量,而是会进行一番运算,最终得到一个2的幂
也就是说,无论你的HashMap(x)中的x设置为多少,HashMap的大小都是2n。2n是大于x的第一个数。

因此关于这个值的设置,在《阿里巴巴Java开发手册》有以下建议:

正例:initialCapacity = (需要存储的元素个数 / 负载因子) + 1。注意 负载因子(即loader factor)默认 为 0.75,如果 暂时 无法确定 初始 值大小,请设置 为 16
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值