mirror of
https://github.com/krahets/hello-algo.git
synced 2025-11-02 21:24:53 +08:00
Add summary for the chapters of introduction, hashing, heap, graph, sorting
This commit is contained in:
@ -4,9 +4,9 @@
|
||||
|
||||
那么,为什么会出现哈希冲突呢?本质上看,**由于哈希函数的输入空间往往远大于输出空间**,因此不可避免地会出现多个输入产生相同输出的情况,即为哈希冲突。比如,输入空间是全体整数,输出空间是一个固定大小的桶(数组)的索引范围,那么必定会有多个整数同时映射到一个桶索引。
|
||||
|
||||
为了缓解哈希冲突,一方面,我们可以通过「哈希表扩容」来减小冲突概率。极端情况下,当输入空间和输出空间大小相等时,哈希表就等价于数组了,可谓“大力出奇迹”。
|
||||
为了缓解哈希冲突,一方面,**我们可以通过哈希表扩容来减小冲突概率**。极端情况下,当输入空间和输出空间大小相等时,哈希表就等价于数组了,可谓“大力出奇迹”。
|
||||
|
||||
另一方面,**考虑通过优化数据结构以缓解哈希冲突**,常见的方法有「链式地址」和「开放寻址」。
|
||||
另一方面,**考虑通过优化哈希表的表示方式以缓解哈希冲突**,常见的方法有「链式地址」和「开放寻址」。
|
||||
|
||||
## 哈希表扩容
|
||||
|
||||
@ -33,7 +33,7 @@
|
||||
- **占用空间变大**,因为链表或二叉树包含结点指针,相比于数组更加耗费内存空间;
|
||||
- **查询效率降低**,因为需要线性遍历链表来查找对应元素;
|
||||
|
||||
为了缓解时间效率问题,**可以把「链表」转化为「AVL 树」或「红黑树」**,将查询操作的时间复杂度优化至 $O(\log n)$ 。
|
||||
为了提升操作效率,**可以把「链表」转化为「AVL 树」或「红黑树」**,将查询操作的时间复杂度优化至 $O(\log n)$ 。
|
||||
|
||||
## 开放寻址
|
||||
|
||||
|
||||
@ -1 +1,11 @@
|
||||
# 小结
|
||||
|
||||
- 向哈希表中输入一个键 key ,查询到值 value 的时间复杂度为 $O(1)$ ,非常高效。
|
||||
- 哈希表的常用操作包括查询、添加与删除键值对、遍历键值对等。
|
||||
- 哈希函数将 key 映射到桶(数组)索引,从而访问到对应的值 value 。
|
||||
- 两个不同的 key 经过哈希函数可能得到相同的桶索引,进而发生哈希冲突,导致查询错误。
|
||||
- 缓解哈希冲突的途径有两种:哈希表扩容、优化哈希表的表示方式。
|
||||
- 负载因子定义为哈希表中元素数量除以桶槽数量,体现哈希冲突的严重程度,常用作哈希表扩容的触发条件。与数组扩容的原理类似,哈希表扩容操作开销也很大。
|
||||
- 链式地址考虑将单个元素转化成一个链表,将所有冲突元素都存储在一个链表中,从而解决哈希冲突。而为了提升查询效率,可以把链表转化为 AVL 树或红黑树,
|
||||
- 开放寻址通过多次探测来解决哈希冲突。线性探测使用固定步长,缺点是不能删除元素且容易产生聚集。多次哈希使用多个哈希函数进行探测,相对线性探测不容易产生聚集,代价是多个哈希函数增加了计算量。
|
||||
- 在工业界中,Java 的 HashMap 采用链式地址、Python 的 Dict 采用开放寻址。
|
||||
|
||||
Reference in New Issue
Block a user