一.综述
可以直接根据hashcode值判断两个对象是否相等吗？肯定是不可以的，因为不同的对象可能会生成相同的hashcode值。虽然不能根据hashcode值判断两个对象是否相等，但是可以直接根据hashcode值判断两个对象不等，如果两个对象的hashcode值不等，则必定是两个不同的对象。如果要判断两个对象是否真正相等，必须通过equals方法。
也就是说对于两个对象，如果调用equals方法得到的结果为true，则两个对象的hashcode值必定相等；如果equals方法得到的结果为false，则两个对象的hashcode值不一定不同；如果两个对象的hashcode值不等，则equals方法得到的结果必定为false；如果两个对象的hashcode值相等，则equals方法得到的结果未知。
HashMap和Hashtable不保证map的顺序，也不保证顺序不会随着时间不变。
HashMap实例有两个参数影响性能：初始capacity和load factor。capacity是hashtable中桶的数量，初始capacity就是hashtable创建时的capacity。load factor影响hashtable多满时允许自动增加capacity。当hashtable中entry的数量超过load factor和当前capacity的乘积，hashtable会重新哈希（意味着，内部数据结构重建）因此hashtable大约拥有桶数量的两倍。
作为通用规则，默认load factor（0.75）在时间和空间消耗上提供了好的权衡。值越大，空间开销越小，但是遍历成本增加（表现在大多数操作，包括get和put）。当设置初始capacity时，为了最小化重新hash的操作次数，应该考虑map的entry数量和load factor。如果初始容量大于最大entry数量除以load factor，重新hash操作将不会发生。然而，设置初始capacity太大会浪费空间。
如果许多mapping存储在HashMap实例中，创建时使用足够大的capacity将允许mapping存储得更有效率，因为不会随着table的数量增大重新hash。注意使用许多相同hashCode()的key肯定会降低任意hashtable的性能。
二.相同点
|
DEFAULT_LOAD_FACTOR
|
0.75
|
|
TREEIFY_THRESHOLD
|
8
|
|
UNTREEIFY_THRESHOLD
|
6
|
|
MIN_TREEIFY_CAPACITY
否则resize()
|
64
|
|
size
|
mapping数量
|
|
threhold
|
capacity*load factor
|
二.不同点
|
|
HashMap
|
Hashtable
|
|
线程安全
|
不安全
|
安全
|
|
允许null的键和值
|
允许
|
不允许
|
|
实现和继承
|
实现Map
|
实现Map，继承Dictionary
|
|
遍历方式
|
Iterator
|
Iterator和Enumeration
|
|
计算哈希值
|
(key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16)
|
(key.hashCode() & 0x7FFFFFFF)
|
|
计算数组下标
当length总是 2 的n次方时，h& (length-1)运算等价于对length取模，也就是h%length，但是&比%具有更高的效率。
|
(length - 1) & hash
|
hash % length
|
|
DEFAULT_INITIAL_CAPACITY
|
16
|
11
|
|
容量增加方式
所以说，当数组长度为2的n次幂的时候，不同的key算得得index相同的几率较小，那么数据在数组上分布就比较均匀，也就是说碰撞的几率小，相对的，查询的时候就不用遍历某个位置上的链表，这样查询效率也就较高了。
导致resize()不同
HashMap直接使用之前的数组下表，而Hashtable需要重新计算 一.综述
可以直接根据hashcode值判断两个对象是否相等吗？肯定是不可以的，因为不同的对象可能会生成相同的hashcode值。虽然不能根据hashcode值判断两个对象是否相等，但是可以直接根据hashcode值判断两个对象不等，如果两个对象的hashcode值不等，则必定是两个不同的对象。如果要判断两个对象是否真正相等，必须通过equals方法。
也就是说对于两个对象，如果调用equals方法得到的结果为true，则两个对象的hashcode值必定相等；如果equals方法得到的结果为false，则两个对象的hashcode值不一定不同；如果两个对象的hashcode值不等，则equals方法得到的结果必定为false；如果两个对象的hashcode值相等，则equals方法得到的结果未知。
HashMap和Hashtable不保证map的顺序，也不保证顺序不会随着时间不变。
HashMap实例有两个参数影响性能：初始capacity和load factor。capacity是hashtable中桶的数量，初始capacity就是hashtable创建时的capacity。load factor影响hashtable多满时允许自动增加capacity。当hashtable中entry的数量超过load factor和当前capacity的乘积，hashtable会重新哈希（意味着，内部数据结构重建）因此hashtable大约拥有桶数量的两倍。
作为通用规则，默认load factor（0.75）在时间和空间消耗上提供了好的权衡。值越大，空间开销越小，但是遍历成本增加（表现在大多数操作，包括get和put）。当设置初始capacity时，为了最小化重新hash的操作次数，应该考虑map的entry数量和load factor。如果初始容量大于最大entry数量除以load factor，重新hash操作将不会发生。然而，设置初始capacity太大会浪费空间。
如果许多mapping存储在HashMap实例中，创建时使用足够大的capacity将允许mapping存储得更有效率，因为不会随着table的数量增大重新hash。注意使用许多相同hashCode()的key肯定会降低任意hashtable的性能。
二.相同点
|
DEFAULT_LOAD_FACTOR
|
0.75
|
|
TREEIFY_THRESHOLD
|
8
|
|
UNTREEIFY_THRESHOLD
|
6
|
|
MIN_TREEIFY_CAPACITY
否则resize()
|
64
|
|
size
|
mapping数量
|
|
threhold
|
capacity*load factor
|
二.不同点
|
|
HashMap
|
Hashtable
|
|
线程安全
|
不安全
|
安全
|
|
允许null的键和值
|
允许
|
不允许
|
|
实现和继承
|
实现Map
|
实现Map，继承Dictionary
|
|
遍历方式
|
Iterator
|
Iterator和Enumeration
|
|
计算哈希值
|
(key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16)
|
(key.hashCode() & 0x7FFFFFFF)
|
|
计算数组下标
当length总是 2 的n次方时，h& (length-1)运算等价于对length取模，也就是h%length，但是&比%具有更高的效率。
|
(length - 1) & hash
|
hash % length
|
|
DEFAULT_INITIAL_CAPACITY
|
16
|
11
|
|
容量增加方式
所以说，当数组长度为2的n次幂的时候，不同的key算得得index相同的几率较小，那么数据在数组上分布就比较均匀，也就是说碰撞的几率小，相对的，查询的时候就不用遍历某个位置上的链表，这样查询效率也就较高了。
导致resize()不同
HashMap直接使用之前的数组下表，而Hashtable需要重新计算
|
old*2
长度始终为2的幂
|
old*2+1
|
|
构造函数
|
threshold=tableSizeFor(initialCapacity)
|
threhold=initialCapacity*load factor
|
|
resize
|
从0-cap
链表顺序不变
|
从cap-0
链表顺序相反
|
|
|
