前言：我们经常会听见很多的概念，哈希值，哈希表，可哈希对象，不可哈希对象，散列表，字典，映射，等等，那么这么多的概念后面到底又有什么区别和联系，它们的本质又是怎么样的，本此系列文章将针对这些概念进行说明，鉴于篇幅较多，本次系列文章将分为两篇来说明，此为第一篇，介绍数据结构哈希表与哈希值。

1.1 从一个简单的现象说起

        顺序存储的结构类型需要一个一个地按顺序访问元素，比如一个数组为【1,2,3,4,5,6,7,8】，当我们需要查找元素7在那个地方的时候，我们从第一个元素开始依次与7对比，找到相等的就是我们需要的7.

当这个总量很大且我们所要访问的元素比较靠后时，性能就会很低，因为要依次查找。

哪有没有更简单的方法呢？肯定有。

由于每一个元素在计算机内都是存储在某一段内存（地址）中的，如果我需要查找的元素是7，而且我知道了7这个元素存储在那个地址上，那我要查找7，我直接到这个内存去取出来即可，这其实就是哈希表的思想。

在我们的生活中，有很多这样的例子，比如查词典，查找通讯录等等，如果都是一个一个遍历，这简直不敢想象。

        让我们想一下，若在手机通信录中查找一个人，那我们应该不会从第 1 个人一直找下去，因为这样实在是太慢了。我们其实是这样做的：首先看这个人的名字的首字母是什么，比如姓张，那么我们一定会滑到最后，因为“Z”姓的名字都在最后。还有在查字典时，要查找一个单词，肯定不会从头翻到尾，而是首先通过这个单词的首字母，找到对应的那一页；再找第 2 个字母、第 3 个字母……这样可以快速跳到那个单词所在的页。

那么问题来了，我要怎么才能知道7是存储在哪个地方的呢？也就是说7这个元素应该与它所在的位置有一个一一对应的关系，这个对应的关系其实就是一种函数映射，及按照某一种规则的映射，这个规则就是哈希函数，也称之为散列函数。

1.2 哈希表（散列表）——hash table

哈希表，又称之为散列表，是一种空间换时间的存储结构，是在算法中提升效率的一种比较常用的方式，但是所需空间太大也会让人头疼，所以通常需要在二者之间权衡。我们会在之后的具体算法章节中得到更多的领悟。

哈希表（散列表），是能够通过给定的关键字的值直接访问到具体对应的值的一个数据结构。也就是说，把关键字映射到一个表中的位置来直接访问记录，以加快访问速度。

（1）一些关键概念

（2）总结

总而言之一句话：

存储位置=hash(键)

value = hash(key)

1.3 举一个小的例子

举一个例子，有一个数组：【5,8,12,17,20】，这里的键Key就是这5个元素，我们假设一个哈希函数为：

hash(x)=x%17+3

得出如下结果：hash(5)=8、hash(8)=11、hash(12)=15、hash(17)=3、hash(20)=6。我们把【5,8,12,17,20】分别放到地址为8、11、15、3、6的位置上。当要检索17对应的值的时候，只要首先计算17的哈希值为3，然后到地址为3的地方去取数据就可以了，可见检索速度是非常快的。

注意：这个地方好像跟字典很像，我们后面再详细说明。

1.4 哈希表的问题——碰撞Clollision

其中有个特殊情况，就是通过不同的 Key，可能访问到同一个地址，这种现象叫作碰撞（Collision）。

通常键的取值范围比哈希表地址集合大很多，因此有可能经过同一哈希函数的计算，把不同的键映射到了同一个地址上面，这就叫冲突。比如，有一组“键-值对”，其键分别为12361、7251、3309、30976，采用的哈希函数是：

则将会得到hash(12361)=hash(7251)=hash(3309)=hash(30976)=13444，即不同的键通过哈希函数对应到了同一个地址，我们称这种哈希计算结果相同的不同键为同义词。

如果“键-值对”在加入哈希表的时候产生了冲突，就必须找另外一个地方来存放它，冲突太多会降低数据插入和搜索的效率，因此希望能找到一个不容易产生冲突的函数，即构造一个地址分布比较均匀的哈希函数。

1.5 哈希函数的构造以及常见的哈希函数

一个好的散列表设计，除了需要选择一个性能较好的哈希函数，否则冲突是无法避免的，所以通常还需要有一个好的冲突处理方式，目前，这个哈希函数比较常用的实现方法比较多，通常需要考虑几个因素：关键字的长度、哈希表的大小、关键字的分布情况、记录的查找频率，等等。常见的一些哈希函数有：

当出现冲突的时候，处理冲突的一些方法有：

1.6 哈希表（散列表）的特点 根据散列表的存储结构，我们可以得出散列表的以下特点。

（1）访问速度很快

由于散列表有散列函数，可以将指定的 Key 都映射到一个地址上，所以在访问一个 Key（键）对应的 Value（值）时，根本不需要一个一个地进行查找，可以直接跳到那个地址。所以我们在对散列表进行添加、删除、修改、查找等任何操作时，速度都很快。

（2）需要额外的空间

首先，散列表实际上是存不满的，如果一个散列表刚好能够存满，那么肯定是个巧合。而且当散列表中元素的使用率越来越高时，性能会下降，所以一般会选择扩容来解决这个问题。另外，如果有冲突的话，则也是需要额外的空间去存储的，比如链地址法，不但需要额外的空间，甚至需要使用其他数据结构。比如上面的例子中，本来我只需要存储数据【5,8,12,17,20】即可，但是使用哈希表我还需要存储经过哈希运算的的哈希值【8,11,15,3,6】，这就是所谓的“用空间换取时间” 这个特点有个很常用的词可以表达，叫作“空间换时间”，在大多数时候，对于算法的实现，为了能够有更好的性能，往往会考虑牺牲些空间，让算法能够更快些。

（3）无序

散列表还有一个非常明显的特点，那就是无序。为了能够更快地访问元素，散列表是根据散列函数直接找到存储地址的，这样我们的访问速度就能够更快，但是对于有序访问却没有办法应对。

（4）可能会产生碰撞

没有完美的散列函数，无论如何总会产生冲突，这时就需要采用冲突解决方案，这也使散列表更加复杂。通常在不同的高级语言的实现中，对于冲突的解决方案不一定一样。

1.6 hash值需要遵守的约定

从上面来看哈希表与字典有很多的相同点，他们都是一种 的形式，他们都是一种 Map 关系，也就是人们俗称的键值对集合。

关于他们这两个概念的详细含义，我目前还没有找到特别权威的说法，很多都是依据java里面或者是C#里面的数据集合类来加以说明的，所以这里就不再展开。