CS_learn/hello-algo
1
0
Fork 0
mirror of https://github.com/krahets/hello-algo.git synced 2026-04-26 19:41:26 +08:00
Code Issues Packages Projects Releases Wiki Activity

build

Browse Source
This commit is contained in:
krahets
2023-07-24 03:03:29 +08:00
parent d0f117eccc
commit debd909387
16 changed files with 262 additions and 227 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
chapter_hashing/hash_algorithm.md
View File

@@ -4,31 +4,33 @@ comments: true
# 6.3.   哈希算法
在上两节中，我们了解了哈希表的工作原理，以及哈希冲突的处理方法。然而，无论是开放寻址还是链地址法，**它们只能保证哈希表可以在发生冲突时正常工作，但无法减少哈希冲突的发生**。
在上两节中，我们了解了哈希表的工作原理和哈希冲突的处理方法。然而无论是开放寻址还是链地址法，**它们只能保证哈希表可以在发生冲突时正常工作，但无法减少哈希冲突的发生**。
如果哈希冲突过于频繁，哈希表的性能则会急剧劣化。例如对于链地址哈希表，理想情况下键值对平均分布在各个桶中，达到最好的查询效率；最差情况下全部键值都被存储到同一个桶中，时间复杂度退化至 $O(n)$ 。
如果哈希冲突过于频繁，哈希表的性能则会急剧劣化。对于链地址哈希表，理想情况下键值对平均分布在各个桶中，达到最佳查询效率；最差情况下所有键值对都被存储到同一个桶中，时间复杂度退化至 $O(n)$ 。
![哈希冲突的最佳与最差情况](hash_algorithm.assets/hash_collision_best_worst_condition.png)
<p align="center"> Fig. 哈希冲突的最佳与最差情况 </p>
**键值对的分布情况是由哈希函数决定的**。回忆哈希函数的计算步骤，先计算哈希值，再对数组长度取模：
**键值对的分布情况由哈希函数决定**。回忆哈希函数的计算步骤，先计算哈希值，再对数组长度取模：
```shell
index = hash(key) % capacity
```
观察以上公式，当哈希表容量 `capacity` 固定时，**哈希算法 `hash()` 决定了输出值**，进而决定了键值对在哈希表中的分布。因此，为了减小哈希冲突的发生概率，我们需要将注意力集中在哈希算法 `hash()` 的设计上。
观察以上公式，当哈希表容量 `capacity` 固定时，**哈希算法 `hash()` 决定了输出值**，进而决定了键值对在哈希表中的分布情况。
这意味着，为了减小哈希冲突的发生概率，我们应当将注意力集中在哈希算法 `hash()` 的设计上。
## 6.3.1. &nbsp; 哈希算法的目标
为了在编程语言中实现“既快又稳”的哈希表数据结构，哈希算法应包含以下特点：
为了实现“既快又稳”的哈希表数据结构，哈希算法应包含以下特点：
- **确定性**：对于相同的输入，哈希算法应始终产生相同的输出。这样才能确保哈希表是可靠的。
- **效率高**：计算哈希值的过程应该足够快。计算开销越小，哈希表的实用性越高。
- **均匀分布**：哈希算法应使得键值对平均分布在哈希表中。分布越平均，哈希冲突的概率就越低。
实际上，哈希算法除了可以用于实现哈希表，还广泛应用于其他领域中，包括：
实际上，哈希算法除了可以用于实现哈希表，还广泛应用于其他领域中。举两个例子：
- **密码存储**：为了保护用户密码的安全，系统通常不会直接存储用户的明文密码，而是存储密码的哈希值。当用户输入密码时，系统会对输入的密码计算哈希值，然后与存储的哈希值进行比较。如果两者匹配，那么密码就被视为正确。
- **数据完整性检查**：数据发送方可以计算数据的哈希值并将其一同发送；接收方可以重新计算接收到的数据的哈希值，并与接收到的哈希值进行比较。如果两者匹配，那么数据就被视为完整的。
@@ -38,11 +40,11 @@ index = hash(key) % capacity
- **抗碰撞性**：应当极其困难找到两个不同的输入，使得它们的哈希值相同。
- **雪崩效应**：输入的微小变化应当导致输出的显著且不可预测的变化。
注意，**“均匀分布”与“抗碰撞性”是两个独立的概念**，满足均匀分布不一定满足抗碰撞性。例如，在随机输入 `key` 下，哈希函数 `key % 100` 可以产生均匀分布的输出。然而，该哈希算法过于简单，所有后两位相等的 `key` 的输出都相同，因此我们可以很容易地从哈希值反推出可用的 `key` ，从而破解密码。
请注意，**“均匀分布”与“抗碰撞性”是两个独立的概念**，满足均匀分布不一定满足抗碰撞性。例如，在随机输入 `key` 下，哈希函数 `key % 100` 可以产生均匀分布的输出。然而该哈希算法过于简单，所有后两位相等的 `key` 的输出都相同，因此我们可以很容易地从哈希值反推出可用的 `key` ，从而破解密码。
## 6.3.2. &nbsp; 哈希算法的设计
哈希算法的设计是一个复杂且需要考虑许多因素的问题。然而，对于一些简单场景，我们也能设计一些简单的哈希算法，以字符串哈希为例：
哈希算法的设计是一个复杂且需要考虑许多因素的问题。然而对于简单场景，我们也能设计一些简单的哈希算法。以字符串哈希为例：
- **加法哈希**：对输入的每个字符的 ASCII 码进行相加，将得到的总和作为哈希值。
- **乘法哈希**：利用了乘法的不相关性，每轮乘以一个常数，将各个字符的 ASCII 码累积到哈希值中。
@@ -382,7 +384,7 @@ index = hash(key) % capacity
[class]{}-[func]{rot_hash}
```
观察发现，每种哈希算法的最后一步都是对大质数 $1000000007$ 取模，以确保哈希值在合适的范围内。值得思考的是，为什么要强调对质数取模，对合数取模的弊端是什么？这是一个有趣的问题。
观察发现，每种哈希算法的最后一步都是对大质数 $1000000007$ 取模，以确保哈希值在合适的范围内。值得思考的是，为什么要强调对质数取模，或者说对合数取模的弊端是什么？这是一个有趣的问题。
先抛出结论：**当我们使用大质数作为模数时，可以最大化地保证哈希值的均匀分布**。因为质数不会与其他数字存在公约数，可以减少因取模操作而产生的周期性模式，从而避免哈希冲突。
@@ -406,17 +408,21 @@ $$
\end{aligned}
$$
值得强调的是，如果能够保证 `key` 是随机均匀分布的，那么选择质数或者合数作为模数都是可以的，它们都能输出均匀分布的哈希值。而当 `key` 的分布存在某种周期性时，对合数取模更容易出现聚集现象。
值得说明的是，如果能够保证 `key` 是随机均匀分布的，那么选择质数或者合数作为模数都是可以的，它们都能输出均匀分布的哈希值。而当 `key` 的分布存在某种周期性时，对合数取模更容易出现聚集现象。
总而言之，我们通常选取质数作为模数，并且这个质数最好大一些，以提升哈希算法的稳健性。
总而言之，我们通常选取质数作为模数，并且这个质数最好足够大，以尽可能消除周期性模式，提升哈希算法的稳健性。
## 6.3.3. &nbsp; 常见哈希算法
不难发现，以上介绍的简单哈希算法都比较“脆弱”，远远没有达到哈希算法的设计目标。例如，由于加法和异或满足交换律，因此加法哈希和异或哈希无法区分内容相同但顺序不同的字符串，这可能会加剧哈希冲突，并引起一些安全问题。
在实际中，我们通常会用一些标准哈希算法，例如 MD5, SHA-1, SHA-2, SHA3 等。它们可以将任意长度的输入数据映射到恒定长度的哈希值。近一个世纪以来，哈希算法处在不断升级与优化的过程中。一部分研究人员努力提升哈希算法的性能，另一部分研究人员和黑客则致力于寻找哈希算法的安全性问题。
在实际中，我们通常会用一些标准哈希算法，例如 MD5 , SHA-1 , SHA-2 , SHA3 等。它们可以将任意长度的输入数据映射到恒定长度的哈希值。
直至目前，MD5 和 SHA-1 已多次被成功攻击，因此它们被各类安全应用弃用。SHA-2 系列中的 SHA-256 是最安全的哈希算法之一，仍未出现成功的攻击案例，因此常被用在各类安全应用与协议中。SHA-3 相较 SHA-2 的实现开销更低、计算效率更高，但目前使用覆盖度不如 SHA-2 系列。
近一个世纪以来，哈希算法处在不断升级与优化的过程中。一部分研究人员努力提升哈希算法的性能，另一部分研究人员和黑客则致力于寻找哈希算法的安全性问题。直至目前：
- MD5 和 SHA-1 已多次被成功攻击，因此它们被各类安全应用弃用。
- SHA-2 系列中的 SHA-256 是最安全的哈希算法之一，仍未出现成功的攻击案例，因此常被用在各类安全应用与协议中。
- SHA-3 相较 SHA-2 的实现开销更低、计算效率更高，但目前使用覆盖度不如 SHA-2 系列。
| | MD5 | SHA-1 | SHA-2 | SHA-3 |
| -------- | ------------------------------ | ---------------- | ---------------------------- | -------------------- |
@@ -632,10 +638,8 @@ $$
// 节点对象 Instance of 'ListNode' 的哈希值为 1033450432
```
在大多数编程语言中，**只有不可变对象才可作为哈希表的 `key`** 。假如我们将列表（动态数组）作为 `key` ，当列表的内容发生变化时，它的哈希值也随之改变，我们就无法在哈希表中查询到原先的 `value` 了。
在许多编程语言中，**只有不可变对象才可作为哈希表的 `key`** 。假如我们将列表（动态数组）作为 `key` ，当列表的内容发生变化时，它的哈希值也随之改变，我们就无法在哈希表中查询到原先的 `value` 了。
虽然自定义对象（例如链表节点）的成员变量是可变的，但它是可哈希的，这是因为对象的哈希值默认基于内存地址生成。即使对象的内容发生了变化，但它的内存地址不变，哈希值仍然是不变的。
虽然自定义对象（比如链表节点）的成员变量是可变的，但它是可哈希的。**这是因为对象的哈希值通常是基于内存地址生成的**，即使对象的内容发生了变化，但它的内存地址不变，哈希值仍然是不变的。
!!! tip "向哈希函数加盐"
Python 解释器在每次启动时，都会为字符串哈希函数加入一个随机的盐（Salt）值。因此在不同的 Python 运行实例中，同一字符串的哈希值通常是不同的。此做法可以有效防止 HashDoS 攻击，提升哈希算法的安全性。
细心的你可能发现在不同控制台中运行程序时，输出的哈希值是不同的。**这是因为 Python 解释器在每次启动时，都会为字符串哈希函数加入一个随机的盐（Salt）值**。这种做法可以有效防止 HashDoS 攻击，提升哈希算法的安全性。

35
chapter_hashing/hash_collision.md
View File

@@ -4,12 +4,12 @@ comments: true
# 6.2. &nbsp; 哈希冲突
上节提到，**通常情况下哈希函数的输入空间远大于输出空间**，因此哈希冲突是不可避免的。例如，输入空间为全体整数，输出空间为数组容量大小，则必然有多个整数映射至同一数组索引。
上节提到，**通常情况下哈希函数的输入空间远大于输出空间**，因此理论上哈希冲突是不可避免的。比如，输入空间为全体整数，输出空间为数组容量大小，则必然有多个整数映射至同一数组索引。
哈希冲突会导致查询结果错误，严重影响哈希表的可用性。为解决该问题，我们可以每当遇到哈希冲突时就进行哈希表扩容，直至冲突消失为止。此方法简单粗暴且有效，但效率太低，因为哈希表扩容需要进行大量的数据搬运与哈希值计算。为了提升效率，我们换一种思路：
哈希冲突会导致查询结果错误，严重影响哈希表的可用性。为解决该问题，我们可以每当遇到哈希冲突时就进行哈希表扩容，直至冲突消失为止。此方法简单粗暴且有效，但效率太低，因为哈希表扩容需要进行大量的数据搬运与哈希值计算。为了提升效率，我们切换一下思路：
1. 改良哈希表数据结构，**使得哈希表可以在存在哈希冲突时正常工作**。
2. 仅在必要时，即当哈希冲突比较严重时，执行扩容操作。
2. 仅在必要时，即当哈希冲突比较严重时，才执行扩容操作。
哈希表的结构改良方法主要包括链式地址和开放寻址。
@@ -29,12 +29,12 @@ comments: true
该方法存在一些局限性，包括：
- **占用空间增大**，由于链表或二叉树包含节点指针，相比数组更加耗费内存空间；
- **查询效率降低**，因为需要线性遍历链表来查找对应元素；
- **占用空间增大**，链表包含节点指针，它相比数组更加耗费内存空间。
- **查询效率降低**，因为需要线性遍历链表来查找对应元素。
以下给出了链式地址哈希表的简单实现，需要注意：
- 为了使得代码尽量简短，我们使用列表（动态数组）代替链表。换句话说，哈希表（数组）包含多个桶，每个桶都是一个列表。
- 为了使得代码尽量简短，我们使用列表（动态数组）代替链表。在这种设定下，哈希表（数组）包含多个桶，每个桶都是一个列表。
- 以下代码实现了哈希表扩容方法。具体来看，当负载因子超过 $0.75$ 时，我们将哈希表扩容至 $2$ 倍。
=== "Java"
@@ -809,18 +809,18 @@ comments: true
!!! tip
为了提高效率，**我们可以将链表转换为「AVL 树」或「红黑树」**，从而将查询操作的时间复杂度优化至 $O(\log n)$ 。
当链表很长时，查询效率 $O(n)$ 很差，**此时可以将链表转换为「AVL 树」或「红黑树」**，从而将查询操作的时间复杂度优化至 $O(\log n)$ 。
## 6.2.2. &nbsp; 开放寻址
「开放寻址 Open Addressing」不引入额外的数据结构，而是通过“多次探测”来处理哈希冲突，探测方式主要包括线性探测、平方探测、多次哈希。
「开放寻址 Open Addressing」不引入额外的数据结构，而是通过“多次探测”来处理哈希冲突，探测方式主要包括线性探测、平方探测、多次哈希等。
### 线性探测
线性探测采用固定步长的线性查找来进行探测，对应的哈希表操作方法为：
- **插入元素**：通过哈希函数计算数组索引，若发现桶内已有元素，则从冲突位置向后线性遍历（步长通常为 $1$ ），直至找到空位，将元素插入其中。
- **查找元素**：若发现哈希冲突，则使用相同步长向后线性遍历，直到找到对应元素，返回 `value` 即可；或者若遇到空位，说明目标键值对不在哈希表中，返回 $\text{None}$ 。
- **查找元素**：若发现哈希冲突，则使用相同步长向后线性遍历，直到找到对应元素，返回 `value` 即可；如果遇到空位，说明目标键值对不在哈希表中，返回 $\text{None}$ 。
![线性探测](hash_collision.assets/hash_table_linear_probing.png)
@@ -828,13 +828,12 @@ comments: true
然而，线性探测存在以下缺陷：
- **不能直接删除元素**。删除元素会在数组内产生一个空位，查找其他元素时，该空位可能导致程序误判元素不存在。因此，需要借助一个标志位来标记已删除元素。
- **容易产生聚集**。数组内连续被占用位置越长，这些连续位置发生哈希冲突的可能性越大，进一步促使这一位置的“聚堆生长”，最终导致增删查改操作效率降低。
- **不能直接删除元素**。删除元素会在数组内产生一个空位，当查找该空位之后的元素时，该空位可能导致程序误判元素不存在。为此，通常需要借助一个标志位来标记已删除元素。
- **容易产生聚集**。数组内连续被占用位置越长，这些连续位置发生哈希冲突的可能性越大，进一步促使这一位置的聚堆生长，形成恶性循环，最终导致增删查改操作效率劣化。
如以下代码所示，为开放寻址（线性探测）哈希表的简单实现，重点包括：
以下代码实现了一个简单的开放寻址（线性探测）哈希表。值得注意两点：
- 我们使用一个固定的键值对实例 `removed` 来标记已删除元素。也就是说，当一个桶为 $\text{None}$ 或 `removed` 时，这个桶都是空的，可用于放置键值对。
- 被标记为已删除的空间是可以再次被使用的。当插入元素时，若通过哈希函数找到了被标记为已删除的索引，则可将该元素放置到该索引。
- 我们使用一个固定的键值对实例 `removed` 来标记已删除元素。也就是说，当一个桶内的元素为 $\text{None}$ 或 `removed` 时，说明这个桶是空的，可用于放置键值对。
- 在线性探测时，我们从当前索引 `index` 向后遍历；而当越过数组尾部时，需要回到头部继续遍历。
=== "Java"
@@ -1719,10 +1718,10 @@ comments: true
与线性探测相比，多次哈希方法不易产生聚集，但多个哈希函数会增加额外的计算量。
!!! note "编程语言的选择"
## 6.2.3. &nbsp; 编程语言的选择
Java 采用链式地址。自 JDK 1.8 以来，当 HashMap 内数组长度达到 64 且链表长度达到 8 时，链表会被转换为红黑树以提升查找性能。
Java 采用链式地址。自 JDK 1.8 以来，当 HashMap 内数组长度达到 64 且链表长度达到 8 时，链表会被转换为红黑树以提升查找性能。
Python 采用开放寻址。字典 dict 使用伪随机数进行探测。
Python 采用开放寻址。字典 dict 使用伪随机数进行探测。
Golang 采用链式地址。Go 规定每个桶最多存储 8 个键值对，超出容量则连接一个溢出桶；当溢出桶过多时，会执行一次特殊的等量扩容操作，以确保性能。
Golang 采用链式地址。Go 规定每个桶最多存储 8 个键值对，超出容量则连接一个溢出桶；当溢出桶过多时，会执行一次特殊的等量扩容操作，以确保性能。

17
chapter_hashing/hash_map.md
View File

@@ -15,7 +15,7 @@ comments: true
除哈希表外，我们还可以使用数组或链表实现查询功能。若将学生数据看作数组（链表）元素，则有：
- **添加元素**：仅需将元素添加至数组（链表）的尾部即可，使用 $O(1)$ 时间；
- **查询元素**：由于数组（链表）是乱序的，因此需要遍历数组（链表）中的所有元素，使用 $O(n)$ 时间；
- **查询元素**：由于数组（链表）是乱序的，因此需要遍历其中的所有元素，使用 $O(n)$ 时间；
- **删除元素**：需要先查询到元素，再从数组中删除，使用 $O(n)$ 时间；
<div class="center-table" markdown>
@@ -28,7 +28,7 @@ comments: true
</div>
观察发现，**在哈希表中进行增删查改的时间复杂度都是 $O(1)$** ，非常高效。因此，哈希表常用于对查找效率要求较高的场景。
观察发现，**在哈希表中进行增删查改的时间复杂度都是 $O(1)$** ，非常高效。
## 6.1.1. &nbsp; 哈希表常用操作
@@ -440,7 +440,10 @@ comments: true
那么，如何基于 `key` 来定位对应的桶呢？这是通过「哈希函数 Hash Function」实现的。哈希函数的作用是将一个较大的输入空间映射到一个较小的输出空间。在哈希表中，输入空间是所有 `key` ，输出空间是所有桶（数组索引）。换句话说，输入一个 `key` ，**我们可以通过哈希函数得到该 `key` 对应的键值对在数组中的存储位置**。
输入一个 `key` ，哈希函数的计算过程分为两步：首先，通过哈希算法 `hash()` 计算得到哈希值；接下来，将哈希值对桶数量（数组长度）`capacity` 取模，从而获取该 `key` 对应的数组索引 `index` 。
输入一个 `key` ，哈希函数的计算过程分为两步：
1. 通过某种哈希算法 `hash()` 计算得到哈希值；
2. 将哈希值对桶数量（数组长度）`capacity` 取模，从而获取该 `key` 对应的数组索引 `index` ；
```shell
index = hash(key) % capacity
@@ -454,7 +457,7 @@ index = hash(key) % capacity
<p align="center"> Fig. 哈希函数工作原理 </p>
以下代码给出了一个简单哈希表实现。其中，我们将 `key` 和 `value` 封装成一个类 `Pair` ，以表示键值对。
以下代码实现了一个简单哈希表。其中，我们将 `key` 和 `value` 封装成一个类 `Pair` ，以表示键值对。
=== "Java"
@@ -1405,7 +1408,7 @@ index = hash(key) % capacity
## 6.1.3. &nbsp; 哈希冲突与扩容
本质上看，哈希函数的作用是将输入空间（`key` 范围）映射到输出空间（数组索引范围），而输入空间往往远大于输出空间。因此，**理论上一定存在“多个输入对应相同输出”的情况**。
本质上看，哈希函数的作用是将所有 `key` 构成的输入空间映射到数组所有索引构成的输出空间，而输入空间往往远大于输出空间。因此，**理论上一定存在“多个输入对应相同输出”的情况**。
对于上述示例中的哈希函数，当输入的 `key` 后两位相同时，哈希函数的输出结果也相同。例如，查询学号为 12836 和 20336 的两个学生时，我们得到：
@@ -1426,6 +1429,6 @@ index = hash(key) % capacity
<p align="center"> Fig. 哈希表扩容 </p>
类似于数组扩容，哈希表扩容需将所有键值对从原哈希表迁移至新哈希表，非常耗时。并且由于哈希表容量 `capacity` 改变，我们需要重新计算所有键值对的存储位置，进一步提高了扩容过程的计算开销。因此，编程语言通常会预留足够大的哈希表容量，防止频繁扩容。
类似于数组扩容，哈希表扩容需将所有键值对从原哈希表迁移至新哈希表，非常耗时。并且由于哈希表容量 `capacity` 改变，我们需要通过哈希函数来重新计算所有键值对的存储位置，这进一步提高了扩容过程的计算开销。为此，编程语言通常会预留足够大的哈希表容量，防止频繁扩容。
在哈希表中，「负载因子 Load Factor」是一个重要概念，其定义为哈希表的元素数量除以桶数量，为了衡量哈希冲突的严重程度，**也常被作为哈希表扩容的触发条件**。例如在 Java 中，当负载因子超过 $0.75$ 时，系统会将哈希表容量扩展为原先的 $2$ 倍。
「负载因子 Load Factor」是哈希表的一个重要概念，其定义为哈希表的元素数量除以桶数量，用于衡量哈希冲突的严重程度，**也常被作为哈希表扩容的触发条件**。例如在 Java 中，当负载因子超过 $0.75$ 时，系统会将哈希表容量扩展为原先的 $2$ 倍。