mirror of
https://github.com/krahets/hello-algo.git
synced 2024-12-27 13:36:28 +08:00
build
This commit is contained in:
parent
3881f13deb
commit
79f6055e8b
5 changed files with 399 additions and 37 deletions
|
@ -155,7 +155,7 @@ comments: true
|
||||||
// 向顶点列表中添加新顶点的值
|
// 向顶点列表中添加新顶点的值
|
||||||
vertices.push_back(val);
|
vertices.push_back(val);
|
||||||
// 在邻接矩阵中添加一行
|
// 在邻接矩阵中添加一行
|
||||||
adjMat.emplace_back(n, 0);
|
adjMat.emplace_back(vector<int>(n, 0));
|
||||||
// 在邻接矩阵中添加一列
|
// 在邻接矩阵中添加一列
|
||||||
for (vector<int> &row : adjMat) {
|
for (vector<int> &row : adjMat) {
|
||||||
row.push_back(0);
|
row.push_back(0);
|
||||||
|
|
355
chapter_hashing/hash_algorithm.md
Normal file
355
chapter_hashing/hash_algorithm.md
Normal file
|
@ -0,0 +1,355 @@
|
||||||
|
---
|
||||||
|
comments: true
|
||||||
|
---
|
||||||
|
|
||||||
|
# 6.3. 哈希算法
|
||||||
|
|
||||||
|
在上两节中,我们了解了哈希表的工作原理,以及哈希冲突的处理方法。然而,无论是开放寻址还是链地址法,**它们只能保证哈希表可以在发生冲突时正常工作,但无法减少哈希冲突的发生**。
|
||||||
|
|
||||||
|
如果哈希冲突过于频繁,哈希表的性能则会急剧劣化。例如对于链地址哈希表,理想情况下键值对平均分布在各个桶中,达到最好的查询效率;最差情况下全部键值都被存储到同一个桶中,时间复杂度退化至 $O(n)$ 。
|
||||||
|
|
||||||
|
![哈希冲突的最佳与最差情况](hash_algorithm.assets/hash_collision_best_worst_condition.png)
|
||||||
|
|
||||||
|
<p align="center"> Fig. 哈希冲突的最佳与最差情况 </p>
|
||||||
|
|
||||||
|
**键值对的分布情况是由哈希函数决定的**。回忆哈希函数的计算步骤,先计算哈希值,再对数组长度取模:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
index = hash(key) % capacity
|
||||||
|
```
|
||||||
|
|
||||||
|
观察以上公式,当哈希表容量 `capacity` 固定时,**哈希算法 `hash()` 决定了输出值**,进而决定了键值对在哈希表中的分布。因此,为了减小哈希冲突的发生概率,我们需要将注意力集中在哈希算法 `hash()` 的设计上。
|
||||||
|
|
||||||
|
## 6.3.1. 哈希算法的目标
|
||||||
|
|
||||||
|
为了在编程语言中实现“既快又稳”的哈希表数据结构,哈希算法应包含以下特点:
|
||||||
|
|
||||||
|
- **确定性**:对于相同的输入,哈希算法应始终产生相同的输出。这样才能确保哈希表是可靠的。
|
||||||
|
- **效率高**:计算哈希值的过程应该足够快。计算开销越小,哈希表的实用性越高。
|
||||||
|
- **均匀分布**:哈希算法应使得键值对平均分布在哈希表中。分布越平均,哈希冲突的概率就越低。
|
||||||
|
|
||||||
|
实际上,哈希算法除了可以用于实现哈希表,还广泛应用于其他领域中,包括:
|
||||||
|
|
||||||
|
- **密码存储**:为了保护用户密码的安全,系统通常不会直接存储用户的明文密码,而是存储密码的哈希值。当用户输入密码时,系统会对输入的密码计算哈希值,然后与存储的哈希值进行比较。如果两者匹配,那么密码就被视为正确。
|
||||||
|
- **数据完整性检查**:数据发送方可以计算数据的哈希值并将其一同发送;接收方可以重新计算接收到的数据的哈希值,并与接收到的哈希值进行比较。如果两者匹配,那么数据就被视为完整的。
|
||||||
|
|
||||||
|
对于密码学的相关应用,哈希算法需要满足更高的安全标准,以防止从哈希值推导出原始密码等逆向工程,包括:
|
||||||
|
|
||||||
|
- **抗碰撞性**:应当极其困难找到两个不同的输入,使得它们的哈希值相同。
|
||||||
|
- **雪崩效应**:输入的微小变化应当导致输出的显著且不可预测的变化。
|
||||||
|
|
||||||
|
注意,**“均匀分布”与“抗碰撞性”是两个独立的概念**,满足均匀分布不一定满足抗碰撞性。例如,在随机输入 `key` 下,哈希函数 `key % 100` 可以产生均匀分布的输出。然而,该哈希算法过于简单,所有后两位相等的 `key` 的输出都相同,因此我们可以很容易地从哈希值反推出可用的 `key` ,从而破解密码。
|
||||||
|
|
||||||
|
## 6.3.2. 哈希算法的设计
|
||||||
|
|
||||||
|
哈希算法的设计是一个复杂且需要考虑许多因素的问题。然而,对于一些简单场景,我们也能设计一些简单的哈希算法,以字符串哈希为例:
|
||||||
|
|
||||||
|
- **加法哈希**:对输入的每个字符的 ASCII 码进行相加,将得到的总和作为哈希值。
|
||||||
|
- **乘法哈希**:利用了乘法的不相关性,每轮乘以一个常数,将各个字符的 ASCII 码累积到哈希值中。
|
||||||
|
- **异或哈希**:将输入数据的每个元素通过异或操作累积到一个哈希值中。
|
||||||
|
- **旋转哈希**:将每个字符的 ASCII 码累积到一个哈希值中,每次累积之前都会对哈希值进行旋转操作。
|
||||||
|
|
||||||
|
=== "Java"
|
||||||
|
|
||||||
|
```java title="simple_hash.java"
|
||||||
|
[class]{simple_hash}-[func]{addHash}
|
||||||
|
|
||||||
|
[class]{simple_hash}-[func]{mulHash}
|
||||||
|
|
||||||
|
[class]{simple_hash}-[func]{xorHash}
|
||||||
|
|
||||||
|
[class]{simple_hash}-[func]{rotHash}
|
||||||
|
```
|
||||||
|
|
||||||
|
=== "C++"
|
||||||
|
|
||||||
|
```cpp title="simple_hash.cpp"
|
||||||
|
[class]{}-[func]{addHash}
|
||||||
|
|
||||||
|
[class]{}-[func]{mulHash}
|
||||||
|
|
||||||
|
[class]{}-[func]{xorHash}
|
||||||
|
|
||||||
|
[class]{}-[func]{rotHash}
|
||||||
|
```
|
||||||
|
|
||||||
|
=== "Python"
|
||||||
|
|
||||||
|
```python title="simple_hash.py"
|
||||||
|
def add_hash(key: str) -> int:
|
||||||
|
"""加法哈希"""
|
||||||
|
hash = 0
|
||||||
|
modulus = 1000000007
|
||||||
|
for c in key:
|
||||||
|
hash += ord(c)
|
||||||
|
return hash % modulus
|
||||||
|
|
||||||
|
def mul_hash(key: str) -> int:
|
||||||
|
"""乘法哈希"""
|
||||||
|
hash = 0
|
||||||
|
modulus = 1000000007
|
||||||
|
for c in key:
|
||||||
|
hash = 31 * hash + ord(c)
|
||||||
|
return hash % modulus
|
||||||
|
|
||||||
|
def xor_hash(key: str) -> int:
|
||||||
|
"""异或哈希"""
|
||||||
|
hash = 0
|
||||||
|
modulus = 1000000007
|
||||||
|
for c in key:
|
||||||
|
hash ^= ord(c)
|
||||||
|
return hash % modulus
|
||||||
|
|
||||||
|
def rot_hash(key: str) -> int:
|
||||||
|
"""旋转哈希"""
|
||||||
|
hash = 0
|
||||||
|
modulus = 1000000007
|
||||||
|
for c in key:
|
||||||
|
hash = (hash << 4) ^ (hash >> 28) ^ ord(c)
|
||||||
|
return hash % modulus
|
||||||
|
```
|
||||||
|
|
||||||
|
=== "Go"
|
||||||
|
|
||||||
|
```go title="simple_hash.go"
|
||||||
|
[class]{}-[func]{addHash}
|
||||||
|
|
||||||
|
[class]{}-[func]{mulHash}
|
||||||
|
|
||||||
|
[class]{}-[func]{xorHash}
|
||||||
|
|
||||||
|
[class]{}-[func]{rotHash}
|
||||||
|
```
|
||||||
|
|
||||||
|
=== "JavaScript"
|
||||||
|
|
||||||
|
```javascript title="simple_hash.js"
|
||||||
|
[class]{}-[func]{addHash}
|
||||||
|
|
||||||
|
[class]{}-[func]{mulHash}
|
||||||
|
|
||||||
|
[class]{}-[func]{xorHash}
|
||||||
|
|
||||||
|
[class]{}-[func]{rotHash}
|
||||||
|
```
|
||||||
|
|
||||||
|
=== "TypeScript"
|
||||||
|
|
||||||
|
```typescript title="simple_hash.ts"
|
||||||
|
[class]{}-[func]{addHash}
|
||||||
|
|
||||||
|
[class]{}-[func]{mulHash}
|
||||||
|
|
||||||
|
[class]{}-[func]{xorHash}
|
||||||
|
|
||||||
|
[class]{}-[func]{rotHash}
|
||||||
|
```
|
||||||
|
|
||||||
|
=== "C"
|
||||||
|
|
||||||
|
```c title="simple_hash.c"
|
||||||
|
[class]{}-[func]{addHash}
|
||||||
|
|
||||||
|
[class]{}-[func]{mulHash}
|
||||||
|
|
||||||
|
[class]{}-[func]{xorHash}
|
||||||
|
|
||||||
|
[class]{}-[func]{rotHash}
|
||||||
|
```
|
||||||
|
|
||||||
|
=== "C#"
|
||||||
|
|
||||||
|
```csharp title="simple_hash.cs"
|
||||||
|
[class]{simple_hash}-[func]{addHash}
|
||||||
|
|
||||||
|
[class]{simple_hash}-[func]{mulHash}
|
||||||
|
|
||||||
|
[class]{simple_hash}-[func]{xorHash}
|
||||||
|
|
||||||
|
[class]{simple_hash}-[func]{rotHash}
|
||||||
|
```
|
||||||
|
|
||||||
|
=== "Swift"
|
||||||
|
|
||||||
|
```swift title="simple_hash.swift"
|
||||||
|
[class]{}-[func]{addHash}
|
||||||
|
|
||||||
|
[class]{}-[func]{mulHash}
|
||||||
|
|
||||||
|
[class]{}-[func]{xorHash}
|
||||||
|
|
||||||
|
[class]{}-[func]{rotHash}
|
||||||
|
```
|
||||||
|
|
||||||
|
=== "Zig"
|
||||||
|
|
||||||
|
```zig title="simple_hash.zig"
|
||||||
|
[class]{}-[func]{addHash}
|
||||||
|
|
||||||
|
[class]{}-[func]{mulHash}
|
||||||
|
|
||||||
|
[class]{}-[func]{xorHash}
|
||||||
|
|
||||||
|
[class]{}-[func]{rotHash}
|
||||||
|
```
|
||||||
|
|
||||||
|
=== "Dart"
|
||||||
|
|
||||||
|
```dart title="simple_hash.dart"
|
||||||
|
[class]{}-[func]{add_hash}
|
||||||
|
|
||||||
|
[class]{}-[func]{mul_hash}
|
||||||
|
|
||||||
|
[class]{}-[func]{xor_hash}
|
||||||
|
|
||||||
|
[class]{}-[func]{rot_hash}
|
||||||
|
```
|
||||||
|
|
||||||
|
观察发现,每种哈希算法的最后一步都是对大质数 $1000000007$ 取模,以确保哈希值在合适的范围内。值得思考的是,为什么要强调对质数取模,对合数取模的弊端是什么?这是一个有趣的问题。
|
||||||
|
|
||||||
|
先抛出结论:**当我们使用大质数作为模数时,可以最大化地保证哈希值的均匀分布**。因为质数不会与其他数字存在公约数,可以减少因取模操作而产生的周期性模式,从而避免哈希冲突。
|
||||||
|
|
||||||
|
举个例子,假设我们选择合数 $9$ 作为模数,它可以被 $3$ 整除。那么所有可以被 $3$ 整除的 `key` 都会被映射到 $0$ , $3$ , $6$ 这三个哈希值。
|
||||||
|
|
||||||
|
$$
|
||||||
|
\begin{aligned}
|
||||||
|
\text{modulus} & = 9 \newline
|
||||||
|
\text{key} & = \{ 0, 3, 6, 9, 12, 15, 18, 21, 24, 27, 30, 33, \cdots \} \newline
|
||||||
|
\text{hash} & = \{ 0, 3, 6, 0, 3, 6, 0, 3, 6, 0, 3, 6,\cdots \}
|
||||||
|
\end{aligned}
|
||||||
|
$$
|
||||||
|
|
||||||
|
如果输入 `key` 恰好满足这种等差数列的数据分布,那么哈希值就会出现聚堆,从而加重哈希冲突。现在,假设将 `modulus` 替换为质数 $13$ ,由于 `key` 和 `modulus` 之间不存在公约数,输出的哈希值的均匀性会明显提升。
|
||||||
|
|
||||||
|
$$
|
||||||
|
\begin{aligned}
|
||||||
|
\text{modulus} & = 13 \newline
|
||||||
|
\text{key} & = \{ 0, 3, 6, 9, 12, 15, 18, 21, 24, 27, 30, 33, \cdots \} \newline
|
||||||
|
\text{hash} & = \{ 0, 3, 6, 9, 12, 2, 5, 8, 11, 1, 4, 7, \cdots \}
|
||||||
|
\end{aligned}
|
||||||
|
$$
|
||||||
|
|
||||||
|
值得强调的是,如果能够保证 `key` 是随机均匀分布的,那么选择质数或者合数作为模数都是可以的,它们都能输出均匀分布的哈希值。而当 `key` 的分布存在某种周期性时,对合数取模更容易出现聚集现象。
|
||||||
|
|
||||||
|
总而言之,我们通常选取质数作为模数,并且这个质数最好大一些,以提升哈希算法的稳健性。
|
||||||
|
|
||||||
|
## 6.3.3. 常见哈希算法
|
||||||
|
|
||||||
|
不难发现,以上介绍的简单哈希算法都比较“脆弱”,远远没有达到哈希算法的设计目标。例如,由于加法和异或满足交换律,因此加法哈希和异或哈希无法区分内容相同但顺序不同的字符串,这可能会加剧哈希冲突,并引起一些安全问题。
|
||||||
|
|
||||||
|
在实际中,我们通常会用一些标准哈希算法,例如 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-3 |
|
||||||
|
| -------- | ------------------------------ | -------------------- | ---------------------------- | -------------------- |
|
||||||
|
| 推出时间 | 1992 | 1995 | 2002 | 2008 |
|
||||||
|
| 输出长度 | 128 bits | 160 bits | 256 / 512 bits | 224/256/384/512 bits |
|
||||||
|
| 哈希冲突 | 较多 | 较多 | 很少 | 很少 |
|
||||||
|
| 安全等级 | 低,已被成功攻击 | 低,已被成功攻击 | 高 | 高 |
|
||||||
|
| 应用 | 已被弃用,仍用于数据完整性检查 | 已被弃用 | 加密货币交易验证、数字签名等 | 可用于替代 SHA-2 |
|
||||||
|
|
||||||
|
## 6.3.4. 数据结构的哈希值
|
||||||
|
|
||||||
|
我们知道,哈希表的 `key` 可以是整数、小数或字符串等数据类型。编程语言通常会为这些数据类型提供内置的哈希算法 `hash()` ,用于计算哈希表中的桶索引。以 Python 为例:
|
||||||
|
|
||||||
|
- 整数和布尔量的哈希值就是其本身。
|
||||||
|
- 浮点数和字符串的哈希值计算较为复杂,有兴趣的同学请自行学习。
|
||||||
|
- 元组的哈希值是对其中每一个元素进行哈希,然后将这些哈希值组合起来,得到单一的哈希值。
|
||||||
|
- 对象的哈希值基于其内存地址生成。通过重写对象的哈希方法,可实现基于内容生成哈希值。
|
||||||
|
|
||||||
|
=== "Java"
|
||||||
|
|
||||||
|
```java title="built_in_hash.java"
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
=== "C++"
|
||||||
|
|
||||||
|
```cpp title="built_in_hash.cpp"
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
=== "Python"
|
||||||
|
|
||||||
|
```python title="built_in_hash.py"
|
||||||
|
num = 3
|
||||||
|
hash_num = hash(num)
|
||||||
|
# 整数 3 的哈希值为 3
|
||||||
|
|
||||||
|
bol = True
|
||||||
|
hash_bol = hash(bol)
|
||||||
|
# 布尔量 True 的哈希值为 1
|
||||||
|
|
||||||
|
dec = 3.14159
|
||||||
|
hash_dec = hash(dec)
|
||||||
|
# 小数 3.14159 的哈希值为 326484311674566659
|
||||||
|
|
||||||
|
str = "Hello 算法"
|
||||||
|
hash_str = hash(str)
|
||||||
|
# 字符串 Hello 算法 的哈希值为 4617003410720528961
|
||||||
|
|
||||||
|
tup = (12836, "小哈")
|
||||||
|
hash_tup = hash(tup)
|
||||||
|
# 元组 (12836, '小哈') 的哈希值为 1029005403108185979
|
||||||
|
|
||||||
|
obj = ListNode(0)
|
||||||
|
hash_obj = hash(obj)
|
||||||
|
# 节点对象 <ListNode object at 0x1058fd810> 的哈希值为 274267521
|
||||||
|
```
|
||||||
|
|
||||||
|
=== "Go"
|
||||||
|
|
||||||
|
```go title="built_in_hash.go"
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
=== "JavaScript"
|
||||||
|
|
||||||
|
```javascript title="built_in_hash.js"
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
=== "TypeScript"
|
||||||
|
|
||||||
|
```typescript title="built_in_hash.ts"
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
=== "C"
|
||||||
|
|
||||||
|
```c title="built_in_hash.c"
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
=== "C#"
|
||||||
|
|
||||||
|
```csharp title="built_in_hash.cs"
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
=== "Swift"
|
||||||
|
|
||||||
|
```swift title="built_in_hash.swift"
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
=== "Zig"
|
||||||
|
|
||||||
|
```zig title="built_in_hash.zig"
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
=== "Dart"
|
||||||
|
|
||||||
|
```dart title="built_in_hash.dart"
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
在大多数编程语言中,**只有不可变对象才可作为哈希表的 `key`** 。假如我们将列表(动态数组)作为 `key` ,当列表的内容发生变化时,它的哈希值也随之改变,我们就无法在哈希表中查询到原先的 `value` 了。
|
||||||
|
|
||||||
|
虽然自定义对象(例如链表节点)的成员变量是可变的,但它是可哈希的,这是因为对象的哈希值默认基于内存地址生成。即使对象的内容发生了变化,但它的内存地址不变,哈希值仍然是不变的。
|
||||||
|
|
||||||
|
!!! tip "向哈希函数加盐"
|
||||||
|
|
||||||
|
Python 解释器在每次启动时,都会为字符串哈希函数加入一个随机的盐(Salt)值。因此在不同的 Python 运行实例中,同一字符串的哈希值通常是不同的。此做法可以有效防止 HashDoS 攻击,提升哈希算法的安全性。
|
|
@ -4,20 +4,16 @@ comments: true
|
||||||
|
|
||||||
# 6.2. 哈希冲突
|
# 6.2. 哈希冲突
|
||||||
|
|
||||||
在理想情况下,哈希函数为每个输入生成唯一的输出,实现 key 和数组索引的一一对应。但实际上,**哈希函数的输入空间通常远大于输出空间**,因此多个输入产生相同输出的情况是不可避免的。例如,输入空间为全体整数,输出空间为数组容量大小,则必然有多个整数映射至同一数组索引。
|
上节提到,**通常情况下哈希函数的输入空间远大于输出空间**,因此哈希冲突是不可避免的。例如,输入空间为全体整数,输出空间为数组容量大小,则必然有多个整数映射至同一数组索引。
|
||||||
|
|
||||||
这种多个输入对应同一输出索引的现象被称为「哈希冲突 Hash Collision」。哈希冲突会导致查询结果错误,严重影响哈希表的可用性。哈希冲突的处理方法主要有两种:
|
哈希冲突会导致查询结果错误,严重影响哈希表的可用性。为解决该问题,我们可以每当遇到哈希冲突时就进行哈希表扩容,直至冲突消失为止。此方法简单粗暴且有效,但效率太低,因为哈希表扩容需要进行大量的数据搬运与哈希值计算。为了提升效率,我们换一种思路:
|
||||||
|
|
||||||
- **扩大哈希表容量**:哈希表容量越大,键值对聚集的概率就越低。极端情况下,当输入空间和输出空间大小相等时,哈希表等同于数组,每个 key 都对应唯一的数组索引。
|
1. 改良哈希表数据结构,**使得哈希表可以在存在哈希冲突时正常工作**。
|
||||||
- **优化哈希表结构**:常用方法包括链式地址和开放寻址。这类方法的思路是通过改良数据结构,使得哈希表可以在发生哈希冲突时仍然可以正常工作。当然,这些优化往往是以牺牲时间效率为代价的。
|
2. 仅在必要时,即当哈希冲突比较严重时,执行扩容操作。
|
||||||
|
|
||||||
## 6.2.1. 哈希表扩容
|
哈希表的结构改良方法主要包括链式地址和开放寻址。
|
||||||
|
|
||||||
哈希函数的最后一步通常是对桶数量 $n$ 取余,作用是将哈希值映射到桶索引范围,从而将 key 放入对应的桶中。当哈希表容量越大(即 $n$ 越大)时,多个 key 被分配到同一个桶中的概率就越低,冲突就越少。因此,**当哈希表内的冲突总体较为严重时,编程语言通常通过扩容哈希表来缓解冲突**。类似于数组扩容,哈希表扩容需将所有键值对从原哈希表迁移至新哈希表,开销较大。
|
## 6.2.1. 链式地址
|
||||||
|
|
||||||
编程语言通常使用「负载因子 Load Factor」来衡量哈希冲突的严重程度,**定义为哈希表中元素数量除以桶数量**,常作为哈希表扩容的触发条件。在 Java 中,当负载因子超过 $0.75$ 时,系统会将 HashMap 容量扩展为原先的 $2$ 倍。
|
|
||||||
|
|
||||||
## 6.2.2. 链式地址
|
|
||||||
|
|
||||||
在原始哈希表中,每个桶仅能存储一个键值对。「链式地址 Separate Chaining」将单个元素转换为链表,将键值对作为链表节点,将所有发生冲突的键值对都存储在同一链表中。
|
在原始哈希表中,每个桶仅能存储一个键值对。「链式地址 Separate Chaining」将单个元素转换为链表,将键值对作为链表节点,将所有发生冲突的键值对都存储在同一链表中。
|
||||||
|
|
||||||
|
@ -27,7 +23,7 @@ comments: true
|
||||||
|
|
||||||
链式地址下,哈希表的操作方法包括:
|
链式地址下,哈希表的操作方法包括:
|
||||||
|
|
||||||
- **查询元素**:输入 key ,经过哈希函数得到数组索引,即可访问链表头节点,然后遍历链表并对比 key 以查找目标键值对。
|
- **查询元素**:输入 `key` ,经过哈希函数得到数组索引,即可访问链表头节点,然后遍历链表并对比 `key` 以查找目标键值对。
|
||||||
- **添加元素**:先通过哈希函数访问链表头节点,然后将节点(即键值对)添加到链表中。
|
- **添加元素**:先通过哈希函数访问链表头节点,然后将节点(即键值对)添加到链表中。
|
||||||
- **删除元素**:根据哈希函数的结果访问链表头部,接着遍历链表以查找目标节点,并将其删除。
|
- **删除元素**:根据哈希函数的结果访问链表头部,接着遍历链表以查找目标节点,并将其删除。
|
||||||
|
|
||||||
|
@ -439,7 +435,7 @@ comments: true
|
||||||
|
|
||||||
为了提高效率,**我们可以将链表转换为「AVL 树」或「红黑树」**,从而将查询操作的时间复杂度优化至 $O(\log n)$ 。
|
为了提高效率,**我们可以将链表转换为「AVL 树」或「红黑树」**,从而将查询操作的时间复杂度优化至 $O(\log n)$ 。
|
||||||
|
|
||||||
## 6.2.3. 开放寻址
|
## 6.2.2. 开放寻址
|
||||||
|
|
||||||
「开放寻址 Open Addressing」不引入额外的数据结构,而是通过“多次探测”来处理哈希冲突,探测方式主要包括线性探测、平方探测、多次哈希。
|
「开放寻址 Open Addressing」不引入额外的数据结构,而是通过“多次探测”来处理哈希冲突,探测方式主要包括线性探测、平方探测、多次哈希。
|
||||||
|
|
||||||
|
@ -448,7 +444,7 @@ comments: true
|
||||||
线性探测采用固定步长的线性查找来进行探测,对应的哈希表操作方法为:
|
线性探测采用固定步长的线性查找来进行探测,对应的哈希表操作方法为:
|
||||||
|
|
||||||
- **插入元素**:通过哈希函数计算数组索引,若发现桶内已有元素,则从冲突位置向后线性遍历(步长通常为 $1$ ),直至找到空位,将元素插入其中。
|
- **插入元素**:通过哈希函数计算数组索引,若发现桶内已有元素,则从冲突位置向后线性遍历(步长通常为 $1$ ),直至找到空位,将元素插入其中。
|
||||||
- **查找元素**:若发现哈希冲突,则使用相同步长向后线性遍历,直到找到对应元素,返回 value 即可;或者若遇到空位,说明目标键值对不在哈希表中,返回 $\text{None}$ 。
|
- **查找元素**:若发现哈希冲突,则使用相同步长向后线性遍历,直到找到对应元素,返回 `value` 即可;或者若遇到空位,说明目标键值对不在哈希表中,返回 $\text{None}$ 。
|
||||||
|
|
||||||
![线性探测](hash_collision.assets/hash_table_linear_probing.png)
|
![线性探测](hash_collision.assets/hash_table_linear_probing.png)
|
||||||
|
|
||||||
|
|
|
@ -6,16 +6,16 @@ comments: true
|
||||||
|
|
||||||
「哈希表 Hash Table」通过建立键 `key` 与值 `value` 之间的映射,实现高效的元素查询。具体而言,我们向哈希表输入一个 `key` ,则可以在 $O(1)$ 时间内获取对应的 `value` 。
|
「哈希表 Hash Table」通过建立键 `key` 与值 `value` 之间的映射,实现高效的元素查询。具体而言,我们向哈希表输入一个 `key` ,则可以在 $O(1)$ 时间内获取对应的 `value` 。
|
||||||
|
|
||||||
以一个包含 $n$ 个学生的数据库为例,每个学生都有“姓名 `name`”和“学号 `id`”两项数据。假如我们希望实现查询功能,例如“输入一个学号,返回对应的姓名”,则可以采用哈希表来实现。
|
以一个包含 $n$ 个学生的数据库为例,每个学生都有“姓名”和“学号”两项数据。假如我们希望实现“输入一个学号,返回对应的姓名”的查询功能,则可以采用哈希表来实现。
|
||||||
|
|
||||||
![哈希表的抽象表示](hash_map.assets/hash_table_lookup.png)
|
![哈希表的抽象表示](hash_map.assets/hash_table_lookup.png)
|
||||||
|
|
||||||
<p align="center"> Fig. 哈希表的抽象表示 </p>
|
<p align="center"> Fig. 哈希表的抽象表示 </p>
|
||||||
|
|
||||||
除哈希表外,我们还可以使用数组或链表实现元素查询,其中:
|
除哈希表外,我们还可以使用数组或链表实现查询功能,其中:
|
||||||
|
|
||||||
- 查询元素需要遍历所有元素,使用 $O(n)$ 时间;
|
- 查询元素需要遍历数组(链表)中的所有元素,使用 $O(n)$ 时间;
|
||||||
- 添加元素仅需添加至尾部即可,使用 $O(1)$ 时间;
|
- 添加元素仅需添加至数组(链表)的尾部即可,使用 $O(1)$ 时间;
|
||||||
- 删除元素需要先查询再删除,使用 $O(n)$ 时间;
|
- 删除元素需要先查询再删除,使用 $O(n)$ 时间;
|
||||||
|
|
||||||
<div class="center-table" markdown>
|
<div class="center-table" markdown>
|
||||||
|
@ -28,11 +28,11 @@ comments: true
|
||||||
|
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
观察发现,在哈希表中进行增删查改的时间复杂度都是 $O(1)$ ,非常高效。因此,哈希表常用于对查找效率要求较高的场景。
|
观察发现,**在哈希表中进行增删查改的时间复杂度都是 $O(1)$** ,非常高效。因此,哈希表常用于对查找效率要求较高的场景。
|
||||||
|
|
||||||
## 6.1.1. 哈希表常用操作
|
## 6.1.1. 哈希表常用操作
|
||||||
|
|
||||||
哈希表的基本操作包括 **初始化、查询操作、添加与删除键值对**。
|
哈希表的常见操作包括:初始化、查询操作、添加键值对和删除键值对等。
|
||||||
|
|
||||||
=== "Java"
|
=== "Java"
|
||||||
|
|
||||||
|
@ -256,7 +256,7 @@ comments: true
|
||||||
map.remove(10583);
|
map.remove(10583);
|
||||||
```
|
```
|
||||||
|
|
||||||
遍历哈希表有三种方式,即 **遍历键值对、遍历键、遍历值**。
|
哈希表有三种常用遍历方式:遍历键值对、遍历键和遍历值。
|
||||||
|
|
||||||
=== "Java"
|
=== "Java"
|
||||||
|
|
||||||
|
@ -436,19 +436,19 @@ comments: true
|
||||||
|
|
||||||
## 6.1.2. 哈希表简单实现
|
## 6.1.2. 哈希表简单实现
|
||||||
|
|
||||||
我们先考虑最简单的情况,**仅用一个数组来实现哈希表**。在哈希表中,我们通常将数组中的每个空位称为「桶 Bucket」,每个桶可存储一个键值对。因此,查询操作就是定位输入的 `key` 对应的桶,从而得到 `value` 。
|
我们先考虑最简单的情况,**仅用一个数组来实现哈希表**。在哈希表中,我们将数组中的每个空位称为「桶 Bucket」,每个桶可存储一个键值对。因此,查询操作就是找到 `key` 对应的桶,并在桶中获取 `value` 。
|
||||||
|
|
||||||
那么,如何基于 `key` 来定位对应的桶呢?这是通过「哈希函数 Hash Function」实现的。哈希函数的作用是将一个较大的输入空间映射到一个较小的输出空间。在哈希表中,输入空间是所有 `key` ,输出空间是所有桶(数组索引)。换句话说,**输入一个 `key` ,我们可以通过哈希函数得到该 `key` 对应的键值对存储在数组中的位置**。
|
那么,如何基于 `key` 来定位对应的桶呢?这是通过「哈希函数 Hash Function」实现的。哈希函数的作用是将一个较大的输入空间映射到一个较小的输出空间。在哈希表中,输入空间是所有 `key` ,输出空间是所有桶(数组索引)。换句话说,输入一个 `key` ,**我们可以通过哈希函数得到该 `key` 对应的键值对在数组中的存储位置**。
|
||||||
|
|
||||||
哈希函数的计算过程分为两步:输入一个 `key` ,首先通过函数 `hash(key)` 计算得到哈希值,接下来将哈希值对桶数量(数组长度)取模,从而获取该 `key` 对应的数组索引 `index` 。计算公式如下
|
输入一个 `key` ,哈希函数的计算过程分为两步:首先,通过哈希算法 `hash()` 计算得到哈希值;接下来,将哈希值对桶数量(数组长度)`capacity` 取模,从而获取该 `key` 对应的数组索引 `index` 。
|
||||||
|
|
||||||
$$
|
```shell
|
||||||
index = \text{hash}(key) \bmod {c}
|
index = hash(key) % capacity
|
||||||
$$
|
```
|
||||||
|
|
||||||
其中, $\bmod$ 表示取余运算, $c$ 为桶数量(数组长度)。随后,我们就可以利用 `index` 在哈希表中访问对应的桶,从而获取 `value` 。
|
随后,我们就可以利用 `index` 在哈希表中访问对应的桶,从而获取 `value` 。
|
||||||
|
|
||||||
设数组长度 $c = 100$ , $\text{hash}(key) = key$ ,易得哈希函数为 $key \bmod 100$ 。下图以 `key` 学号和 `value` 姓名为例,展示了哈希函数的工作原理。
|
设数组长度 `capacity = 100` 、哈希算法 `hash(key) = key` ,易得哈希函数为 `key % 100` 。下图以 `key` 学号和 `value` 姓名为例,展示了哈希函数的工作原理。
|
||||||
|
|
||||||
![哈希函数工作原理](hash_map.assets/hash_function.png)
|
![哈希函数工作原理](hash_map.assets/hash_function.png)
|
||||||
|
|
||||||
|
@ -1403,18 +1403,29 @@ $$
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
## 6.1.3. 哈希冲突
|
## 6.1.3. 哈希冲突与扩容
|
||||||
|
|
||||||
本质上看,哈希函数的是将一个庞大的输入空间(`key` 范围)映射到一个较小的输出空间(数组索引范围)。因此,**理论上一定存在”多个输入对应相同输出”的情况**。
|
本质上看,哈希函数的作用是黄输入空间(`key` 范围)映射到输出空间(数组索引范围),而输入空间往往远大于输出空间。因此,**理论上一定存在“多个输入对应相同输出”的情况**。
|
||||||
|
|
||||||
对于上述示例中的哈希函数,当输入的 `key` 后两位相同时,哈希函数的输出结果也相同。例如,查询学号为 $12836$ 和 $20336$ 的两个学生时,我们得到:
|
对于上述示例中的哈希函数,当输入的 `key` 后两位相同时,哈希函数的输出结果也相同。例如,查询学号为 12836 和 20336 的两个学生时,我们得到:
|
||||||
|
|
||||||
$$
|
```shell
|
||||||
12836 \bmod 100 = 20336 \bmod 100 = 36
|
12386 % 100 = 36
|
||||||
$$
|
20386 % 100 = 36
|
||||||
|
```
|
||||||
|
|
||||||
两个学号指向了同一个姓名,这显然是不对的。我们把这种情况称为“哈希冲突”。在下节中,我们将重点讨论如何解决冲突问题。
|
如下图所示,两个学号指向了同一个姓名,这显然是不对的。我们将这种多个输入对应同一输出的情况称为「哈希冲突 Hash Collision」。
|
||||||
|
|
||||||
![哈希冲突示例](hash_map.assets/hash_collision.png)
|
![哈希冲突示例](hash_map.assets/hash_collision.png)
|
||||||
|
|
||||||
<p align="center"> Fig. 哈希冲突示例 </p>
|
<p align="center"> Fig. 哈希冲突示例 </p>
|
||||||
|
|
||||||
|
容易想到,哈希表容量 $n$ 越大,多个 `key` 被分配到同一个桶中的概率就越低,冲突就越少。因此,**我们可以通过扩容哈希表来减少哈希冲突**。如下图所示,扩容前键值对 `(136, A)` 和 `(236, D)` 发生冲突,扩容后冲突消失。
|
||||||
|
|
||||||
|
![哈希表扩容](hash_map.assets/hash_table_reshash.png)
|
||||||
|
|
||||||
|
<p align="center"> Fig. 哈希表扩容 </p>
|
||||||
|
|
||||||
|
类似于数组扩容,哈希表扩容需将所有键值对从原哈希表迁移至新哈希表,非常耗时。并且由于哈希表容量 `capacity` 改变,我们需要重新计算所有键值对的存储位置,进一步提高了扩容过程的计算开销。因此,编程语言通常会预留足够大的哈希表容量,防止频繁扩容。
|
||||||
|
|
||||||
|
在哈希表中,「负载因子 Load Factor」是一个重要概念,其定义为哈希表的元素数量除以桶数量,为了衡量哈希冲突的严重程度,**也常被作为哈希表扩容的触发条件**。例如在 Java 中,当负载因子超过 $0.75$ 时,系统会将哈希表容量扩展为原先的 $2$ 倍。
|
||||||
|
|
|
@ -2,7 +2,7 @@
|
||||||
comments: true
|
comments: true
|
||||||
---
|
---
|
||||||
|
|
||||||
# 6.3. 小结
|
# 6.4. 小结
|
||||||
|
|
||||||
- 哈希表能够在 $O(1)$ 时间内将键 key 映射到值 value,效率非常高。
|
- 哈希表能够在 $O(1)$ 时间内将键 key 映射到值 value,效率非常高。
|
||||||
- 常见的哈希表操作包括查询、添加与删除键值对、遍历键值对等。
|
- 常见的哈希表操作包括查询、添加与删除键值对、遍历键值对等。
|
||||||
|
|
Loading…
Reference in a new issue