本文来说下Redis数据结构之哈希

---

概述

大部分编程语言都提供了 哈希（hash）类型，它们的叫法可能是 哈希、字典、关联数组。在 Redis 中，哈希类型 是指键值本身又是一个 键值对结构。

哈希 形如 value={ {field1，value1}，…{fieldN，valueN} }，Redis 键值对 和 哈希类型 二者的关系如图所示

哈希类型中的 映射关系 叫作 field-value，这里的 value 是指 field 对应的 值，不是 键 对应的值。

---

Redis hash结构命令

官网 https://redis.io/commands#hash

---

相关命令

基本命令

设置值：hset key field value

下面为 user：1 添加一对 field-value，如果设置成功会返回 1，反之会返回 0。

127.0.0.1:6379> hset user:1 name tom
(integer) 1
(1.89s)

此外 Redis 提供了 hsetnx 命令，它们的关系就像 set 和 setnx 命令一样，只不过 作用域 由 键 变为 field。

---

获取值：hget key field

下面操作用于获取 user：1 的 name 域（属性） 对应的值。

127.0.0.1:6379> hget user:1 name
"tom"

如果 键 或 field 不存在，会返回 nil：

127.0.0.1:6379> hget user:1 name
"tom"
127.0.0.1:6379> hget user:2 name
(nil)
127.0.0.1:6379> hget user:1 age
(nil)
127.0.0.1:6379>

---

删除field：hdel key field [field …]

hdel 会删除 一个或多个 field，返回结果为 成功删除 field 的个数，例如：

127.0.0.1:6379> hdel user:1 name
(integer) 1
127.0.0.1:6379> hdel user:1 age
(integer) 0
127.0.0.1:6379>

---

计算field个数：hlen key

例如键 user：1 有 3 个 field：

127.0.0.1:6379> hset user:1 name tom
(integer) 1
127.0.0.1:6379> hset user:1 age 24
(integer) 1
127.0.0.1:6379> hset user:1 city shanghai
(integer) 1
127.0.0.1:6379> hlen user:1
(integer) 3
127.0.0.1:6379>

---

批量设置或获取field-value：hmget key field [field …] hmset key field value [field value …]

hmset 和 hmget 分别是 批量设置 和 获取 field-value，hmset 需要的参数是 key 和 多对 field-value，hmget 需要的参数是 key 和 多个 field。例如：

127.0.0.1:6379> hmset user:1 name tom age 12 city shanghai
OK
127.0.0.1:6379> hmget user:1 name city
1) "tom"
2) "shanghai"
127.0.0.1:6379>

---

判断field是否存在：hexists key field

例如 user：1 包含 name 域，所以返回结果为 1，不包含时返回 0：

127.0.0.1:6379> hexists user:1 name
(integer) 1
127.0.0.1:6379> hexists user:1 names
(integer) 0
127.0.0.1:6379>

---

获取所有field：hkeys key

hkeys 命令应该叫 hfields 更为恰当，它返回指定 哈希键 所有的 field，例如：

127.0.0.1:6379> hkeys user:1
1) "name"
2) "age"
3) "city"
127.0.0.1:6379>

---

获取所有value：hvals key

下面操作获取 user：1 的全部 value：

127.0.0.1:6379> hvals user:1
1) "tom"
2) "12"
3) "shanghai"
127.0.0.1:6379>

---

获取所有的field-value：hgetall key

下面操作获取 user:1 所有的 field-value：

127.0.0.1:6379> hgetall user:1
1) "name"
2) "tom"
3) "age"
4) "12"
5) "city"
6) "shanghai"
127.0.0.1:6379>

在使用 hgetall 时，如果 哈希元素 个数比较多，会存在 阻塞 Redis 的可能。如果开发人员只需要获取 部分 field，可以使用 hmget，如果一定要获取 全部 field-value，可以使用 hscan 命令，该命令会 渐进式遍历 哈希类型。

---

不常用命令

键值自增：hincrby key field hincrbyfloat key field

hincrby 和 hincrbyfloat，就像 incrby 和 incrbyfloat 命令一样，但是它们的 作用域 是 field。

---

计算value的字符串长度：hstrlen key field

例如 hget user:1 name 的 value 是 tom，那么 hstrlen 的返回结果是 3。

127.0.0.1:6379> hstrlen user:1 name
(integer) 3

下面是 哈希类型命令 的 时间复杂度，开发人员可以参考此表选择适合的命令。

---

内部编码

哈希类型 的 内部编码 有两种：

ziplist（压缩列表）

当 哈希类型 元素个数 小于 hash-max-ziplist-entries 配置（默认 512 个）、同时 所有值 都 小于 hash-max-ziplist-value 配置（默认 64 字节）时，Redis 会使用 ziplist 作为 哈希 的 内部实现，ziplist 使用更加 紧凑的结构 实现多个元素的 连续存储，所以在 节省内存 方面比 hashtable 更加优秀。

---

hashtable（哈希表）

当 哈希类型 无法满足 ziplist 的条件时，Redis 会使用 hashtable 作为 哈希 的 内部实现，因为此时 ziplist 的 读写效率 会下降，而 hashtable 的读写 时间复杂度 为 O（1）。

下面的示例演示了 哈希类型 的 内部编码，以及相应的变化。

当 field 个数 比较少，且没有大的 value 时，内部编码 为 ziplist：

127.0.0.1:6379> hmset hashkey f1 v1 f2 v2
OK
127.0.0.1:6379> object encoding hashkey
"ziplist"

当有 value 大于 64 字节时，内部编码 会由 ziplist 变为 hashtable：

127.0.0.1:6379> hset hashkey f3 "one string is bigger than 64 byte...忽略..."
OK
127.0.0.1:6379> object encoding hashkey
"hashtable"

当 field 个数 超过 512，内部编码 也会由 ziplist 变为 hashtable：

127.0.0.1:6379> hmset hashkey f1 v1 f2 v2 f3 v3 ... f513 v513
OK
127.0.0.1:6379> object encoding hashkey
"hashtable"

---

适用场景

如图所示，为 关系型数据表 的两条 用户信息，用户的属性作为表的列，每条用户信息作为行。

使用 Redis 哈希结构 存储 用户信息 的示意图如下：

相比于使用 字符串序列化 缓存 用户信息，哈希类型 变得更加 直观，并且在 更新操作 上会 更加便捷。可以将每个用户的 id 定义为 键后缀，多对 field-value 对应每个用户的 属性，类似如下伪代码：

public UserInfo getUserInfo(long id) {
    // 用户id作为key后缀
    String userRedisKey = "user:info:" + id;
    // 使用hgetall获取所有用户信息映射关系
    Object userInfoMap = redis.hgetAll(userRedisKey);
    UserInfo userInfo;
    if (userInfoMap != null) {
        // 将映射关系转换为UserInfo
        userInfo = transferMapToUserInfo(userInfoMap);
    } else {
        // 从MySQL中获取用户信息
        userInfo = mysql.get(id);
        // 将userInfo变为映射关系使用hmset保存到Redis中
        redis.hmset(userRedisKey, transferUserInfoToMap(userInfo));
        // 添加过期时间
        redis.expire(userRedisKey, 3600);
    }
    return userInfo;
}

---

哈希结构与关系型表

需要注意的是 哈希类型 和 关系型数据库 有两点不同之处：

哈希类型 是 稀疏的，而 关系型数据库 是 完全结构化的，例如 哈希类型 每个 键 可以有不同的 field，而 关系型数据库 一旦添加新的 列，所有行 都要为其 设置值（即使为 NULL），如图所示：

关系型数据库 可以做复杂的 关系查询，而使用 Redis 去模拟关系型复杂查询 开发困难，维护成本高。

---

几种缓存方式

到目前为止，我们已经能够用 三种方法 缓存 用户信息，下面给出三种方案的 实现方法 和 优缺点分析。

原生字符串类型

给用户信息的每一个属性分配 一个键。

set user:1:name tom
set user:1:age 23
set user:1:city beijing

• 优点：简单直观，每个属性都支持 更新操作。
• 缺点：占用 过多的键，内存占用量 较大，同时用户信息 内聚性比较差，所以此种方案一般不会在生产环境使用。

---

序列化字符串类型

将用户信息 序列化 后用 一个键 保存。

set user:1 serialize(userInfo)

• 优点：简化编程，如果合理的使用 序列化 可以 提高内存利用率。
• 缺点：序列化 和 反序列化 有一定的开销，同时每次 更新属性 都需要把 全部数据 取出进行 反序列化，更新后 再 序列化 到 Redis 中。

---

哈希类型

每个用户属性使用 一对 field-value，但是只用 一个键 保存。

hmset user:1 name tom age 23 city beijing

• 优点：简单直观，如果使用合理可以 减少内存空间 的使用。
• 缺点：要控制和减少 哈希 在 ziplist 和 hashtable 两种 内部编码 的 转换，hashtable 会消耗 更多内存。

---

本文参考

《Redis 开发与运维》

---

本文小结

本文介绍了 Redis 中的 哈希结构 的 一些 基本命令、内部编码 和 适用场景。最后对比了 关系型表 和 哈希结构 的区别，以及几种 存储方式 的优缺点。

1. 概念 引入

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

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

当向该结构中

• 插入元素 ：根据待插入元素的关键码，以此函数计算出该元素的存储位置并按此位置进行存放
• 搜索元素：对元素的关键码进行同样的计算，把求得的函数值当做元素的存储位置，在结构中按此位置取元素比较，若关键码相等，则搜索成功

该方式即为哈希(散列)方法，哈希方法中使用的转换函数称为哈希(散列)函数，构造出来的结构称为哈希表(HashTable)(或者称散列表)

例如：数据集合{1，7，6，4，5，9}；
哈希函数设置为：hash(key) = key % capacity; capacity为存储元素底层空间总的大小。

用该方法进行搜索不必进行多次关键码的比较，因此搜索的速度比较快

2. 冲突

2.1 概念

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

2.2 避免

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

2.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种不同的符号在各位上出现的频率不一定相同，可能在某些位上分布比较均匀，每种符号出现的机会均等，在某些位上分布不均匀只有某几种符号经常出现。可根据散列表的大小，选择其中各种符号分布均匀的若干位作为散列地址。

数字分析法通常适合处理关键字位数比较大的情况，如果事先知道关键字的分布且关键字的若干位分布较均匀的情况

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

2.4 冲突-避免-负载因子调节（重点）

所以当冲突率达到一个无法忍受的程度时，我们需要通过降低负载因子来变相的降低冲突率。
已知哈希表中已有的关键字个数是不可变的，那我们能调整的就只有哈希表中的数组的大小。

2.5 冲突-解决

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

2.5.1 闭散列

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

寻找下一个空位置的方法 ：

1. 线性探测
   比如上面的场景，现在需要插入元素44，先通过哈希函数计算哈希地址，下标为4，因此44理论上应该插在该位置，但是该位置已经放了值为4的元素，即发生哈希冲突。

线性探测：从发生冲突的位置开始，依次向后探测，直到寻找到下一个空位置为止。

• 插入

1. 通过哈希函数获取待插入元素在哈希表中的位置
2. 如果该位置中没有元素则直接插入新元素，如果该位置中有元素发生哈希冲突，使用线性探测找到下一个空位置，插入新元素
   

• 采用闭散列处理哈希冲突时，不能随便物理删除哈希表中已有的元素，若直接删除元素会影响其他元素的搜索。比如删除元素4，如果直接删除掉，44查找起来可能会受影响。因此线性探测采用标记的伪删除法来删除一个元素。

2. 二次探测(采用特定公式避免数据紧挨在一起放置)
   线性探测的缺陷是产生冲突的数据堆积在一块，这与其找下一个空位置有关系，因为找空位置的方式就是挨着往后逐个去找，因此二次探测为了避免该问题，找下一个空位置的方法为：Hi = ( H0+i^2 )% m, 或者：Hi
   = (H0 -i^2 )% m。其中：i = 1,2,3…， H0是通过散列函数Hash(x)对元素的关键码 key 进行计算得到的位置，m是表的大小。

研究表明：当表的长度为质数且表装载因子a不超过0.5时，新的表项一定能够插入，而且任何一个位置都不会被探查两次。因此只要表中有一半的空位置，就不会存在表满的问题。在搜索时可以不考虑表装满的情况，但在插入时必须确保表的装载因子a不超过0.5，如果超出必须考虑增容。

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

2.6 冲突-解决-开散列/哈希桶 （数组+链表）

开散列法又叫链地址法(开链法)，首先对关键码集合用散列函数计算散列地址，具有相同地址的关键码归于同一子集合，每一个子集合称为一个桶，各个桶中的元素通过一个单链表链接起来，各链表的头结点存储在哈希表中。

2.7 冲突严重时的解决办法

哈希桶其实可以看作将大集合的搜索问题转化为小集合的搜索问题了，那如果冲突严重，就意味着小集合的搜索性能其实也时不佳的，这个时候我们就可以将这个所谓的小集合搜索问题继续进行转化，例如：

1. 每个桶的背后是另一个哈希表
2. 每个桶的背后是一棵搜索树

3. key-val值假设都为int型的代码实现

public 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 double DEFAULT_LOAD_FACTOR=0.75;

    public HashBuck(){
        this.array=new Node[10];
    }

    /**
     * put函数
     * @param key
     * @param val
     */
    public void put(int key,int val){
        //1.找到key所在的位置
        int index=key%this.array.length;
        //2.遍历这个下标的链表，看是不是有相同的key 有 更新val值
        Node cur=array[index];
        while (cur!=null){
            if (cur.key==key){
                cur.val=val;//更新val的值
                return;
            }
            cur=cur.next;
        }
        //3.没有这个key的话，采用头插法插入
        Node node=new Node(key,val);
        node.next=array[index];
        array[index]=node;
        this.usedSize++;
        //4.插入元素成功后，检查当前散列表的负载因子
        if (loadFactor()>=DEFAULT_LOAD_FACTOR){

        }

    }

    private void resize(){
        Node[] newArray=new Node[array.length*2];
        //扩容之后所有的元素需要重新哈希
        for (int i = 0; i < array.length; i++) {
            Node cur=array[i];
            while (cur!=null){
                int index=cur.key%newArray.length;//获取新的下标
                //重新哈希：就是把cur这个节点，以头插/尾插的形式 插入到新的数组对应下标的链表当中
                Node curNext=cur.next;
                cur.next=newArray[index];//先绑定后面
                newArray[index]=cur;//再绑定前面
                cur=curNext;
            }
        }
        array=newArray;
    }

    private double loadFactor(){
        return 1.0*usedSize/array.length;
    }

    /**
     * get函数
     * 根据key获取val的值
     * @param key
     * @return
     */
    public int get(int key){
        //1.找到key所在的位置
        int index=key%this.array.length;
        //2.获取val
        Node cur=array[index];
        while (cur!=null){
            if (cur.key==key){
                return cur.val;
            }
            cur=cur.next;
        }
        return -1;
    }
}

扩容前：

扩容后：（重新哈希后再放置元素 ）

4. 性能分析

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

5.与Java类集的关系（代码举列）

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

代码举列如下：

import java.util.HashMap;
import java.util.Objects;

/**
 * Created with IntelliJ IDEA.
 * User: 12629
 * Date: 2022/2/22
 * Time: 21:32
 * Description:
 */
class Person { //自定义person类
    public String ID;

    public Person(String ID) {
        this.ID = ID;
    }


    @Override // 重写equals方法
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Person person = (Person) o;
        return Objects.equals(ID, person.ID);
    }

    @Override //重写hashcode方法
    public int hashCode() {
        return Objects.hash(ID);
    }

    @Override
    public String toString() {
        return "Person{" +
                "ID='" + ID + '\'' +
                '}';
    }
}
public class HashBuck2<K,V> {

    static class Node<K,V> {
        public K key;
        public V val;
        public Node<K,V> next;

        public Node(K key,V val) {
            this.val = val;
            this.key = key;
        }
    }

    public Node<K,V>[] array = (Node<K,V>[])new Node[10];
    public int usedSize;

    public void put(K key,V val) {
        int hash = key.hashCode();//转换为一个整数 
        int index = hash % array.length;
        Node<K,V> cur = array[index];
        while (cur != null) {
            if(cur.key.equals(key)) {
                cur.val = val;//更新val值
                return;
            }
            cur = cur.next;
        }
        Node<K,V> node = new Node<>(key, val);
        node.next = array[index];
        array[index] = node;
        this.usedSize++;
    }

    public V get(K key) {
        int hash = key.hashCode();//转换为一个整数 
        int index = hash % array.length;
        Node<K,V> cur = array[index];
        while (cur != null) {
            if(cur.key.equals(key)) {
                //更新val值
                return cur.val;
            }
            cur = cur.next;
        }
        return null;
    }

    public static void main(String[] args) {
        
        //我们认为 身份证ID一样的两个人是同一个人 
        //通过对hashcode和equals方法的重写 可以实现这一逻辑
        //重写hashcode之后，字符串类型的ID相同的话生成的整数就是相同的
        //实现了ID一样的两个人是同一人这一逻辑
        
        Person person1 = new Person("123");
        Person person2 = new Person("123");

        HashBuck2<Person,String> hashBuck2 = new HashBuck2<>();
        hashBuck2.put(person1,"love");

        System.out.println(hashBuck2.get(person2));
    }

    
}

因为person1和person2是同一个人
所以get person2的val其实就是放入person1的love

• over

1.unordered_map/unordered_set

1. unordered_map是存储<key, value>键值对的关联式容器，其允许通过keys快速的索引到与其对应的value。
2. 在unordered_map中，键值通常用于惟一地标识元素，而映射值是一个对象，其内容与此键关联。键和映射值的类型可能不同。
3. 在内部,unordered_map没有对<kye, value>按照任何特定的顺序排序, 为了能在常数范围内找到key所对应的value，unordered_map将相同哈希值的键值对放在相同的桶中。
4. unordered_map容器通过key访问单个元素要比map快，但它通常在遍历元素子集的范围迭代方面效率较低。

unordered_map的元素访问：

2. 底层结构

unordered系列的关联式容器之所以效率比较高，是因为其底层使用了哈希结构。

2.1哈希概念

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

当向该结构中插入元素：根据待插入元素的关键码，以 函数(hashFunc) 计算出该元素的存储位置并按此位置进行存放。

搜索元素： 对元素的关键码进行同样的计算，把求得的函数值当做元素的存储位置，在结构中按此位置取元素比较，若关键码相等，则搜索成功。

该方式即为哈希(散列)方法，哈希方法中使用的转换函数称为哈希(散列)函数，构造出来的结构称为哈希表(Hash Table)(或者称散列表)。

2.3常见哈希函数

1.直接定址法–(常用)：

• 取关键字的某个线性函数为散列地址：Hash（Key）= A*Key + B ；
  优点：简单、高效 ；
  缺点：需要事先知道关键字的分布情况 ；

使用场景：适合查找比较小且连续的情况，比如:第一次出现的字符：构建一个数组hash[ch-‘a’] 来映射位置；
不适用场景：数据分散，数据元素不连续，很容易造成空间浪费，比如 ：一组数据最小的为1，最大的到了99999999；

2.除留余数法(常用)

设散列表中允许的地址数为m，取一个不大于m，但最接近或者等于m的质数i作为除数，按照哈希函数：Hash(key) = key% i(p<=m), 将关键码转换成哈希地址；

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

2.4 哈希冲突

• 不同关键字通过相同哈希哈数计算出相同的哈希地址，该种现象称为哈希冲突或哈希碰撞。

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

3.闭散列（开放定址法）

当发生哈希冲突时，如果哈希表未被装满，说明在哈希表中必然还有空位置，那么可以把key存放到冲突位置中的“下一个” 空位置中去。寻找下一个空位置的方法有线性探测法和二次探测法

3.1线性探测

• 从发生冲突的位置开始，依次向后探测，直到寻找到下一个空位置为止；

• 插入：通过哈希函数获取待插入元素在哈希表中的位置
  

删除：

采用闭散列处理哈希冲突时，不能随便物理删除哈希表中已有的元素，若直接删除元素会影响其他元素的搜索。比如删除元素4，如果直接删除掉，44查找起来可能会受影响。因此线性探测采用标记的伪删除法来删除一个元素；

线性探测的缺点：空间踩踏

3.2闭散列扩容-载荷因子

3.3二次探测

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

4.开散列

开散列法又叫链地址法(开链法)，首先对关键码集合用散列函数计算散列地址，具有相同地址的关键码归于同一子集合，每一个子集合称为一个桶，各个桶中的元素通过一个单链表链接起来，各链表的头结点存储在哈希表中。

4.1开散列增容

开散列最好的情况是：每个哈希桶中刚好挂一个节点，再继续插入元素时，每一次都会发生哈希冲突，因此，在元素个数刚好等于桶的个数时，可以给哈希表增容；

• 载荷因子为1进行扩容；

优点：
- 不同位置冲突时，不再互相干扰，载荷因子一般控制在1

缺点：
- 迭代器遍历输出的时候，不是有序输出的；

如果所有的数据都冲突到一个桶下面了，怎么办？

1.桶下面挂红黑树：极限也是logN的时间复杂度，但是也只是这一会而已，当增容的时候，这种现象就会缓解；
2.多阶哈希