mirror of
https://github.com/krahets/hello-algo.git
synced 2025-12-19 07:17:54 +08:00
Replace ":" with "。"
This commit is contained in:
@@ -18,18 +18,18 @@ index = hash(key) % capacity
|
||||
|
||||
## 哈希算法的目标
|
||||
|
||||
为了实现“既快又稳”的哈希表数据结构,哈希算法应包含以下特点:
|
||||
为了实现“既快又稳”的哈希表数据结构,哈希算法应包含以下特点。
|
||||
|
||||
- **确定性**:对于相同的输入,哈希算法应始终产生相同的输出。这样才能确保哈希表是可靠的。
|
||||
- **效率高**:计算哈希值的过程应该足够快。计算开销越小,哈希表的实用性越高。
|
||||
- **均匀分布**:哈希算法应使得键值对平均分布在哈希表中。分布越平均,哈希冲突的概率就越低。
|
||||
|
||||
实际上,哈希算法除了可以用于实现哈希表,还广泛应用于其他领域中。举两个例子:
|
||||
实际上,哈希算法除了可以用于实现哈希表,还广泛应用于其他领域中。
|
||||
|
||||
- **密码存储**:为了保护用户密码的安全,系统通常不会直接存储用户的明文密码,而是存储密码的哈希值。当用户输入密码时,系统会对输入的密码计算哈希值,然后与存储的哈希值进行比较。如果两者匹配,那么密码就被视为正确。
|
||||
- **数据完整性检查**:数据发送方可以计算数据的哈希值并将其一同发送;接收方可以重新计算接收到的数据的哈希值,并与接收到的哈希值进行比较。如果两者匹配,那么数据就被视为完整的。
|
||||
|
||||
对于密码学的相关应用,哈希算法需要满足更高的安全标准,以防止从哈希值推导出原始密码等逆向工程,包括:
|
||||
对于密码学的相关应用,为了防止从哈希值推导出原始密码等逆向工程,哈希算法需要具备更高等级的安全特性。
|
||||
|
||||
- **抗碰撞性**:应当极其困难找到两个不同的输入,使得它们的哈希值相同。
|
||||
- **雪崩效应**:输入的微小变化应当导致输出的显著且不可预测的变化。
|
||||
@@ -38,7 +38,7 @@ index = hash(key) % capacity
|
||||
|
||||
## 哈希算法的设计
|
||||
|
||||
哈希算法的设计是一个复杂且需要考虑许多因素的问题。然而对于简单场景,我们也能设计一些简单的哈希算法。以字符串哈希为例:
|
||||
哈希算法的设计是一个需要考虑许多因素的复杂问题。然而对于某些要求不高的场景,我们也能设计一些简单的哈希算法。
|
||||
|
||||
- **加法哈希**:对输入的每个字符的 ASCII 码进行相加,将得到的总和作为哈希值。
|
||||
- **乘法哈希**:利用了乘法的不相关性,每轮乘以一个常数,将各个字符的 ASCII 码累积到哈希值中。
|
||||
@@ -223,7 +223,7 @@ $$
|
||||
|
||||
在实际中,我们通常会用一些标准哈希算法,例如 MD5 , SHA-1 , SHA-2 , SHA3 等。它们可以将任意长度的输入数据映射到恒定长度的哈希值。
|
||||
|
||||
近一个世纪以来,哈希算法处在不断升级与优化的过程中。一部分研究人员努力提升哈希算法的性能,另一部分研究人员和黑客则致力于寻找哈希算法的安全性问题。直至目前:
|
||||
近一个世纪以来,哈希算法处在不断升级与优化的过程中。一部分研究人员努力提升哈希算法的性能,另一部分研究人员和黑客则致力于寻找哈希算法的安全性问题。
|
||||
|
||||
- MD5 和 SHA-1 已多次被成功攻击,因此它们被各类安全应用弃用。
|
||||
- SHA-2 系列中的 SHA-256 是最安全的哈希算法之一,仍未出现成功的攻击案例,因此常被用在各类安全应用与协议中。
|
||||
@@ -239,7 +239,7 @@ $$
|
||||
|
||||
## 数据结构的哈希值
|
||||
|
||||
我们知道,哈希表的 `key` 可以是整数、小数或字符串等数据类型。编程语言通常会为这些数据类型提供内置的哈希算法,用于计算哈希表中的桶索引。以 Python 为例,我们可以调用 `hash()` 函数来计算各种数据类型的哈希值,包括:
|
||||
我们知道,哈希表的 `key` 可以是整数、小数或字符串等数据类型。编程语言通常会为这些数据类型提供内置的哈希算法,用于计算哈希表中的桶索引。以 Python 为例,我们可以调用 `hash()` 函数来计算各种数据类型的哈希值。
|
||||
|
||||
- 整数和布尔量的哈希值就是其本身。
|
||||
- 浮点数和字符串的哈希值计算较为复杂,有兴趣的同学请自行学习。
|
||||
|
||||
@@ -2,12 +2,12 @@
|
||||
|
||||
上节提到,**通常情况下哈希函数的输入空间远大于输出空间**,因此理论上哈希冲突是不可避免的。比如,输入空间为全体整数,输出空间为数组容量大小,则必然有多个整数映射至同一数组索引。
|
||||
|
||||
哈希冲突会导致查询结果错误,严重影响哈希表的可用性。为解决该问题,我们可以每当遇到哈希冲突时就进行哈希表扩容,直至冲突消失为止。此方法简单粗暴且有效,但效率太低,因为哈希表扩容需要进行大量的数据搬运与哈希值计算。为了提升效率,我们切换一下思路:
|
||||
哈希冲突会导致查询结果错误,严重影响哈希表的可用性。为解决该问题,我们可以每当遇到哈希冲突时就进行哈希表扩容,直至冲突消失为止。此方法简单粗暴且有效,但效率太低,因为哈希表扩容需要进行大量的数据搬运与哈希值计算。为了提升效率,我们可以采用以下思路。
|
||||
|
||||
1. 改良哈希表数据结构,**使得哈希表可以在存在哈希冲突时正常工作**。
|
||||
2. 仅在必要时,即当哈希冲突比较严重时,才执行扩容操作。
|
||||
|
||||
哈希表的结构改良方法主要包括链式地址和开放寻址。
|
||||
哈希表的结构改良方法主要包括“链式地址”和“开放寻址”。
|
||||
|
||||
## 链式地址
|
||||
|
||||
@@ -15,21 +15,21 @@
|
||||
|
||||

|
||||
|
||||
链式地址下,哈希表的操作方法包括:
|
||||
哈希表在链式地址下的操作方法发生了一些变化。
|
||||
|
||||
- **查询元素**:输入 `key` ,经过哈希函数得到数组索引,即可访问链表头节点,然后遍历链表并对比 `key` 以查找目标键值对。
|
||||
- **添加元素**:先通过哈希函数访问链表头节点,然后将节点(即键值对)添加到链表中。
|
||||
- **删除元素**:根据哈希函数的结果访问链表头部,接着遍历链表以查找目标节点,并将其删除。
|
||||
|
||||
该方法存在一些局限性,包括:
|
||||
链式地址存在以下局限性。
|
||||
|
||||
- **占用空间增大**,链表包含节点指针,它相比数组更加耗费内存空间。
|
||||
- **查询效率降低**,因为需要线性遍历链表来查找对应元素。
|
||||
|
||||
以下给出了链式地址哈希表的简单实现,需要注意:
|
||||
以下代码给出了链式地址哈希表的简单实现,需要注意两点。
|
||||
|
||||
- 为了使得代码尽量简短,我们使用列表(动态数组)代替链表。在这种设定下,哈希表(数组)包含多个桶,每个桶都是一个列表。
|
||||
- 以下代码实现了哈希表扩容方法。具体来看,当负载因子超过 $0.75$ 时,我们将哈希表扩容至 $2$ 倍。
|
||||
- 使用列表(动态数组)代替链表,从而简化代码。在这种设定下,哈希表(数组)包含多个桶,每个桶都是一个列表。
|
||||
- 以下实现包含哈希表扩容方法。当负载因子超过 $0.75$ 时,我们将哈希表扩容至 $2$ 倍。
|
||||
|
||||
=== "Java"
|
||||
|
||||
@@ -113,7 +113,7 @@
|
||||
|
||||
### 线性探测
|
||||
|
||||
线性探测采用固定步长的线性查找来进行探测,对应的哈希表操作方法为:
|
||||
线性探测采用固定步长的线性搜索来进行探测,其操作方法与普通哈希表有所不同。
|
||||
|
||||
- **插入元素**:通过哈希函数计算数组索引,若发现桶内已有元素,则从冲突位置向后线性遍历(步长通常为 $1$ ),直至找到空位,将元素插入其中。
|
||||
- **查找元素**:若发现哈希冲突,则使用相同步长向后线性遍历,直到找到对应元素,返回 `value` 即可;如果遇到空位,说明目标键值对不在哈希表中,返回 $\text{None}$ 。
|
||||
@@ -122,12 +122,12 @@
|
||||
|
||||

|
||||
|
||||
然而,线性探测存在以下缺陷:
|
||||
然而,线性探测存在以下缺陷。
|
||||
|
||||
- **不能直接删除元素**。删除元素会在数组内产生一个空位,当查找该空位之后的元素时,该空位可能导致程序误判元素不存在。为此,通常需要借助一个标志位来标记已删除元素。
|
||||
- **容易产生聚集**。数组内连续被占用位置越长,这些连续位置发生哈希冲突的可能性越大,进一步促使这一位置的聚堆生长,形成恶性循环,最终导致增删查改操作效率劣化。
|
||||
|
||||
以下代码实现了一个简单的开放寻址(线性探测)哈希表。值得注意两点:
|
||||
以下代码实现了一个简单的开放寻址(线性探测)哈希表。
|
||||
|
||||
- 我们使用一个固定的键值对实例 `removed` 来标记已删除元素。也就是说,当一个桶内的元素为 $\text{None}$ 或 `removed` 时,说明这个桶是空的,可用于放置键值对。
|
||||
- 在线性探测时,我们从当前索引 `index` 向后遍历;而当越过数组尾部时,需要回到头部继续遍历。
|
||||
|
||||
@@ -441,7 +441,7 @@
|
||||
|
||||
那么,如何基于 `key` 来定位对应的桶呢?这是通过「哈希函数 hash function」实现的。哈希函数的作用是将一个较大的输入空间映射到一个较小的输出空间。在哈希表中,输入空间是所有 `key` ,输出空间是所有桶(数组索引)。换句话说,输入一个 `key` ,**我们可以通过哈希函数得到该 `key` 对应的键值对在数组中的存储位置**。
|
||||
|
||||
输入一个 `key` ,哈希函数的计算过程分为两步:
|
||||
输入一个 `key` ,哈希函数的计算过程分为以下两步。
|
||||
|
||||
1. 通过某种哈希算法 `hash()` 计算得到哈希值。
|
||||
2. 将哈希值对桶数量(数组长度)`capacity` 取模,从而获取该 `key` 对应的数组索引 `index` 。
|
||||
|
||||
Reference in New Issue
Block a user