zoukankan      html  css  js  c++  java
  • 关于HashMap初始化容量问题

    使用阿里云代码规范插件扫描后出现以下提示:

    hashmap should set a size when initalizing,即hashmap应该在初始化时设置一个大小

    在网上搜到一篇讲解(https://www.cnblogs.com/coderxuyang/p/3718856.html),如下:

    在元素的装载数量明确的时候HashMap的大小应该如何选择。

    今天看到美团招聘给出了一道小题目,关于HashMap的性能问题。问题如下:

    java hashmap,如果确定只装载100个元素,new HashMap(?)多少是最佳的,why?

    要回答这个问题,首先得知道影响HashMap性能的参数有哪些。咱们翻翻JDK。

    在JDK6中是这么描述的:

    HashMap的实例有两个参数影响其性能:初始容量和加载因子

    首先我们来看初始容量和加载因子的定义。

    容量是哈希表中桶的数量,初始容量只是哈希表在创建时的容量。

    加载因子是哈希表在其容量自动增加之前可以达到多满的一种尺度。

    当哈希表中条目的数目超过 容量乘加载因子 的时候,则要对该哈希表进行rehash操作,从而哈希表将具有大约两倍的桶数。(以上摘自JDK6)

    HashMap默认的加载因子是0.75 .它在时间和空间成本上寻求了一种折中。

    回到本文的问题。根据JDK中的描述,如果这个只装载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为哈希表的长度。

    134-1 = 128 + 6 -1;

    那么 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次方,那么,所有的哈希桶均有被使用的可能。

    再次回到美团提出的问题,与134最靠近的2^n无疑是128。

    如果只修改HashMap的长度而不修改HashMap的加载因子的话,HashMap会进行rehash操作,这是一个代价很大的操作,所以不可取。

    那么应该选择的就应该是256。

    而由于空间加大和有效利用哈希桶,这时的哈希碰撞将大大降低,因此HashMap的读取效率会比较高。

    所以,最后结论就是:HashMap的大小应该设置为256。

    结果的补充:其实在Java中,无论你的HashMap(x)中的x设置为多少,HashMap的大小都是2^n。2^n是大于x的第一个数。因为HashMap的初始化代码中有以下这行代码:

     int capacity = 1;
            while (capacity < initialCapacity)
                capacity <<= 1;

    但是这就带来了一个问题,如果x=100,那么HashMap的初始大小应该是128.但是100/128=0.78,已经超过默认加载因子(0.75)的大小了。因此会resize一次,变成256。所以最好的结果还是256。

    最后发个参考链接:http://www.iteye.com/topic/539465

    另,总结StringBuffer、ArrayList、HashMap的扩容:

    StringBuffer:内部实现是一个字符数组。初始默认大小为16,当然也可以在其构造方法中进行设置。当新添加字符或字符串时,发现数组容量不够。这个时候就需要使用Array.copyOf()方法进行扩充。扩充的新的数组大小等于,(原始容量*2+2)和(数组实际字符个数+新增的字符长度)之间的较大值。

    ArrayList:内部实现是一个Object的数组。初始默认大小为0,当然也可以在其构造方法中设置。当添加一个Object时,默认扩充数组容量为10。然后每次扩充的新的数组大小等于,(原始容量*3/2)和(数组的长度+1)之间的较大值。根据每次增加一个Object,可得该情况每次扩充的固定大小为3/2。当初始大小为手动设置的时候,每次扩充的新的数组大小等于,(原始容量*3/2)和(数组的长度+1)之间的较大值。

    HashMap:内部实现是一个Entry的数组,默认大小是空的数组。初始化的容量是16加载因子是3/4(当数组元素数量大于总容量的加载因子的时候,扩充数组)。当默认不是空的数组时,当达到加载因子的比例的时候,每次扩充初始容量的2

  • 相关阅读:
    ubuntu 更新软件
    如何在linux(lubuntu)下搭建C/C++开发环境
    Linux下如何查看版本信息
    知识点笔记
    Require.js中使用jQuery 插件
    async中常用总结
    node.js在遇到“循环+异步”时的注意事项
    前端性能优化
    生产/消费者问题
    线程与内存
  • 原文地址:https://www.cnblogs.com/tiancai/p/9558895.html
Copyright © 2011-2022 走看看