Java中HashMap和Hashtable的区别

HashMap 和 Hashtable 的区别

  1. 线程是否安全:HashMap 是非线程安全的,Hashtable 是线程安全的;Hashtable 内部的方法基本都经过 synchronized 修饰。(如果你要保证线程安全的话就使用 ConcurrentHashMap 吧);
  2. 效率:因为线程安全的问题,HashMap 要比 Hashtable 的效率高一点。另外,Hashtable 基本被淘汰,最好不要在代码中使用他;
  3. 对 Null key 和 Null value 的支持:HashMap 中,null 可以作为键,这样的键只有一个,而可以有一个或多个键所对应的值为 null 。当时在 Hashtable 中 put 进的键值只要有一个为 null ,就会直接抛出 NullPointerException 。
  4. 初试容量大小和每次扩充容量大小的不同
    1. 创建时如果不指定容量初始值,Hashtable 默认的初始大小为 11,之后每次扩充,容量变为原来的 2n+1。HashMap 默认的初始化大小为16,之后每次扩充,容量变为原来的 2 倍。
    2. 创建时如果给定了容量初始值,那么 Hashtable 会直接使用你给定的大小,而 HashMap 会将其扩充为 2 的幂次方大小(HashMap 中的 tableSizeFor() 方法保证)。也就是说 HashMap 总是使用 2 的幂作为哈希表的大小。
  5. 底层数据结构:JDK 1.8 以后的 HashMap 在解决哈希冲突时有了较大的变化,当链表长度大于阈值时(默认为8),将链表转化为红黑树,以减少搜索时间。Hashtable 没有这样的机制。

HashMap 中带有初始容量的构造函数:

public HashMap(int initialCapacity, float loadFactor) {
     //此处对传入的初始容量进行校验,最大不能超过MAXIMUM_CAPACITY = 1<<30(230)
        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;
        this.threshold = tableSizeFor(initialCapacity);
    }
public HashMap(int initialCapacity) {
    this(initialCapacity, DEFAULT_LOAD_FACTOR);
}

下面这个方法保证了 HashMap 总是使用 2 的幂作为哈希表的大小。

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

HashMap 的底层实现

JDK 1.8 之前

JDK 1.8 之前 HashMap 底层是数组和链表结合在一起使用,也就是链表散列。HashMap 通过 key 的 hashCode 经过扰动函数处理过后得到 hash 值,然后通过 (n - 1) & hash 来判断当前元素存放的位置(这里的 n 指的是数组的长度),如果当前位置存在元素的话,就判断该元素与要存入的元素的 hash 值以及 key 是否相同,如果相同的话,直接覆盖,不相同就通过拉链法解决冲突。

所谓扰动函数指的就是 HashMap 的 hash 方法。使用 hash 方法也就是扰动函数是为了防止一些实现比较差的 hashCode() 方法,换句话说使用扰动函数之后可以减少碰撞。

JDK 1.8 HashMap 的 hash 方法源码:

JDK 1.8 的 hash 方法相比于 JDK 1.7 的 hash 方法更加简化,但是原理不变。

static final int hash(Object key) {
	int h;
	// key.hashCode():返回散列值也就是hashcode
	// ^ :按位异或
	// >>>:⽆符号右移,忽略符号位,空位都以0补⻬
	return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}

对比一下 JDK 1.7 的 HashMap 的 hash 源码:

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

相比于 JDK 1.8 的 hash 方法, JDK 1.7 的 hash 方法的性能会稍差一些,因为毕竟扰动了 4 次。

所谓**“拉链法”**就是:将链表和数组相结合。也就是说创建一个链表数组,数组中每一格就是一个链表。若遇到哈希冲突,则将冲突的值加到链表中即可。

JDK 1.8 之后

相比于之前的版本, JDK 1.8 之后在解决哈希冲突时有了较大的变化,当链表长度大于阈值时(默认为 8),将链表转化为红黑树,以减少搜索时间。

TreeMap, TreeSet 以及 JDK 1.8 之后的 HashMap 底层都用到了红黑树。红黑树就是为了解决二叉查找树的缺陷,因为二叉查找树在某些情况下会退化成一个线性结构。

HashMap 的长度为什么是 2 的幂次方?

**为了能让 HashMap 存取高效,尽量减少碰撞,也就是要尽量把数据分配均匀。**Hash 值的范围为 -2147483648 到 2147483647,前后加起来大概 40 亿的映射空间,只要哈希函数映射得比较均匀松散,一般应用是很难出现碰撞的。但问题是一个 40 亿长度的的数组,内存是放不下的。所以这个散列值是不能直接拿来用的。用之前需要先做对数组长度的取模运算,得到的余数才能用来要存放的位置也就是对应的数组下标。这个数组下标的计算方法是“(n - 1) & hash”(n 代表数组长度)。这也就解释了 HashMap 的长度为什么是 2 的幂次方。

这个算法应该如何设计呢?

我们首先可能会想到采用 % 取余的操作来实现。但是,重点来了,取余 % 操作中如果除数是 2 的幂次则等价于与其除数减一的与 & 操作。也就是说,hash % length == hash & (length - 1)的前提是 length 是 2 的 n 次方。并且采用二进制位操作 & ,相对于 % 能够提高运算效率,这就解释了 HashMap 的长度为什么是 2 的幂次方。

HashMap 多线程操作导致死循环问题

主要原因在于并发下的 Rehash 会造成元素之间会形成一个循环链表。不过, JDK 1.8 之后解决了这个问题,但是还是不建议在多线程下使用 HashMap,因为多线程下使用 HashMap 还是会存在其他问题比如数据丢失。并发环境下推荐使用 ConcurrentHashMap。

猜你喜欢

转载自blog.csdn.net/gaoxiaokun4282/article/details/105750636