【数据结构】哈希表

系统管理员 2024-04-23 20:31 7阅读 0赞

> ⭐ 作者：小胡\_不糊涂  
> 🌱 作者主页：[小胡\_不糊涂的个人主页][Link 1]  
> 📀 收录专栏：[浅谈数据结构][Link 2]  
> 💖 持续更文，关注博主少走弯路，谢谢大家支持 💖

#### 哈希表 ####

*  1. 概念
 *  2. 什么是冲突
 *  3. 降低冲突可能性-哈希函数设计
 *  4. 避免冲突-负载因子调节
 *  5. 解决冲突
 *   *  5.1 闭散列
     *  5.2 开散列/哈希桶

![在这里插入图片描述][1705be2f0ddd44d89cbace6f14b68232.gif_pic_center]

## 1. 概念 ##

顺序结构以及平衡树中，元素关键码与其存储位置之间没有对应的关系，因此在查找一个元素时，必须要经过关键码的多次比较。**顺序查找时间复杂度为O(N)，平衡树中为树的高度，即O( lon2(N))**，搜索的效率取决于搜索过程中元素的比较次数。

**理想的搜索方法**：可以不经过任何比较，**一次直接从表中得到要搜索的元素。** 如果构造一种存储结构，通过某种函数(hashFunc)使元素的存储位置与它的关键码之间能够建立一一**映射的关系**，那么在查找时通过该函数可以很快找到该元素。

> 当向该结构中：  
> 　插入元素：根据待插入元素的关键码，以此函数计算出该元素的存储位置并按此位置进行存放  
> 　搜索元素：对元素的关键码进行同样的计算，把求得的函数值当做元素的存储位置，在结构中按此位置取元素比较，若关键码相等，则搜索成功  
> 　**该方式即为哈希(散列)方法，** 哈希方法中使用的**转换函数称为哈希(散列)函数**，构造出来的结构称为**哈希表(HashTable)(或者称散列表)**  
> 例如：数据集合\{1，7，6，4，5，9\}；  
> **哈希函数**设置为：hash(key) = key % capacity; capacity为存储元素底层空间总的大小。  
> ![在这里插入图片描述][51e760bb678d43cfbca98842eae8a644.png]

用该方法进行搜索不必进行多次关键码的比较，因此搜索的速度比较快。但是按照上述哈希方式，向集合中插入元素44，就会产生一个问题：hash(44)=44%10=4，而上面的4下标里已经有了一个元素，这就会产生**冲突**。

## 2. 什么是冲突 ##

对于两个数据元素的关键字Ki和Kj (i != j)，有 Ki!=Kj ，但有：Hash(Ki) == Hash(Kj)，即：不同关键字通过相同哈希函数计算出相同的哈希地址，该种现象称为**哈希冲突或哈希碰撞**。  
把具有不同关键码而具有相同哈希地址的数据元素称为“同义词”。

> **如何避免哈希冲突呢？**  
> 　首先，我们需要明确一点，由于我们哈希表底层数组的容量往往是小于实际要存储的关键字的数量的，这就导致一个问题，冲突的发生是必然的，但我们能做的应该是**尽量的降低冲突率**。

## 3. 降低冲突可能性-哈希函数设计 ##

引起哈希冲突的一个原因可能是：哈希函数设计不够合理。  
**哈希函数设计原则：**

*  哈希函数的定义域必须包括需要存储的全部关键码，而如果散列表允许有m个地址时，其值域必须在0到m-1之间
 *  哈希函数计算出来的地址能均匀分布在整个空间中
 *  哈希函数应该比较简单

**常见哈希函数：**

1.  **直接定制法**  
    取关键字的某个线性函数为散列地址：Hash（Key）= A\*Key + B 优点：简单、均匀缺点：**需要事先知道关键字的分布情况使用场景：适合查找比较小且连续的情况。**
2.  **除留余数法**  
    设散列表中允许的地址数为m，取一个不大于m，但最接近或者等于m的质数p作为除数，按照哈希函数：Hash(key) = key% p(p<=m),将关键码转换成哈希地址。
3.  **平方取中法**  
    假设关键字为1234，对它平方就是1522756，抽取中间的3位227作为哈希地址；再比如关键字为4321，对它平方就是18671041，抽取中间的3位671(或710)作为  
    **哈希地址平方取中法比较适合：不知道关键字的分布，而位数又不是很大的情况。**
4.  **折叠法**  
    折叠法是将关键字从左到右分割成位数相等的几部分(最后一部分位数可以短些)，然后将这几部分叠加求和，并按散列表表长，取后几位作为散列地址。  
    **折叠法适合事先不需要知道关键字的分布，适合关键字位数比较多的情况**。
5.  **随机数法**  
    选择一个随机函数，取关键字的随机函数值为它的哈希地址，即H(key) = random(key),其中random为随机数函数。  
    **通常应用于关键字长度不等时采用此法**。
6.  **数学分析法**  
    设有n个d位数，每一位可能有r种不同的符号，这r种不同的符号在各位上出现的频率不一定相同，可能在某些位上分布比较均匀，每种符号出现的机会均等，在某些位上分布不均匀只有某几种符号经常出现。可根据散列表的大小，选择其中各种符号分布均匀的若干位作为散列地址。  
    ![在这里插入图片描述][43fdce976f3845c0b1c53371fb83ae14.png]

例如：  
假设要存储某家公司员工登记表，如果用手机号作为关键字，那么极有可能前7位都是相同的，那么我们可以选择后面的四位作为散列地址，如果这样的抽取工作还容易出现冲突，还可以对抽取出来的数字进行反转(如1234改成4321)、右环位移(如1234改成4123)、左环移位、前两数与后两数叠加(如1234改成12+34=46)等方法。  
**数字分析法通常适合处理关键字位数比较大的情况，如果事先知道关键字的分布且关键字的若干位分布较均  
匀的情况**。

注意： 哈希函数设计的越精妙，产生哈希冲突的可能性就越低，但是无法避免哈希冲突。

## 4. 避免冲突-负载因子调节 ##

![在这里插入图片描述][61077d5f4bf84949944a109f8a7f85bb.png]

> 负载因子和冲突率的关系粗略演示：![在这里插入图片描述][099e7acdf3f94b37864dd23e009a0046.png]  
> 当冲突率达到一个无法忍受的程度时，我们需要通过降低负载因子来变相的降低冲突率。  
> 已知哈希表中已有的关键字个数是不可变的，那我们能调整的就只有哈希表中的数组的大小

## 5. 解决冲突 ##

**解决哈希冲突两种常见的方法是：闭散列和开散列**

### 5.1 闭散列 ###

**闭散列**：也叫开放定址法，当发生哈希冲突时，如果哈希表未被装满，说明在哈希表中必然还有空位置，那么可以把key存放到冲突位置中的“下一个”空位置中去。那如何寻找下一个空位置呢？

1.  **线性探测**  
    比如上面的场景，现在需要插入元素44，先通过哈希函数计算哈希地址，下标为4，因此44理论上应该插在该位置，但是该位置已经放了值为4的元素，即发生哈希冲突。  
    **线性探测**：从发生冲突的位置开始，依次向后探测，直到寻找到下一个空位置为止。

> 插入
> 
>  *  通过哈希函数获取待插入元素在哈希表中的位置
>  *  如果该位置中没有元素则直接插入新元素，如果该位置中有元素发生哈希冲突，使用线性探测找到下一个空位置，插入新元素  
>     ![在这里插入图片描述][22ff54bed4a04e0aa790faa712d04909.png]
>  *  采用闭散列处理哈希冲突时，不能随便物理删除哈希表中已有的元素，若直接删除元素会影响其他元素的搜索。比如删除元素4，如果直接删除掉，44查找起来可能会受影响。因此线性探测采用标记的伪删除法来删除一个元素。

1.  **二次探测**  
    线性探测的缺陷是产生冲突的数据堆积在一块，这与其找下一个空位置有关系，因为找空位置的方式就是挨着往后逐个去找，因此二次探测为了避免该问题，找下一个空位置的方法为：Hi = (H0 +i^2)%m，或者：Hi= (H0-i^2)%m。其中：i ==1,2,3…，H0是通过散列函数Hash(x)对元素的关键码 key 进行计算得到的位置，m是表的大小。 对于2.1中如果要插入44，产生冲突，使用解决后的情况为：  
    ![在这里插入图片描述][353ebfaf1220406cb1f071f7d7b6e0bb.png]  
    注意： 当表的长度为质数且表装载因子a不超过0.5时，新的表项一定能够插入，而且任何一个位置都不会被探查两次。因此只要表中有一半的空位置，就不会存在表满的问题。在搜索时可以不考虑表装满的情况，但在插入时必须确保表的装载因子a不超过0.5，如果超出必须考虑增容。

因此：比散列最大的缺陷就是空间利用率比较低，这也是哈希的缺陷。

### 5.2 开散列/哈希桶 ###

开散列法又叫链地址法(开链法)，首先对关键码集合用散列函数计算散列地址，具有相同地址的关键码归于同一子集合，\*\*每一个子集合称为一个桶，\*\*各个桶中的元素通过一个单链表链接起来，各链表的头结点存储在哈希表中。  
![在这里插入图片描述][12ef3a3855f3465083b4b9ff08441cc0.png]  
从上图可以看出，开散列中每个桶中放的都是发生哈希冲突的元素。  
**开散列，可以认为是把一个在大集合中的搜索问题转化为在小集合中做搜索了。**

哈希桶的实现：

ublic class HashBuck {
        
        static class Node {
        
            public int key;
            public int val;
            public Node next;
            public Node(int key, int val) {
        
                this.key = key;
                this.val = val;
            }
        }
    
        public Node[] array;
        public int usedSize;//存放了多少个数据
        public static final float DEFAULT_LOAD_FACTOR = 0.75f;//载荷因子
    
        public HashBuck() {
        
            array = new Node[10];
        }
    
        public void put(int key,int val) {
        
            int index = key % array.length;
            //遍历index下标的链表是否存在key：存在更新value；不存在则插入数据
            Node cur = array[index];
            while (cur != null) {
        
                if(cur.key == key) {
        
                    //更新value
                    cur.val = val;
                    return;
                }
                cur = cur.next;
            }
            //cur == null 链表遍历完成 没有找到这个key
            Node node = new Node(key,val);
            node.next = array[index];
            array[index] = node;
            usedSize++;//8
            if(doLoadFactor() > DEFAULT_LOAD_FACTOR) {
        
                //扩容！！
                //array = Arrays.copyOf(array,2*array.length);error
                resize();
            }
        }
    
        private void resize() {
        
            Node[] newArray = new Node[2*array.length];
            //遍历原来的数组
            for (int i = 0; i < array.length; i++) {
        
                Node cur = array[i];
                //遍历每个数组元素(链表)
                while (cur != null) {
        
                    Node tmp = cur.next;
                    int newIndex = cur.key % newArray.length;//新的数组下标
                    //采用头插法 插入到新数组的 newIndex下标
                    cur.next = newArray[newIndex];
                    newArray[newIndex] = cur;
                    cur = tmp;
                }
            }
            array = newArray;
        }
    
        private float doLoadFactor() {
        
            return usedSize*1.0f / array.length;
        }
    
        public int get(int key) {
        
            int index = key % array.length;
            Node cur = array[index];
            while (cur != null) {
        
                if(cur.key == key) {
        
                    return cur.val;
                }
                cur = cur.next;
            }
            return -1;
        }
    }

虽然哈希表一直在和冲突做斗争，但在实际使用过程中，我们认为哈希表的冲突率是不高的，冲突个数是可控的，也就是每个桶中的链表的长度是一个常数，所以，通常意义下，我们认为哈希表的插入/删除/查找时间复杂度是O(1) 。

小结：

1.  HashMap 和 HashSet 即 java 中利用哈希表实现的 Map 和 Set
2.  java 中**使用的是哈希桶方式解决冲突**的
3.  java 会在冲突链表长度大于一定阈值后，将链表转变为搜索树（红黑树），即：(当数组长度>=64 &&链表长度>=8以后，把链表变成红黑树)
4.  java 中计算哈希值实际上是调用的类的 hashCode 方法，进行 key 的相等性比较是调用 key 的 equals 方法。所以如果要用自定义类作为 HashMap 的 key 或者 HashSet 的值，必须覆写 hashCode 和 equals 方法，而且要做到 equals 相等的对象，hashCode 一定是一致的。

[Link 1]: https://blog.csdn.net/iLoyo_
[Link 2]: http://t.csdnimg.cn/pu3jy
[1705be2f0ddd44d89cbace6f14b68232.gif_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/23/c3008733fc644fbebf3aa0938618cf22.gif
[51e760bb678d43cfbca98842eae8a644.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/23/2946e5e7c0b249d59651214be43258f4.png
[43fdce976f3845c0b1c53371fb83ae14.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/23/5d3e272725bf466b9f5ac9ed0e155ea0.png
[61077d5f4bf84949944a109f8a7f85bb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/23/248fdb64c27447b0af099787be8e0d7d.png
[099e7acdf3f94b37864dd23e009a0046.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/23/4ebb6687a69f4e62926b0519a3befe88.png
[22ff54bed4a04e0aa790faa712d04909.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/23/ed3ef330cde3416a86b51738082e93d7.png
[353ebfaf1220406cb1f071f7d7b6e0bb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/23/a1817101c8f64d7d9237b457a51a9908.png
[12ef3a3855f3465083b4b9ff08441cc0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/23/b79d356325e84bb2bbe765c0a15f056b.png