认识达内从这里开始

我们除了需要学习java编程的基础知识以外，同时还需要掌握不同的数据结构的分析方法。而今天我们就给大家简单介绍一下，哈希表对于java编程都有哪些作用。

1.哈希表介绍

前面我们已经介绍了许多类型的数据结构。在想要查询容器内特定元素时，有序向量使得我们能使用二分查找法进行精确的查询((O(logN)对数复杂度，很高效)。

可人类总是不知满足，依然在寻求一种更高效的特定元素查询的数据结构，哈希表/散列表(hash table)就应运而生啦。哈希表在特定元素的插入，删除和查询时都能够达到O(1)常数的时间复杂度,十分高效。

1.1 哈希算法

哈希算法的定义：把任意长度的输入通过哈希算法转换映射为固定长度的输出，所得到的输出被称为哈希值(hashCode = hash(input))。哈希映射是一种多对一的关系，即多个不同的输入有可能对应着一个相同的哈希值输出;也意味着，哈希映射是不可逆，无法还原的。

举个例子：我们有一个好朋友叫熊大,大家都叫他老熊。可以理解为是一个hash算法：对于一个人名，我们一般称呼为"老" + 姓氏(单姓) (hash(熊大) = 老熊)。同时，我们还有一个好朋友叫熊二,我们也叫他老熊(hash(熊二) = 老熊)。当熊大和熊二两个好朋友同时和我们聚会时，都称呼他们为老熊就不太合适啦，因为这时出现了hash冲突。老熊这个称呼同时对应了多个人，多个不同的输入对应了相同的哈希值输出。

java在Object这一高层对象中实现了hashCode方法，并允许子类重写更适应自身，冲突概率更低的hashCode方法。

1.2 哈希表实现的基本思路

哈希表存储的是key-value键值对结构的数据，其基础是一个数组。

由于采用hash算法会出现hash冲突，一个数组下标对应了多个元素。常见的解决hash冲突的方法有：开放地址法、重新哈希法、拉链法等等，我们的哈希表实现采用的是拉链法解决hash冲突。

采用拉链法的哈希表将内部数组的每一个元素视为一个插槽(slot)或者桶(bucket)，并将数据存放在键值对节点(EntryNode)中。EntryNode除了存放key和value，还维护着一个next节点的引用。为了解决hash冲突，单个插槽内的多个EntryNode构成一个简单的单向链表，插槽指向链表的头部节点，新的数据将会插入当前链表的尾部。

key值不同但映射的hash值相同的元素在哈希表的同一个插槽中以链表的形式共存。

1.3 哈希表的负载因子(loadFactor)：

哈希表在查询数据时通过直接计算数据hash值对应的插槽，迅速获取到key值对应的数据，进行非常高效的数据查询。

但依然存在一个问题：虽然设计良好的hash函数可以尽可能的降低hash冲突的概率，但hash冲突还是不可避免的。当发生频繁的哈希冲突时，对应的插槽内可能会存放较多的元素，导致插槽内的链表数据过多。而链表的查询效率是非常低的，在极端情况下，甚至会出现所有元素都映射存放在同一个插槽内，此时的哈希表退化成了一个链表，查询效率急剧降低。

一般的，哈希表存储的数据量一定时，内部数组的大小和数组插槽指向的链表长度成反比。换句话说，总数据量一定，内部数组的容量越大(插槽越多)，平均下来桶链表的长度也就越小，查询效率越高。

同等数据量下，哈希表内部数组容量越大，查询效率越高，但同时空间占用也越高，这本质上是一个空间换时间的取舍。

哈希表允许用户在初始化时指定负载因子(loadFactor)：负载因子代表着存储的总数据量和内部数组大小的比值。插入新数据时，判断哈希表当前的存储量和内部数组的比值是否超过了负载因子。当比值超过了负载因子时，哈希表认为内部过于拥挤，查询效率太低，会触发一次扩容的rehash操作。rehash会对内部数组扩容，将存储的元素重新进行hash映射，使得哈希表始终保持一个合适的查询效率。

通过指定自定义的负载因子，用户可以控制哈希表在空间和时间上取舍的程度，使哈希表能更有效地适应用户的使用场景。

指定的负载因子越大，哈希表越拥挤(负载高，紧凑)，查询效率越低，空间效率越高。

指定的负载因子越小，哈希表越稀疏(负载小，松散)，查询效率越高，空间效率越低。

2.哈希表ADT接口

和之前介绍的链表不同，我们在哈希表的ADT接口中暴露出了哈希表内部实现的EntryNode键值对节点。通过暴露出去的public方法，用户在使用哈希表时，可以获得内部的键值对节点，灵活的访问其中的key、value数据(但没有暴露setKey方法，不允许用户自己设置key值)。

3.哈希表性能

3.1 空间效率：

哈希表的空间效率很大程度上取决于负载因子。通常，为了保证哈希表查询的高效性，负载因子都设置的比较小(小于1)，因而可能会出现许多空的插槽，浪费空间。

总体而言，哈希表的空间效率低于向量和链表。

3.2 时间效率：

一般的，哈希表增删改查接口的时间复杂度都是O(1)。但是出现较多的hash冲突时，冲突范围内的key的增删改查效率较低，时间效率会有一定的波动。

总体而言，哈希表的时间效率高于向量和链表。

哈希表的时间效率很高，可天下没有免费的午餐，据统计，哈希表的空间利用率通常情况下还不到50%。

哈希表是一个使用空间来换取时间的数据结构，对查询性能有较高要求的场合，可以考虑使用哈希表。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。