Fork me on GitHub

【jdk源码3】HashMap源码学习

  可以毫不夸张的说,HashMap是容器类中用的最频繁的一个,而Java也对它进行优化,在jdk1.7及以前,当将相同Hash值的对象以key的身份放到HashMap中,HashMap的性能将由O(1)下降到O(N),所以jdk1.8将相同Hash值的key以红黑树的形式进行存储。

 

一、简单理解

1.1 初始容量的设计

  给我的感受是,给用户自由,但是要在限定的范围内。

  首先介绍初始容量是什么,引用Java API中的介绍:

HashMap 的实例有两个参数影响其性能:初始容量 和加载因子。容量 是哈希表中桶的数量,初始容量只是哈希表在创建时的容量。加载因子 是哈希表在其容量自动增加之前可以达到多满的一种尺度。当哈希表中的条目数超出了加载因子与当前容量的乘积时,则要对该哈希表进行 rehash 操作(即重建内部数据结构),从而哈希表将具有大约两倍的桶数。

  也就是说,我们可以有远见知道HashMap中将要存入多少数据,而相应的设置初始容量,减少rehash的次数,因为每次rehash将会对HashMap进行一次重构,影响性能,因此HashMap的构造方法中提供了对初始容量的设置:

HashMap(int initialCapacity) :构造一个带指定初始容量和默认加载因子 (0.75) 的空 HashMap。 
HashMap(int initialCapacity, float loadFactor) :构造一个带指定初始容量和加载因子的空 HashMap。 

  但是HashMap在设计的时候,已经考虑到要rehash,以及根据Hash值在固定数量的桶中查询数据,加上对数字的移位运算最高效,所以桶的数量被设计为2的几次方,但是用户输入初始容量是任意的,HashMap是怎么处理的呢?它是取比输入值-1大的且最近的2的几次方的值:

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

  也就是说最终初始容量不一定安装你输入的来,就像一开始说的那样,HashMap给你一定的自由,但是不是绝对的自由。

  以后写代码也可以这么做,当一个重要属性可能影响效率时,不能给使用者太大的自由度,不然用起来慢就不好了。

1.2 列表转树的条件

  首先简单说明下列表和红黑树,对它们有了基本的认识后才能知道为什么决定将列表转成红黑树:

  • 所占空间:红黑树>列表
  • 性能:红黑树>列表,但是当元素数量特别少时,列表的性能还是大于红黑树的

  也就是,有一个阈值,当超过阈值时才会将列表转换成红黑树,为了提高性能HashMap还是考虑的很多的,主要有三个属性涉及到列表和红黑树转换:

static final int TREEIFY_THRESHOLD = 8;
static final int UNTREEIFY_THRESHOLD = 6;
static final int MIN_TREEIFY_CAPACITY = 64

  TREEIFY_THRESHOLD :当一个节点的数量大于此数量的时候,将会将此节点列表转换成一个树。

  UNTREEIFY_THRESHOLD :当已经是一个树的节点,在移除元素的时候,如果移除后小于这个值,则将树转换成列表。

  MIN_TREEIFY_CAPACITY :当一个节点准备转换成树之前,如果HashMap桶的数量小于此,则不进行转换,而是将HashMap进行扩容。

   也就是说为了一个优化,相当于将HashMap一半的代码进行了重新,为了提升当元素都放置到一个桶时性能的下降。但是对于用户来说是透明的,用户在使用上完全感受不到变化,所以说优化是没有终点的,这一点我还是挺佩服他们的。

1.3 元素的大小比较

  之前讲TreeMap的时候说过,放入TreeMap的key必须具备可比较性,要么本身实现Comparable接口,要么传入key的比较器,因为如果key不能比较大小,就没办法构建一棵树。而我们在放入HashMap的key时,却没有对此有要求,它是怎么实现的呢。

  首先判断key的类型是否是Comparable,如果是,就通过自身的比较方法进行比较。

  如果key不是Comparable,那么就通过key本身的Hash值进行比较,即便子类重写了hashCode方法,也会用最原始的,实际上是用了System的一个方法:

System.identityHashCode(Object x) 

  这个方法,返回给定对象的哈希码,该代码与默认的方法 hashCode() 返回的代码一样,无论给定对象的类是否重写 hashCode()。

  也就是说最终总是能比较出大小,当然如果还一样,说明key是一样的,覆盖即可。

  其中判断key的类型是否是Comparable中有一段代码如下:

static Class<?> comparableClassFor(Object x) {
    if (x instanceof Comparable) {
        Class<?> c; Type[] ts, as; Type t; ParameterizedType p;
        if ((c = x.getClass()) == String.class) // bypass checks
            return c;
        if ((ts = c.getGenericInterfaces()) != null) {
            for (int i = 0; i < ts.length; ++i) {
                if (((t = ts[i]) instanceof ParameterizedType) &&
                    ((p = (ParameterizedType)t).getRawType() ==
                     Comparable.class) &&
                    (as = p.getActualTypeArguments()) != null &&
                    as.length == 1 && as[0] == c) // type arg is c
                    return c;
            }
        }
    }
    return null;
}

  说实话我一开始没有想到会这么复杂,后来我认真研究了一下发现一个类即便实现了Comparable接口,也有可能比较的是其他类:

class Dog implements Comparable<Object>{
  public String name;

  public Dog(String name) {
    this.name = name;
  }
  @Override
  public int compareTo(Object o) {
    // TODO Auto-generated method stub
    return 0;
  }
}

  没想到判断的这么严谨,因为印象中很少有类实现Comparable接口,而不去比较自己的,简单总结它的逻辑:

  • 首先是一个Comparable
  • Comparable必须是一个参数化类型,就是说指定比较类型
  • 参数化有一个参数,且是它本身

  看完这部分,我想了想TreeMap为什么没有借鉴HashMap的这种方式,而必须让key具有比较性,原因其实很简单,HashMap的作用就是存储快速读取,而TreeMap的额外多了个目的就是排序,如果一个key不具备可比较性,而最终使用了最原始的hashCode,那排序就没有了意义,还不如使用更高效的HashMap呢。

二、问题及总结

  HashMap做为最常用的容器类,Java已经封装的足够好了,而我们使用的时候如果能做到以下两点也就能最大化的提高HashMap的性能:

  • 自定义对象做为key时,重写hashCode和equals方法
  • 如果能预见存入HashMap元素的数量,在初始化的时候指定

  其它暂时没有遇到什么问题。

posted @ 2017-07-17 21:11  已往之不谏  阅读(877)  评论(0编辑  收藏  举报