HashMap与HashTable源码学习及效率比较分析

  一、个人学习后的见解:

    首先表明学习源码后的个人见解,后续一次依次进行分析:

    1、线程安全:HashMap是非线程安全的,HashTable是线程安全的(HashTable中使用了synchronized关键字进行控制),HashMap对应的线程安全的有concurrentHashMap,但如果不用concurrentHashMap的话,也可以只用Collections.synchronizedMap(Map)进行转换。

    2、key值为null时的不同处理方式:HashMap允许key值为null,并会把key值为null放在Entry数组中的第一个bucket中;HashTable不允许存放key为null的存放,如果为null会抛出异常。

    3、数据结构:HashMap和HashTable都使用哈希表来存储键值对。后边具体分析。

    4、算法:其一、HashMap中对于key值的定位有内部封装的hash算法,而HashTable中是直接使用.hashcode获取hash值;其二、关于两者容量大小的定义也决定了两者在算法方面的不同效果。

    5、效率问题:单线程情况下_耗时:HashMap.put > HashTable.put;HashMap.get < HashTable.get

    6、根据HashTable注释表名其相当于被弃用了。

  二、对上面简介的分析:

    1、第一点不用解释了,源码中直接体现出来了,想了解者可观看源码。

    2、如图为HashMap的源码部分

         

      对于HashMap的key为null时会调用putForNullKey方法(想了解者可查看源码)进行处理,将value值放入Entry数组的第一个bucket中。

      下图为HashTable的源码部分

       我们可以明确的看到,HashTable的put方法如果key值为null时,会抛出NullPointerException空指针异常。

      从源码出我们可以看出来对于两者对null的不同待遇只是因为代码处理不同,并没有对效率或者其他有影响。

  3、数据结构:

    HashMap和HashTable都使用哈希表来存储键值对。在数据结构上是基本相同的,都创建了一个继承自Map.Entry的私有的内部类Entry,每一个Entry对象表示存储在哈希表中的一个键值对。

    Entry对象唯一表示一个键值对,有四个属性:

      -K key 键对象
      -V value 值对象
      -int hash 键对象的hash值
      -Entry entry 指向链表中下一个Entry对象,可为null,表示当前Entry对象在链表尾部

    可以说,有多少个键值对,就有多少个Entry对象,那么在HashMap和HashTable中是怎么存储这些Entry对象,以方便我们快速查找和修改的呢?请看下图。

    上图画出的是一个桶数量为8,存有5个键值对的HashMap/HashTable的内存布局情况。可以看到HashMap/HashTable内部创建有一个Entry类型的引用数组,用来表示哈希表,数组的长度,即是哈希桶的数量。而数组的每一个元素都是一个Entry引用,从Entry对象的属性里,也可以看出其是链表的节点,每一个Entry对象内部又含有另一个Entry对象的引用。

    这样就可以得出结论,HashMap/HashTable内部用Entry数组实现哈希表,而对于映射到同一个哈希桶(数组的同一个位置)的键值对,使用Entry链表来存储(解决hash冲突)。


1

2

3

4

5

6

7

8

9

10

11

12

13

14

以下代码及注释来自java.util.HashTable

/**

 * The hash table data.

 */

private transient Entry<K,V>[] table;

以下代码及注释来自java.util.HashMap

/**

 * The table, resized as necessary. Length MUST Always be a power of two.

 */

transient Entry<K,V>[] table = (Entry<K,V>[]) EMPTY_TABLE;

从代码可以看到,对于哈希桶的内部表示,两个类的实现是一致的。

  4、算法

    第3点已经说了用来表示哈希表的内部数据结构。HashMap/HashTable还需要有算法来将给定的键key,映射到确定的hash桶(数组位置)。需要有算法在哈希桶内的键值对多到一定程度时,扩充哈希表的大小(数组的大小)。本小节比较这两个类在算法层面有哪些不同。

    初始容量大小和每次扩充容量大小的不同。先看代码:


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

以下代码及注释来自java.util.HashTable

// 哈希表默认初始大小为11

public Hashtable() {

    this(11, 0.75f);

}

protected void rehash() {

    int oldCapacity = table.length;

    Entry<K,V>[] oldMap = table;

    // 每次扩容为原来的2n+1

    int newCapacity = (oldCapacity << 1) + 1;

    // ...

}

以下代码及注释来自java.util.HashMap

// 哈希表默认初始大小为2^4=16

static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16

void addEntry(int hash, K key, V value, int bucketIndex) {

    // 每次扩充为原来的2n

    if ((size >= threshold) && (null != table[bucketIndex])) {

       resize(2 * table.length);

}

    可以看到HashTable默认的初始大小为11,之后每次扩充为原来的2n+1。HashMap默认的初始化大小为16,之后每次扩充为原来的2倍。还有我没列出代码的一点,就是如果在创建时给定了初始化大小,那么HashTable会直接使用你给定的大小,而HashMap会将其扩充为2的幂次方大小。

    也就是说HashTable会尽量使用素数、奇数。而HashMap则总是使用2的幂作为哈希表的大小。我们知道当哈希表的大小为素数时,简单的取模哈希的结果会更加均匀(具体证明,见这篇文章),所以单从这一点上看,HashTable的哈希表大小选择,似乎更高明些。但另一方面我们又知道,在取模计算时,如果模数是2的幂,那么我们可以直接使用位运算来得到结果,效率要大大高于做除法。所以从hash计算的效率上,又是HashMap更胜一筹。

    所以,事实就是HashMap为了加快hash的速度,将哈希表的大小固定为了2的幂。当然这引入了哈希分布不均匀的问题,所以HashMap为解决这问题,又对hash算法做了一些改动。具体我们来看看,在获取了key对象的hashCode之后,HashTable和HashMap分别是怎样将他们hash到确定的哈希桶(Entry数组位置)中的。


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

以下代码及注释来自java.util.HashTable

// hash 不能超过Integer.MAX_VALUE 所以要取其最小的31个bit

int hash = hash(key);

int index = (hash & 0x7FFFFFFF) % tab.length;

// 直接计算key.hashCode()

private int hash(Object k) {

    // hashSeed will be zero if alternative hashing is disabled.

    return hashSeed ^ k.hashCode();

}

以下代码及注释来自java.util.HashMap

int hash = hash(key);

int i = indexFor(hash, table.length);

// 在计算了key.hashCode()之后,做了一些位运算来减少哈希冲突

final int hash(Object k) {

    int h = hashSeed;

    if (0 != h && k instanceof String) {

        return sun.misc.Hashing.stringHash32((String) k);

    }

    h ^= k.hashCode();

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

}

// 取模不再需要做除法

static int indexFor(int h, int length) {

    // assert Integer.bitCount(length) == 1 : "length must be a non-zero power of 2";

    return h & (length-1);

}

    正如我们所言,HashMap由于使用了2的幂次方,所以在取模运算时不需要做除法,只需要位的与运算就可以了。但是由于引入的hash冲突加剧问题,HashMap在调用了对象的hashCode方法之后,又做了一些位运算在打散数据。关于这些位计算为什么可以打散数据的问题,本文不再展开了。感兴趣的可以看这里。

    如果你有细心读代码,还可以发现一点,就是HashMap和HashTable在计算hash时都用到了一个叫hashSeed的变量。这是因为映射到同一个hash桶内的Entry对象,是以链表的形式存在的,而链表的查询效率比较低,所以HashMap/HashTable的效率对哈希冲突非常敏感,所以可以额外开启一个可选hash(hashSeed),从而减少哈希冲突。因为这是两个类相同的一点,所以本文不再展开了,感兴趣的看这里。事实上,这个优化在JDK 1.8中已经去掉了,因为JDK 1.8中,映射到同一个哈希桶(数组位置)的Entry对象,使用了红黑树来存储,从而大大加速了其查找效率。

  5、关于效率问题:

    结论已经在文章开始时表名了,此处博主水准较低,并不是很能确认是因为以下几点导致:

    HashMap.put > HashTable.put:

      参照数据结构介绍,hasmMap的容量永远为2^*,所以HashMap在计算key所在位置时是采用了以为进行处理的;但此处会导致相同的hashcode变多,每个bucket(entry)的深度增加,所以后续put耗时较长。

    HashMap.get < HashTable.get:

       由于HashTable.get也做了同步处理,在这里对于锁的处理时间时HashTable的耗时过长(对于我自己不是很有说服力,因为在put时也有锁机制处理)

  6、HashTable已经配淘汰:

    

    如图为Hashtable(jdk1.7版本)的注释,已经很明确的表名了如果是单线程情况下建议使用HashMap,如果是多线程的情况下建议使用ConcurrentHashMap,此处可表明HashTable自己都不建议使用自己。

  关于第五点的具体原因希望有感兴趣的或者大牛帮忙解答下~~

原文地址:https://www.cnblogs.com/liu-eagles/p/9059931.html

时间: 2024-11-05 13:43:15

HashMap与HashTable源码学习及效率比较分析的相关文章

Java集合专题总结(1):HashMap 和 HashTable 源码学习和面试总结

2017年的秋招彻底结束了,感觉Java上面的最常见的集合相关的问题就是hash--系列和一些常用并发集合和队列,堆等结合算法一起考察,不完全统计,本人经历:先后百度.唯品会.58同城.新浪微博.趣分期.美团点评等都在1.2--面的时候被问过无数次,都问吐了&_&,其他公司笔试的时候,但凡有Java的题,都有集合相关考点,尤其hash表--现在总结下. Java集合概述 HashMap介绍 HashMap源码学习 关于HashMap的几个经典问题 HashTable介绍和源码学习 Hash

(转)HashMap和HashTable源码

转自: http://www.cnblogs.com/ITtangtang/p/3948406.html http://frankfan915.iteye.com/blog/1152091 一.HashMap概述二.HashMap的数据结构三.HashMap源码分析     1.关键属性     2.构造方法     3.存储数据     4.调整大小 5.数据读取                       6.HashMap的性能参数                      7.Fail-

Nmap 源码学习三 nmap_main主程序分析

主体程序位置在nmap.cc line:1640 学习要点: 程序在1650行,新建一个主机的单例对象, #ifndef NOLUA /* Only NSE scripts can add targets */ NewTargets *new_targets = NULL; /* Pre-Scan and Post-Scan script results datastructure */ ScriptResults *script_scan_results = NULL; #endif 从168

JDK源码学习系列08----HashMap

                                                          JDK源码学习系列08----HashMap 1.HashMap简介 HashMap 是一个散列表,它存储的内容是键值对(key-value)映射. HashMap 继承于AbstractMap,实现了Map.Cloneable.java.io.Serializable接口. HashMap 的实现不是同步的,这意味着它不是线程安全的.它的key.value都可以为null.此外,

Java多线程之JUC包:ReentrantLock源码学习笔记

若有不正之处请多多谅解,并欢迎批评指正. 请尊重作者劳动成果,转载请标明原文链接: http://www.cnblogs.com/go2sea/p/5627539.html ReentrantLock是JUC包提供的一种可重入独占锁,它实现了Lock接口.与Semaphore类似,ReentrantLock也提供了两种工作模式:公平模式&非公平模式,也是通过自定义两种同步器FairSync&NonfairSync来实现的. 源代码: /* * ORACLE PROPRIETARY/CONF

[Android FrameWork 6.0源码学习] View的重绘过程之WindowManager的addView方法

博客首页:http://www.cnblogs.com/kezhuang/p/ 关于Activity的contentView的构建过程,我在我的博客中已经分析过了,不了解的可以去看一下 <[Android FrameWork 6.0源码学习] Window窗口类分析> 本章博客是接着上边那篇博客分析,目的是为了引出分析ViewRootImpl这个类.现在只是分析完了Window和ActivityThread的调用过程 从ActivityThread到WindowManager再到ViewRoo

由JDK源码学习HashMap

HashMap基于hash表的Map接口实现,它实现了Map接口中的所有操作.HashMap允许存储null键和null值.这是它与Hashtable的区别之一(另外一个区别是Hashtable是线程安全的).另外,HashMap中的键值对是无序的.下面,我们从HashMap的源代码来分析HashMap的实现,以下使用的是Jdk1.7.0_51. 一.HashMap的存储实现 HashMap底层采用的是数组和链表这两种数据结构.当我们把key-value对put到HashMap时,系统会根据ha

【JDK1.8】 Java小白的源码学习系列:HashMap

目录 Java小白的源码学习系列:HashMap 官方文档解读 基本数据结构 基本源码解读 基本成员变量 构造器 巧妙的tableSizeFor put方法 巧妙的hash方法 JDK1.8的putVal方法 JDK1.8的resize方法 初始化部分 数组搬移部分 Java小白的源码学习系列:HashMap 春节拜年取消,在家花了好多天时间啃一啃HashMap的源码,同样是找了很多很多的资料,有JDK1.7的,也有JDK1.8的,当然本文基于JDK1.8.将所学到的东西进行整理,希望回过头再看

JDK1.8源码学习之 HashMap.java

///JDK1.8源码学习之HashMap.java package java.util; import java.io.IOException; import java.io.InvalidObjectException; import java.io.Serializable; import java.lang.reflect.ParameterizedType; import java.lang.reflect.Type; import java.util.function.BiConsu