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自己都不建议使用自己。

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