散列使得查询速度提升，HashMap如此快的原因

 本文来自《Thinking in java 3th》

散列的价值在于速度：散列使得查询得以快速进行。由于速度的瓶颈是对“键”的查询，因此解决的方案之一就是保持“键”的排序状态，然后使用Collections.binarySearch进行查询。散列则更进一步，他将“键”保存在某处，使你能够快速找到。存储一组元素最快的数据结构是数组，所以使用他来代表“键”的信息（注意：是“键”的信息，而不是“键”本身）。但是数组有一个特性：一旦分配，容量就不能改变。因此我们就有一个问题：我们需要在Map中保存任意数量的“值”，但是如果“键”的数量被数组容量限制了，该怎么办呢？

答案就是：数组并不保存”键“本身。而是通过”键“对象生成一个数字，将其作为数组的下标索引。这个数字就是散列码，由定义在Object中的hashCode生成（也称散列函数）。你的类总是应该重载hashCode方法。为解决数组容量被固定的问题，不同的”键“可以产生相同的下标。也就是说，可能会有冲突（collision）。因此数组多大就不重要了，每个”键“总能在数组中找到他的位置。

于是查询一个”值“的过程首先就是计算散列码，然后使用散列码查询数组。如果保证没有冲突（如果”值“的数量是固定的，就有可能），那你可就有了一个完美的散列函数，但是这种情况很特殊。通常，冲突是由”外部链接（external chaining）“处理：数组并不直接保存“值”，而是保存“值”的list。然后对list中的“值”使用equals方法进行现行查询。这部分的查询自然比较慢。但是，如果有好的散列函数，数组的每个位置就只有较少的“值”。因此，不是查询所有的list，而是快速跳到数组的某个位置，只对很少的元素进行比较。这就是HashMap会如此快的原因。

HashMap的性能因子：

容量（Capacity）：散列表中桶的数量

初始化容量（Initial capacity）：创建散列表时桶的数量。HashMap和HashSet都允许你在构造器中制定初始化容量。

尺寸（Size）：当前散列表中记录的数量。

负载因子（Load factor）：等于“size/capacity”。等于零，表示空的散列表，0.5表示半满的散列表。轻负载的散列表具有冲突少、适宜插入与查询的特点（但是使用迭代器遍历会变慢）。HashMap和HashSet都允许你在构造器中指定负载因子，当负载到达指定值时，容器会自动成倍的增加容量，并将原有的对象重新分配，存入新桶中（成为“重散列”rehashing）。